Content Replication and Placement Phase

This phase consists of three steps to be performed aiming to collect statistical information about the objects, compute the number of replicas for each object and then find the placement for the replicas. These steps are described as follows:

During the τ period

During the replication period τ , every node maintains a list containing informa- tion about the request frequency observed by the node. The list entries are in the form of a 4-tuple hM Ri, Om, |Om|, λmi(τ )ithat represents the request count λmi for every object Om during τ at node i. An object request is counted when a MC initiates one to its access MR regardless of being served by the access MR, any other MR or even the origin server.

At the end of the τ period

In this step, the DNs send the collected statistical information to the CM that computes pm(τ + 1). The sub-steps are described as follows:

a. The partition members of the lowest level DNs forward their object fre- quency list obtained from previous step to their DN. Each DN aggregates the received lists from its children along with its own list, stores the result- ing list and then forwards it to its parent node. The process of aggregate, store and forward is repeated until the root node receives the full list for the whole WMN and then forwards it to the CM. The usefulness of this hierar- chical approach is: (i) Reducing communication overhead; and (ii) Fusing popularity information at different levels of the DBT helps distributing this information instead of collecting it by a central node.

b. For every object Om , the CM computes the global popularity Prm(τ ) according to Eq. (4.1). Prm(τ ) = PN i=1λmi(τ ) PN i=1 PM m=1λmi(τ ) (4.1)

c. The CM computes the number of replicas pm(τ + 1)for every object Om using Eq. (4.2).

pm(τ + 1) =

SC × N × Prm(τ ) |Om|

(4.2)

d. The CM creates a Replica-List (RL) that contains information about the objects’ replicas. The generated list structure is in the form of a 3-tuple hpm(τ +1), Om, |Om|i grouped by pm(τ +1)in a decreasing order and within each group, the objects are sorted by their size |Om| in a decreasing order. The reason behind this way of sorting is that we give priority for the highly popular objects and then the priority is given to the larger objects. Within a group of objects that have the same number of replicas, objects will have semi-equal popularity; prioritizing large objects would minimize the cost weighted by the object size given the storage constraint. However, our scheme is fair with small objects in terms of the computed number of replicas, since it divides the popularity of an object by its size (see Eq. (4.2)). This adopted approach of sorting was not considered in the schemes we compare our work with in this thesis and it cannot be adopted by such schemes. Therefore, they assume equal object size. In fact, our approach yields to different set of replicas and different number of replicas per object.

Replica assignment and placement

In this subsection, we describe our distributed replica placement heuristic (see Alg. 3). The heuristic has two sides. The first side is run by the CM and rep-

Algorithm 3:Pseudo code for the SP-DNA Heuristic.

1 foreach group ∈ RL do

2 multicast a message containing the group of object replicas to the

corresponding list of DNs in Map-List

3 end

4 upon receiving the message, a DN will do: 5 lookup the Map-List for the given pm(τ + 1)

6 if the node is flagged s then

7 forall the Om in the received group do

8 Fetch(Om)

9 end

10 else

11 forall the Om in the received group do

12 select the node that minimizes the cost:

13 M inPN

0 i0₌₁

PN0

j0₌₁P rmi0(τ )d_i0_j0 s.t ∃ SC

14 assign Omto the selected node

15 Fetch(Om)

16 end

resented by the first loop (lines 1 to 3). The second side is run by the DNs (lines 4 to 17). Based on the produced Replica List (RL), the CM multicasts a message for each group in the RL to the corresponding DNs obtained from the Map-List in the Network Setup Phase. The message multicast is performed using the Application Level Multicast (ALM). This is carried out in a decreasing order of the number of replicas pm(τ + 1) to prioritize objects with high popularity. The multicast message is in the form of a 3-tuple hpm(τ + 1), Om, |Om|i for each object in the group. Afterwards, each DN finds out from the Map-List whether it has to self-host or partition-host the objects in the received multicast message. If the node has to self- host (line 6) the listed objects, then it only needs to call the fetch function (line 8) to bring the needed object and store it. The description of the fetch function (Alg. 4) is discussed below. Otherwise (line 10), the case will be partition-host. The DN computes the total cost (line 13) for every partition member and assigns the object Omto the node that minimizes the total demand- weighted cost. The distance di0_j0 represents the shortest distance between i0and

j0. Note that the selected node must have enough storage for Om. Otherwise, the DN picks the second best node and so forth constrained by the storage limit.

Upon successful assignment, the selected node fetches the object replica using Alg. 4 by trying to find it locally (line 2). Upon a miss, it consults the Directory Service (e.g., Chord [17]) by sending the object’s key to obtain the list of nodes hosting it. If the object is found, the replica server requests it from the closest node. Upon a miss, it requests Om from the origin server. We note here that lines 13 and 14 refer to two separate updates. The first (line 13) is for the replica server to differentiate objects of the next period (τ + 1) from objects of the current period (τ ). The second (line 14) is used to update the Directory Service with the node ID hosting Omfor the next period (τ + 1). After fetching Om, the node evicts object(s) from previous τ and inserts Om for (τ + 1). We can observe that the

Algorithm 4:Function to fetch an object performed by the replica server node.

1 Function Fetch(Om)

2 if Omis in the node’s storage then

3 goto line 13

4 end

5 else if lookup(Om) → the Directory Service then

6 receive the list of nodes hosting Om

7 select the nearest hosting node for Om

8 fetch Omfrom the selected replica node

9 end

10 else

11 fetch Omfrom the origin server

12 end

13 update Om(τ + 1)

SP-DNA heuristic is not fully distributed as it depends slightly on the CM that acts as a Super-Peer [93]. However, the major burden is on the replica placement, which is performed by the DNs. This avoids the fully distributed approach that incurs excessive message overhead resulting from the exchange of popularity statistics between all the participating nodes.