forwarding. A selective-admittance local cluster routing scheme is implementable in a distributed way, as will be discussed in Section 5.9. This approach therefore solves the problem of overly large local clusters in a scheme where landmarks retain local clusters.
5.5
Distributed Landmark Selection
The Strowes [65] protocol selects a landmark set in a centralised, off-line manner, as described above in Section 5.3. The barrier to distributing this process lay in distributing the k-core graph decomposition. That problem has been solved in Chapter 4. How to solve the issue of excessive landmark state has been discussed in Section 5.4. Section 5.3 also discussed some generalisations of the processes and limits used by Strowes [65], Cowen [17] and Thorup and Zwick [68]. This chapter will go on to explain how to combine the distributed k-core algorithms with other distributed algorithms to obtain a fully distributed landmark selection process. Section 5.3 outlined a general process for landmark selection, where an initial landmark set is selected according to some ordered division, or partial-order, of the nodes such as the k-core graph decomposition. This initial set may then be
augmented with any remaining nodes whose clusters are overly large. The ordered division may be produced somewhat independently of the rest of the landmark selection process, or it may be carried out iteratively in conjunction with the landmark set process, such as in the Thorup and Zwick [68] process.
In the Distributed Landmark Routing protocol of this chapter, nodes each limit their local cluster routing table, regardless of whether they are chosen as
landmarks, for reasons explained in Sections 5.4 and 5.9. As a consequence, there is no need for this distributed landmark selection scheme to check local cluster size limits and take any steps to augment the landmark set with nodes with overly large local clusters, as the Cowen [17] and Thorup and Zwick [68] schemes do. To distribute initial landmark selection for a Cowen Landmark Routing protocol requires sufficient information to be made available at nodes to allow each to decide whether or not it is in the landmark set. That decision could be made in one of two ways:
• A node having sufficient information to be able to to directly test whether the pre-determined ˜O (Nx) bound on landmark set membership is still met if
the node itself were in the landmark set.
• A node being able to know that not having been given the information required to directly test the bound on landmark membership implied that it
Figure 5.3: High level overview of distributed landmark selection could not be a landmark.
These methods can be employed together in the same distributed landmark selection protocol.
The first approach requires knowledge of the node’s own rank in the ordered division, knowledge of the number of nodes in the network, and knowledge of the number of nodes in the ordered divisions being considered for the landmark set. The ordered division or partial-order used here is the k-core graph decomposition, as it gives good results on Internet graphs, as shown by Strowes [65]. How to distribute the calculation of the k-core graph decomposition has been explained in Chapter 4. The problem remaining then is how to count the network and the
k-cores, and distribute this across enough of the nodes (not necessarily all) such
that the nodes of the network can reliably determine whether or not they are landmarks.
Counting the nodes in the network in order to provide that knowledge can be achieved with a spanning tree over the network. A distributed spanning tree algorithm would allow each node to know its parent in the tree. The counts of the kmax of all the children of a node can be aggregated upwards to the root node, along the spanning tree. After which, the total counts of the number of nodes in each k-core can be distributed back down the tree, to each node. Section 5.7.5 gives a detailed example of how this counting protocol can work.
As the counts distribute down, each node can calculate whether or not it is in the initial landmark set. This calculation is made by a node v taking the size of the
k-core membership for its kmax(v), i.e. K (v) = |kmax(v)-core|, from the received k-core membership counts, and the total network size, N , and testing whether K (v) < ˜O (Nx), where ˜O (Nx) is a predetermined limit on the growth of the
5.5 Distributed Landmark Selection 129
landmark set.
If K (v) < ˜O (Nx) then the node v is in the initial landmark set.
On the other hand, if K (v) ≥ ˜O (Nx), then v is not in the initial landmark set. The node then may be able to refrain from distributing count information down the spanning tree on those branches where the highest kmax of any node on that branch is lower than the local node’s, as an optimisation.
An alternative scheme would be to have the root (which has the highest kmax) calculate the cut, on receiving the counts. It could simply propagate down along the spanning tree the value of the k-core which is the landmark set.
This alternative, of having the root communicate down only the cut would not allow nodes to verify the cut. As the calculation is unlikely to be onerous, and as the number of k-cores and hence the number of counts are limited in number, the costs of messaging all the counts are likely to be low. The transparency benefits of having at least each node in the landmark set be independently able to calculate membership may outweigh the communication overhead of the costs.
As the landmark set size grows only slowly relative to the size of the network, the calculations can easily be pre-computed and kept in table form. A form for the initial landmark set size bound to make calculating such tables easier, along with example code and table are given in Appendix B. If such tables are used, then the number of entries stored must be kept fixed relative to the network size, to keep the protocol compact. This can be done by updating the tables when the network grows, discarding entries no longer relevant due to the growth before adding new ones, as well as by using ranges of initial landmark set sizes. The range of each entry can grow with the network size.
The total network size (equivalent to the 1-core size) will still need to be
propagated down the spanning tree, even if the total k-core counts do not, in order to allow local cluster sizes to be limited. Cluster sizes can be bounded according to the original Cowen method by adding nodes with overly-large clusters (i.e., larger than the N1+α2 limit) to the landmark set. This only makes sense if landmarks do not keep local routing clusters. Alternatively, nodes need to limit their cluster sizes according to known size of the network, which will be the approach taken in this protocol.
Additionally, nodes may need to know N to limit the scope of local cluster routing messages sent. If nodes boot-strapped their local cluster routing protocol without knowing N , then they would have to allow these messages global scope, until such time as they learnt N . This would imply the overall protocol potentially required non-compact state in order to boot-strap.
By starting the spanning tree protocol first, and limiting the scope of the local cluster routing messages according to the bound on the known size of the network, the local cluster state can be kept compact even during bootstrap. As the spanning tree protocol converges and the known size increases, the local cluster routing scope can be increased accordingly.
A slight problem with the above network size counting scheme is that it is not compact. It requires at least some nodes to store max (kmax(v)) counts. Each count requires O (log N ) space, while max (kmax(v)) appears to scale with Θ (N ), Figure 4.6 on page 92 suggests. This implies O (N log N ) scaling of the counting state – which is not compact. That said, while max (kmax(v)) scales linearly with the number of nodes, it does so with a very low co-efficient of the order of 0.002 on Figure 4.6 on page 92. With such a low co-efficient, the k-core state will stay trivial compared to the (compact) routing state up to potentially quite high values of N . However, obviously, with enough growth the counting state would eventually approach and overtake the routing state.
Should the size of the counting state become an issue, this could be addressed by exchanging the undesired state for communication overhead. Rather than the root aggregating the counts for all k-cores at once, it could instead iteratively “call” for the counts of each k-core. The root could start with its own kmax-core and send a message down the tree asking to have the counts for that kmax-core to be
aggregated back up the tree to it. It could then repeated this for the count for the next k-core down. This process would be repeated until the root found the k-core that no longer was within the bound, implying the next higher k-core was the landmark set. With this, state would only have to kept for the count of 2 k-cores, which would be O (log N ) and compact.
A single counting protocol could easily incorporate both approaches. The root could use the communication-efficient, but ultimately non-compact approach initially so long as the counting state remained low compared to the routing state. Only when the counting state became onerous compared to routing state,
exceeding some arbitrary threshold, would the root need to switch to the state-efficient but communication-intensive approach. This would be compact.