Linear-Size Hopsets with Small Hopbound, and Distributed Routing with Low Memory
Michael Elkin, Ofer Neiman

TL;DR
This paper introduces a new construction of linear-size hopsets with significantly improved hopbound, enabling efficient distributed routing schemes with low memory and near-optimal tradeoffs.
Contribution
It presents the first linear-size hopset with nearly exponential hopbound and efficient PRAM and distributed algorithms for their construction, improving over previous exponential-size or high-hopbound methods.
Findings
Constructed linear-size hopsets with hopbound $( ext{log} n)^{ ext{log}^{(3)} n + O(1)}$
Developed PRAM algorithms with polylogarithmic running time for constant hopbound hopsets
Designed distributed routing schemes with near-optimal memory and stretch, and fast construction time
Abstract
For a positive parameter , the -bounded distance between a pair of vertices in a weighted undirected graph is the length of the shortest path in with at most edges, aka {\em hops}. For as above and , a {\em -hopset} of is a graph on the same vertex set, such that all distances in are -approximated by -bounded distances in . Hopsets are a fundamental graph-theoretic and graph-algorithmic construct, and they are widely used for distance-related problems in a variety of computational settings. Currently existing constructions of hopsets produce hopsets either with edges, or with a hopbound . In this paper we devise a construction of {\em linear-size} hopsets with hopbound $(\log…
Peer Reviews
No public reviews on file for this paper yet. If you reviewed it on a platform where reviews are public (OpenReview, ICLR, NeurIPS, ICML), you can paste yours below so the community can read it here.
Videos
No videos yet. Explain this paper in a talk, walkthrough, or lecture? Add one.
Linear-Size Hopsets with Small Hopbound,
and Distributed Routing with Low Memory
Michael Elkin This research was supported by the ISF grant No. (724/15). Department of Computer Science, Ben-Gurion University of the Negev, Beer-Sheva, Israel. Email: {elkinm,neimano}@cs.bgu.ac.il
Ofer Neiman Supported in part by ISF grant No. (523/12) and by BSF grant No. 2015813. Department of Computer Science, Ben-Gurion University of the Negev, Beer-Sheva, Israel. Email: {elkinm,neimano}@cs.bgu.ac.il
Abstract
For a positive parameter , the -bounded distance between a pair of vertices in a weighted undirected graph is the length of the shortest path in with at most edges, aka hops. For as above and , a -hopset of is a graph on the same vertex set, such that all distances in are -approximated by -bounded distances in .
Hopsets are a fundamental graph-theoretic and graph-algorithmic construct, and they are widely used for distance-related problems in a variety of computational settings. Currently existing constructions of hopsets produce hopsets either with edges, or with a hopbound . In this paper we devise a construction of linear-size hopsets with hopbound (ignoring the dependence on ) . This improves the previous bound almost exponentially.
We also devise efficient implementations of our construction in PRAM and distributed settings. The only existing PRAM algorithm [EN16a] for computing hopsets with a constant (i.e., independent of ) hopbound requires time. We devise a PRAM algorithm with polylogarithmic running time for computing hopsets with a constant hopbound, i.e., our running time is exponentially better than the previous one. Moreover, these hopsets are also significantly sparser than their counterparts from [EN16a].
We use our hopsets to devise a distributed routing scheme that exhibits near-optimal tradeoff between individual memory requirement of vertices throughout preprocessing and routing phases of the algorithm, and stretch , along with a near-optimal construction time , where is the hop-diameter of the input graph. Previous distributed routing algorithms either suffered from a prohibitively large memory requirement , or had a near-linear construction time, even on graphs with small hop-diameter .
1 Introduction
1.1 Hopsets
Consider a weighted undirected graph . Consider another graph on the same vertex set, that satisfies that for every , , where stands for the distance between and in . For a positive integer parameter , and a positive parameter , the graph is called a -hopset of , if for every pair of vertices , the -bounded distance between and in is within a factor from the distance between these vertices in , i.e., . The -bounded distance between and in is the length of the shortest -bounded --path in , i.e., of a shortest path with at most hops/edges.
Hopsets constitute an important algorithmic and combinatorial object, and they are extremely useful for approximate distance computations in a large variety of computational settings, including the distributed model [Nan14, HKN16, EN16a, EN16b, Elk17], parallel (PRAM) model [KS97, SS99, Coh00, MPVX15, EN16a], streaming model [Nan14, HKN16, EN16a, Elk17], dynamic setting [Ber09, HKN14], and for routing [LP15, EN16a]. The notion of hopsets was coined in a seminal paper of Cohen [Coh00]. (Though some first implicit constructions appeared a little bit earlier [UY91, KS97, SS99, Coh97].
In [Coh00], Cohen also devised landmark constructions of hopsets. Specifically, she showed that for any parameters , and , and any -vertex graph , there exists a -hopset with edges, with . Moreover, she showed that hopsets with comparable attributes can be efficiently constructed in the centralized and parallel settings. Specifically, in the centralized setting her algorithm takes an additional parameter , and constructs a hopset of size edges in time, with hopbound . In the PRAM model, her hopset has size , and is as above, and it is constructed in roughly (i.e., polylogarithmic time), and with work.
Cohen [Coh00] also raised the open question of existence and efficient constructability of hopsets with better attributes; she called it an “intriguing research problem”. In the two decades that passed since Cohen’s work [Coh00], numerous algorithms for constructing hopsets in various settings were devised [Ber09, HKN14, Nan14, MPVX15, EN16a]. The hopsets of [Ber09, HKN14, Nan14, HKN16] are no better than those of [Coh00] in terms of their attributes. (But they are constructed in settings to which Cohen’s algorithm is not known to apply.) The algorithm of [MPVX15] builds hopsets of size , but with a large hopbound . In [EN16a], the current authors showed that there always exist -hopsets of size , with constant (i.e., independent of ) hopbound . Abboud et al. [ABP17] showed a lower bound on the hopbound of hopsets with size .
In the PRAM model, [EN16a] showed two results. First, that for parameters and , hopsets with constant hopbound can be constructed in time , using work. Second, [EN16a] devised a PRAM algorithm with polylogarithmic time , albeit with a polylogarithmic roughly equal to the running time. The hopset’s size is in the second result as well.
These results of [EN16a] strictly outperformed the longstanding tradeoff of [Coh00] in all regimes, and proved existence of hopsets with constant hopbound. However, they left a significant room for improvement. First, the hopsets of [EN16a] have edges in all regimes. As a result, the only currently existing sparser hopsets [UY91, KS97, SS99, MPVX15] have hopbound of . Hence it was left open in [EN16a] if hopsets with size and hopbound exist. Second, the question whether hopsets with constant hopbound can be constructed in polylogarithmic PRAM time was left open in [EN16a]. Indeed, the hopsets’ algorithm of [EN16a] for constructing such hopsets requires PRAM time.
In this paper we answer both these questions in the affirmative. Specifically, we show that for any , there exists a -hopset, for all simultaneously, with size and . In particular, by setting , we obtain a linear-size hopset, and its hopbound is . This is an almost exponential improvement of the previously best known upper bound (due to [MPVX15]) on the hopbound of linear-size hopsets.
Second, in the PRAM setting, for any , , and , our algorithm constructs hopsets of size , constant hopbound , in polylogarithmic time , using work . This is an exponential improvement of the parallel running time of the previously best-known algorithm for constructing hopsets with constant hop-bound due to [EN16a]. We can also shave the factor in the size, that allows for a linear-size hopset, but then grows to be roughly the running time. See Table 1 for a concise comparison between existing and new results concerning hopsets in the PRAM model.
Our algorithm also provides improved results for constructing hopsets in distributed CONGEST and Congested Clique models (see Section 3 for definition of these models). In all these models, our algorithm constructs linear-size hopsets. Also, the running time of our algorithms in all these models is purely combinatorial, i.e., it does not depend on the aspect ratio of the graph. 111The aspect ratio of a graph is given by . In contrast, previous algorithms [Nan14, HKN16, EN16a] for constructing hopsets in the CONGEST model all have running time proportional to .
1.2 Distributed Routing with Small Memory
The main application of our novel hopsets’ construction is to the problem of distributed construction of compact routing schemes. A routing scheme has two main phases: the preprocessing phase, and the routing phase. In the preprocessing phase, each vertex is assigned a routing table and a routing label.222In this paper we only consider labeled or name-dependent routing, in which vertices are assigned labels by the scheme. There is also a large body of literature on name-independent routing schemes; cf. [AGM*+*08] and the references therein. However, a lower bound [LP13] shows that constructing a name-independent routing scheme with stretch requires time in the CONGEST model. See also [GGHI13] for lower bounds on the communication complexity of the preprocessing phase of distributed routing. In the routing phase, a vertex gets a message with a short header and with a destination label of a vertex , and based on its routing table , on , and on , the vertex decides to which neighbor to forward the message , and which header to attach to the message. The stretch of a routing scheme is the worst-case ratio between the length of a path on which a message travels, and the graph distance between the message’s origin and destination.
Due to its both theoretical and practical appeal, routing is a central problem in distributed graph algorithms [PU89, ABNLP90, TZ01b, Cow01, EGP03, GP03, AGM04, Che13]. A landmark routing scheme was devised in [TZ01b]. For an integer , the stretch of their scheme is , the tables are of size , the labels are of size , and the headers are of size . Chechik [Che13] improved this result, and devised a scheme with stretch , and other parameters like in [TZ01b].
An active thread of research [ABNLP90, AP92, LP13, GGHI13, LP15, EN16b] focuses on efficient implementation of the preprocessing phase of routing in the distributed CONGEST model, i.e., computing compact tables and short labels that enable for future low-stretch routing. This problem was raised in a seminal paper by Awerbuch, Bar-Noy, Linial and Peleg [ABNLP90], who devised a routing scheme with stretch , overall memory requirement ,333-notation hides polylogarithmic in factors. individual memory requirement for a vertex of , and construction time (in the CONGEST model). The “individual memory requirement” parameter encapsulates the routing tables and labels, and the memory used while computing the tables and labels.
Lenzen and Patt-Shamir [LP15] devised a distributed routing scheme (based on [TZ01b]) with stretch , tables of size , labels of size , individual memory requirement of , and construction time , where is the shortest-path diameter of the input graph , i.e., the maximum number of hops in a shortest path between a pair of vertices in . Though is often much smaller than , it is desirable to evaluate complexity measures of distributed algorithms in terms of and , where is the hop-diameter of , defined as the maximum distance between a pair of vertices in the underlying unweighted graph of . Typically, we have , and it is always the case that . (See Peleg’s book [Pel00] for a comprehensive discussion.)
Lenzen and Patt-Shamir [LP13] also devised a routing scheme with tables of size , labels of size , stretch at most , and has running time of rounds. They (based on [SHK*+*12]) also showed a lower bound of on the time required to construct a routing scheme. In a follow-up paper, [LP15] showed how to improve the stretch of the above scheme to . The main drawback of this result is the prohibitively large size of the routing tables. (The individual memory requirement is consequently prohibitively large as well.) They also exhibited a different tradeoff, that overcame the issue of large routing tables. They devised an algorithm that produced routing tables of size , labels of size and stretch , albeit with sub-optimal running time , and no guarantee on the individual memory requirement during the preprocessing phase. In [EN16b], the current authors improved the bounds of [LP13, LP15]. In the current state-of-the-art scheme [EN16b], the stretch is , the tables and labels are of the same size as in [LP13, LP15] (i.e., and , respectively), the construction time is . (A similar, though slightly weaker, result was achieved by [LPP16].) Still there is no meaningful guarantee on the individual memory requirement in the preprocessing phase. See Table 2 for a concise summary of existing bounds, and a comparison with our new results.
To summarize, all currently existing distributed routing algorithms with nearly-optimal running time suffer from three issues. First, they provide no meaningful guarantee on individual memory requirement on vertices in the preprocessing phase; second, their preprocessing time is not purely combinatorial, but rather depends linearly on ; and third, their tables and labels sizes are roughly off from the respective tables and labels’ sizes of Thorup-Zwick’s sequential construction [TZ01b].
The issue of individual memory requirement was indeed explicitly raised by Lenzen [Len16] in a private communication with the authors. He wrote (the stress on “during” is in the origin):
“One annoying thing about this is that there is a huge amount of storage required during the construction. It seems odd that the nodes can hold only small tables, but should have large memory during the construction. I think it’s an interesting question whether we can have a good construction using memory only. A hop set may be the wrong option for this, because reflecting the distance structure of the skeleton accurately cannot be done by a sparse graph; on the other hand, maybe there’s some distributed representation cleverly distributing the information over the graph nodes?”
Based on our novel hopsets’ construction, we devise an algorithm that addresses all these issues. Specifically, the stretch of our scheme is , the sizes of tables and labels essentially match the respective sizes of Thorup-Zwick’s construction, i.e., they are and , respectively. Our construction time is , i.e., it is purely combinatorial. Most importantly, the individual memory requirement is at most . Moreover, we can reduce the running time to , while the individual memory increases slightly to . In particular, we can have a polylogarithmic individual memory requirement and construction time , for an arbitrarily small constant .
Distributed Tree Routing: An important ingredient in the existing distributed routing schemes [LP15, EN16b] for general graphs, and in our new routing scheme, is a distributed tree routing scheme. Thorup and Zwick [TZ01b] showed that with routing tables of size and labels of size , one can have an exact (i.e., no stretch) tree routing. [LP15, EN16b] showed that in time, one can construct exact tree routing with tables and labels of size and , respectively, i.e., there is an overhead of in both parameters with respect to Thorup-Zwick’s sequential construction. In this paper we improve this result, and devise a -time algorithm that constructs tree-routing tables and labels of sizes that match the sequential construction of Thorup and Zwick, i.e., of size and , respectively. Moreover, if one is interested in a scheme that always routes via the root of the tree, as is the case in the application to routing in general networks, then our algorithm for constructing tables and labels that supports this requires only a small () individual memory in each vertex.
1.3 Technical Overview
Cohen’s algorithm [Coh00] is based on a subroutine for constructing pairwise covers [Coh93, ABCP93], i.e., collections of small-radii clusters with small maximum overlap (no vertex belongs to too many clusters). The algorithm is a top-down recursive procedure: it interconnects large clusters of the cover via hopset edges, and recurses in small clusters. To keep the overall overlap of all recursion levels in check, Cohen used the radius parameter for the covers. This resulted in a hop-bound, which is at least polylogarithmic in . Cohen’s hopset is also built separately for each distance scale , , and the ultimate hopset is the union of all these single-scale hopsets.
The hopset’s construction of [EN16a], (due to the current authors), also builds a single-scale hopset for each distance scale, and then takes their union as an ultimate hopset. The construction of single-scale hopsets in [EN16a] is based upon ideas from the construction of -spanners of [EP04] for unweighted graphs. It starts with a partition of the vertex set into singleton clusters , and alternates superclustering and interconnection steps. In a superclustering step some of the clusters of the current partition are merged into larger clusters (of ), while the other clusters are interconnected with one another via hopset edges.
This approach (of [EN16a]) enabled us to prove existence of hopsets with constant hop-bound, but it appears to be uncapable of producing hopsets of size . Indeed, even if each single-scale hopset is of linear size (which is indeed the case in [EN16a]), their union is doomed to be of size . Moreover, in parallel and distributed settings, one produces a hopset based upon a hopset of scale . This results in accumulation of stretch from to . To alleviate this issue, one needs to rescale . However, then the hopbound grows from constant to polylogarithmic. To get around this, [EN16a] used a smaller number of scales, and this indeed enables [EN16a] to construct hopsets with constant hopbound in these settings, albeit the running time becomes proportional to the ratio between consequent scales, i.e., it becomes .
The closest to our current construction of hopsets is the line of research of [Ber09, HKN14, HKN16, Nan14], which is based on a construction of distance oracles due to Thorup and Zwick [TZ01a]. To construct their oracles, [TZ01a] used a hierarchy of sets , where each vertex of , for all , is sampled with probability for the inclusion into . For each vertex , [TZ01a] defined for every , the th pivot to be its closest vertex in , and the th bunch , (for , let ), and the entire bunch . They also defined the dual sets, clusters, . Bernstein and others [Ber09, HKN14, Nan14, HKN16] used this construction with , and built Thorup-Zwick clusters with respect to -bounded distances. As a result, they obtained a so-called -bounded hopset, i.e., a hopset which takes care only of pairs of vertices that admit a -bounded shortest path. They then used this bounded hopset in a certain recursive fashion (see the so-called hop reduction of Nanongkai [Nan14]), to obtain their ultimate hopset.
Thorup-Zwick’s construction with alone introduces into the hopset edges, and thus, such a hopset cannot be very sparse. In addition, the recursive application of the hop reduction technique results in a hopbound of .
Our construction of hopsets is based upon a construction of Thorup-Zwick’s emulators444A graph is called a sublinear-error emulator of an unweighted graph , if for every pair of vertices , we have for some sub-linear stretch function . If is a subgraph of , it is called a sublinear-error spanner of ., from a different paper by Thorup and Zwick [TZ06]. Specifically, to obtain the hierarchy , one samples each vertex of , for , with probability roughly for inclusion in . Then one defines the bunch of a vertex as , and sets
[TABLE]
For unweighted graphs , [TZ06] showed that given by (1) is an additive emulator with stretch and edges. By a different proof argument, we show that the very same construction provides also a -hopset of the same size and with , for all simultaneously. Moreover, by adjusting the sampling probabilities, we also shave the factor from both the hopset’s and the emulator’s size, while increasing the exponent of by 1. (This also gives rise to the first linear-size emulator with sub-linear additive stretch for unweighted graphs.)
As a result, we obtain a construction of hopsets, which is by far simpler than the previous Thorup-Zwick-based constructions of hopsets [Ber09, HKN14, Nan14, HKN16]. As was discussed above, it also provides hopsets with much better parameters, and it is more adaptable to efficient implementation in various computational settings. Our construction is also much simpler than the constructions of [Coh00, EN16a], which are not based on Thorup-Zwick’s hierarchy.
Parallel and distributed implementations of our hopset’s construction proceed in scales , where on scale the algorithm constructs a -bounded hopset. This is different from the situation in [Coh00, EN16a, Nan14, HKN16], where scale takes care of distances in the range . An important advantage of this is that we no longer need to take the union of all single-scale hopsets into our hopset; rather we just take the largest-scale hopset as our ultimate hopset. This saves a factor of in the size, and enables us to construct linear-size hopsets in parallel and distributed settings. The fact that we do not work with distance scales, but rather with hop-distance-scales, makes it possible to avoid the dependence on in the distributed construction time, and to achieve a purely combinatorial running time. All previous distributed algorithms for constructing approximate hopsets [Nan14, HKN16, EN16a] have running time proportional to . (A distributed construction of an exact hopset [Elk17] by the first-named author, however, avoids this dependence too. Alas, it has a much higher running time.)
The fact that the construction’s scales are with respect to hop-distances, as opposed to actual distances, enables us to essentially avoid accumulation of error. This is done by the following recursive procedure. First, we build -bounded hopsets , , and set to be the highest-scale hopset. This process involves accumulation of stretch, and after rescaling the stretch parameter , the hopset ends up having polylogarithmic hopbound . Its construction time is roughly , i.e., polylogarithmic as well. Now we add the hopset into the original graph, and recurse on . Note that now we only need to process scales, rather than ones. Hence the accumulation of stretch in the resulting hopset is much more mild than in . As a result, after rescaling the stretch parameter , the hopbound of is roughly . By repeating this recursive process for iterations, we eventually achieve a hopset with constant hop-bound in parallel polylogarithmic time. As was mentioned above, this dramatically improves the parallel time required in [EN16a] to construct a hopset with constant hopbound.
In the context of distributed routing, like in [LP15, EN16b], our hopset is constructed on top of a virtual (aka skeleton) graph , where is a collection of vertices, sampled from the original vertex set independently with probability . There is an edge iff there is a -bounded path in . However, since we aim to design an algorithm in which vertices employ only a small memory during the preprocessing phase, we cannot afford computing the virtual graph . Rather, somewhat surprisingly, we show that the hopset for can be constructed without ever constructing itself! We only compute those edges of , which are required for constructing the hopset .
Note, however, that unlike a spanner or a low-stretch spanning tree, hopset is always used in conjunction with the graph for which it was constructed. In other words, to compute the Thorup-Zwick routing scheme for the virtual graph , we conduct Bellman-Ford explorations in . So, at the first glance, it seems necessary to eventually compute , for being able to conduct these Bellman-Ford explorations.
We cut this gordian knot by computing only those edges of that are really needed for computing either the hopset or the TZ routing scheme for . This turns out to be (typically) a small fraction of edges of , and those edges can be computed much more efficiently than the entire , and using much smaller memory. This idea also enables us to compute lengths of these edges of precisely, as opposed to approximately, as it was done in [LP15, HKN16, EN16b]. This simplifies the analysis of the resulting scheme. We note that the idea of computing a hopset without first computing the underlying virtual graph , and conducting Bellman-Ford explorations in without ever computing in its entirety appeared in a recent work [Elk17], by the first-named author. [Elk17] constructed an exact hopset of [SS99, Nan14] with a polynomial hopbound. However, the exact hopset is a much simpler structure than the small-hopbound approximate hopset that we construct here. Showing that this idea is applicable for our new approximate small-hopbound hopset is technically substantially more challenging.
Another crucial idea that we employ to guarantee a small individual memory requirement is ensuring that our hopset has small arboricity, i.e., that its edges can be oriented in such a way that every vertex has only a small out-degree. This out-degree is proportional to the ultimate individual memory requirement of our algorithm.
1.4 Organization
Our linear-size hopsets appear in Section 2, and the distributed construction in Section 3.1 for Congested Clique and Section 3.2 for the CONGEST model. The hopsets in the PRAM model are presented in Section 4. Finally, in Section 5 we describe our distributed routing scheme with small memory, and the distributed tree routing in Section 5.1.
2 Linear Size Hopsets
Let be a weighted graph, and fix a parameter . Let (one should think of ). Let be a sequence of sets, such that for all , is created by sampling every element from independently with probability .555Our definition is slightly different than that of [TZ06], which used , but it gives rise to the same expected size of . We use our version since it allows efficient implementation in various models of computation. It follows that for we have
[TABLE]
and in particular .
For every and every vertex , define the pivot as a vertex satisfying (note does not exist for ), and define the bunch
[TABLE]
The hopset is created by taking , where the length of the edge is set as . As argued in [TZ01a], for any and , the size of is bounded by a random variable sampled from a geometric distribution with parameter (this corresponds to the first vertex of , when ordered by distance to , that is included in ). Hence . For we have . The expected size of the hopset is at most
[TABLE]
The following lemma bounds the number of hops and stretch of . Recall that is the length of the shortest-path between in that consists of at most edges.
Lemma 1**.**
Fix any and any . Then for every , at least one of the following holds:
. 2. 2.
There exists such that .
Proof.
The proof is by induction on . We start with the basis . If it is the case that , then we added the edge to the hopset, i.e. , and so the first item holds. Otherwise, consider the case that : then we can take , so the second item holds trivially. The remaining case is that and , so by definition of we get that . By taking , there is a single edge between in of length , which satisfies the second item.
Assume the claim holds for , and we prove for . Consider the path between in , and partition it into segments , each of length at most , and at most edges of between these segments. This can be done as follows: define , and for , walk from on (towards ) until the point , which is the vertex so that the next edge will take us to distance greater than from (or until we reached ). By definition, . Define to be the neighbor of on that is closer to (if exists). If does not exist (which can happen only when ) then define and . Observe that for all , , so indeed .
We use the induction hypothesis for all pairs with parameter . Consider first the case that the first item holds for all of them, that is, . Then we take the path in that consists of the -hops between each pair , and the edges of . Since , we have
[TABLE]
The second case is that there are pairs for which only the second item holds. Let (resp., ) be the first (resp., last) index for which the first item does not hold for the pair (resp., ). Then there are such that
[TABLE]
(Note that we used and not in the second inequality. This can be done since the lemma’s assertion holds for the pair as well, and as the first item is symmetric with respect to , it does not hold for the pair as well.) Consider now the case that . In this case we added the edge to the hopset, and by the triangle inequality,
[TABLE]
Next, apply the inductive hypothesis on segments for and , and in between use the detour via . Since , there is at least one segment we skipped, so the total number of hops is bounded by . (The additive term of accounts for the edges , .) This expression is at most whenever . It follows that
[TABLE]
This demonstrates item 1 holds in this case. The final case to consider is that . Assume first that . Then taking , the definition of implies that . We now claim that item 2 holds for such a choice of . Indeed, since , we have
[TABLE]
where the last inequality used that . The case that is simpler, since we may take . ∎
Fix any , and apply the lemma on any pair with and . It must be that the first item holds (since ). Hence we have that
[TABLE]
where the number of hops is given by . We derive the following theorem.
Theorem 1**.**
For any weighted graph on vertices, and any , there exists of size at most , which is a -hopset for any with .
2.1 Improved Hopset Size
Here we show how to remove the factor from the hopset size, at the cost of increasing the exponent of by an additive 1. Note that we may assume w.l.o.g that , as for larger values of , both and the size of the hopset (which becomes ), grow with . We will increase the number of sets by 1, and sample using the following probabilities: (the restriction on ensures ). Now for ,
[TABLE]
and in particular . The expected size of becomes at most
[TABLE]
The hopset construction and the stretch analysis in Lemma 1 remains essentially the same. There is an additional sampled set now, and thus the exponent of grows by an additive 1.
Theorem 2**.**
For any weighted graph on vertices and any , there exists of size at most , which is a -hopset for any with .
Since our construction is based on the [TZ06] emulator construction, following their analysis we obtain an emulator with additive stretch that can have linear size.
Corollary 2**.**
For any un-weighted graph on vertices and any , there exists an emulator of size at most , with additive stretch for pairs at distance .
2.2 Efficient Implementation
We consider the construction and notation of Section 2.1, with the slightly stronger assumption .
It was (implicitly) shown in [TZ01a] that for any , the sets (and the corresponding distances) for all can be computed in expected time . (In fact, in [TZ01a], the set contains more vertices, not only those in . However, we can remove the extra vertices easily.) The running time becomes larger as grows, and in order to keep it under control, we use the method of [EN16a]: introduce a parameter , and redefine the probabilities as follows. Set and . For , let as in Section 2.1. Set also , and for the remaining levels , set . Finally, let . Note that for , we have that
[TABLE]
In particular, using that , we get
[TABLE]
(The last inequality uses that . Thus , and so that .) Thus for any we see that
[TABLE]
The expected number of edges inserted until phase is at most
[TABLE]
The expected number of edges at phase is bounded by
[TABLE]
The remaining phases until introduce at most
[TABLE]
as this summation converges. Finally, since
[TABLE]
the last phase contributes at most edges to the hopset. We conclude that the total number of edges is .
Recall that the expected running time of the Dijkstra explorations at level is . Thus the expected running time of the first levels converges to , while each of the at most remaining levels will take also time. The final level is expected to take as well, since there are expected vertices at from which Dijkstra is performed. The price we pay is in a higher number of sets, which increases the exponent of by at most an additive . The following result summarizes the discussion.
Theorem 3**.**
For any weighted graph on vertices, and any , , there is a randomized algorithm that runs in expected time , and computes an edge set of size at most . This edge set is a -hopset for any , where
[TABLE]
By substituting , we obtain an improved version of the hopsets of [EN16a], where both the size of the hopset and the running time are smaller by a factor of , while the other parameters remain the same. Another notable advantage is that it yields a single hopset which works for all simultaneously.
Corollary 3**.**
For any weighted graph on vertices, and any , , there is a randomized algorithm that runs in expected time , and computes of size at most , which is a -hopset for any , where
[TABLE]
3 Distributed Models
We will consider two standard models in distributed computing: the Congested Clique model, and the CONGEST model. In both models every vertex of an -vertex graph hosts a processor, and the processors communicate with one another in discrete rounds, via short messages. Each message is allowed to contain an identity of a vertex, an edge weight, a distance in the graph, or anything else of no larger (up to a fixed constant factor) size.666Typically, in the CONGEST model only messages of size bits are allowed, but edge weights are restricted to be at most polynomial in . Our definition is geared to capture a more general situation, when there is no restriction on the aspect ratio. Hence results achieved in our more general model are more general than previous ones. The local computation is assumed to require zero time, and we are interested in algorithms that run for as few rounds as possible. In the Congested Clique model, we assume that all vertices are interconnected via direct edges, while in the CONGEST model, every vertex can send messages only to its -neighbors (the weight of edges is irrelevant to the communication time).
3.1 Congested Clique Model
We first show how to construct the hopset in the Congested Clique model. In order to avoid a high number of rounds when computing distances for determining the bunches , we built the hopset in levels, where each level hopset will only ”take care” of pairs that have a shortest path with at most hops. This is somewhat different from previous works [Coh00, Nan14, HKN16, EN16a], in which the level hopset handled pairs with distance in the range . A few advantages of our current approach: it easily avoids the dependency on the ratio between largest and smallest distance, and also the final hopset is just the level one, so we can obtain a linear size hopset (unlike previous works which took the union of all levels).
There are a few technical difficulties in implementing the algorithm of Section 2 in a distributed setting. The first is that the [TZ01a] method for computing the bunches was to compute their ”inverses” – called clusters.777The cluster is defined as follows: each point iff . Alas, it is not known how to compute these clusters in a distributed manner when errors are allowed. Rather, we compute the bunches directly, and to avoid the potential large congestion (a vertex may be a part of many bunches, and needs to send messages for all of them), we replace the bunches with half-bunches (i.e., taking only points closer than half the distance to the pivot). See below for the formal definition. The second issue (of congestion) is more subtle, and arises since hop-bounded distances do not obey the triangle inequality. For the stretch analysis to go through, we need that the weight of the hopset edges will be bounded by a certain path between the end-points of the edge (see (3.1)). In order to ensure that this happens, we build each hopset for level gradually, i.e. the bunches are created first for , then for and so on, where each time the partial hopset is added to the graph on which we compute distance.
We say that is a -hopset if provides approximation with at most hops for all pairs such that (i.e., the pairs that have a shortest path consisting of at most edges between them). Note that the empty set is a -hopset (and thus also a -hopset for all and ). Given a -hopset , we build a -hopset , where for some . The final hopset will be . (We stress that the previous hopsets are only used to compute , and are not contained in it.)
Observe that is a -hopset, since every path with at most hops can be partitioned into two paths of at most hops each, and provides a approximation with hops for each of these. It follows that for any ,
[TABLE]
We sample sets as in Section 2.2, where is the number of sets. We introduce a subtle change to the construction – in the previous section we defined for each a set , and added the edges for all , simultaneously for all . Here we shall build the hopset gradually: For each we define a set of edges corresponding to the bunches of vertices in , and finally take .
Fix some , and assume we built the set (when define ). We shall work in the graph , defined by
[TABLE]
The algorithm consists of two stages. On the first stage, for rounds, run a Bellman-Ford exploration in rooted at , to obtain for each the value . (If some vertex was not found in the exploration, then we set .) Also for each vertex with , store as a vertex satisfying .
To determine the bunches (this is the second stage), each vertex conducts another Bellman-Ford exploration in the graph rooted at , this time for only rounds, i.e., half the number of hops of the first exploration, to distance less than (i.e., the messages whose origin is contain the value , and only vertices within this distance from forward the message in the next round). Define the half-bunch . Let
[TABLE]
and set the weight of the edge as the distance discovered in the exploration (i.e., for and for the pivot).
Claim 4**.**
.
Proof.
The argument is essentially the same as the one in Section 2.2. The only difference is that when analyzing in step the expected size of a bunch, i.e., for some , we consider the ordering on given by the -bounded distance from in the graph , i.e., according to . Then the size of is bounded by the index of the first vertex in this ordering that is included in . Since every is included in independently with probability , we have that . In fact, may have a smaller size than the first index included in , since we use more hops for computing distances to pivots (which reduces the distance threshold for being in ), and since we only take into the bunch points that are less than half the distance to the pivot. Finally, for the last level we have that for , . Combining this with bounds on in Section 2.2 we can bound the size of in the same manner. ∎
In fact, since is stochastically bounded by a geometric distribution with parameter , it follows that with high probability for all ,
[TABLE]
Claim 5**.**
The number of rounds required is whp .
Proof.
The sampling of the sets is done independently for each vertex, therefore it requires no communication. For each and , we conduct a single Bellman-Ford exploration in rooted at for rounds. Since in the Congested Clique model all edges are present, this requires rounds per exploration (every vertex sends just a single message to all its neighbors every round). The more expensive step is the explorations to range rooted at each . The number of rounds in these explorations is affected by the number of messages a vertex needs to forward to its neighbors at each round. In what follows we prove that with high probability this number is at most for every .
Fix . Consider , and order the vertices of according to their -bounded distance to in , that is, according to . Since , the probability that none of the first vertices in that ordering is sampled to is at most
[TABLE]
So by the union bound on the vertices, with high probability, for each at least one of the first vertices in its ordering of is sampled to . Denote by the first vertex in the ordering of that was chosen to . We claim that no vertex , that appears after in the ordering of , will cause to forward messages concerning . This is because in the first stage we performed the Bellman-Ford exploration rooted at for rounds. Thus
[TABLE]
where the last inequality uses the assumption that appeared after in ’s ordering. We obtained . So by the definition of half bunch, and thus, will not forward ’s messages.
We still have to argue about the last level (since no vertex is chosen to ). Recall that the expected size of is bounded by , as shown in (8). It can be easily checked that whp . (Recall that .) We conclude that whp, every vertex needs to send at most messages to implement a single step of Bellman-Ford. There are rounds for each and each , so the total number of rounds required is . ∎
Next, we prove an analogue of Lemma 1 for the distributed setting. There are several subtle differences described in the beginning of this section. So we provide a complete proof that addresses these subtleties.
Lemma 6**.**
Fix any , set , and let be such that . Then for every , at least one of the following two assertions holds:
. 2. 2.
There exists such that .
Proof.
The proof is by induction on . We start with the base case . If it is the case that then we can take and the second item holds trivially. Otherwise, consider the case that and . Then we added an edge to of weight (the case that is similar, replacing by ). Recall that . Hence
[TABLE]
so the first item holds. The last case is that and . By definition of , it must be that
[TABLE]
Since , the edge is in the hopset, and its weight is
[TABLE]
where for the last two inequalities we again used (9) and the fact that . (The latter holds since we assume and , so ). This proves the second item with .
Assume the claim holds for , and we prove for . Consider the shortest path between in that contains at most edges, and partition it into segments as in the proof of Lemma 1. We use the induction hypothesis for all pairs with parameter . (By the virtue of lying on a shortest path that has at most edges, all these pairs satisfy ). Consider first the case that the first item holds for all of them, that is, . Then we take the path in that consists of the -hops between each pair , and the edges of . Since by (10), , we have
[TABLE]
which concludes the proof for the first case. The second case is that there are pairs for which only the second item holds. Let (resp., ) be the first (resp., last) index for which the first item does not hold for the pair (resp., ). Then there are such that
[TABLE]
Consider first the case that . Then we take , and derive
[TABLE]
where in the second inequality we used that the first item holds for all intervals until the -th one, and in the final one that and .
From now on assume . Recall that the Bellman-Ford explorations that constructed were conducted in the graph . These explorations were conducted to hop-depth on the first stage, and on the second. This allows us to provide the following bound:
[TABLE]
Here the first inequality follows by the triangle inequality, the second uses that , that lie on a shortest path with at most hops, and that is a hopset.
Consider the case that , then we have a hopset edge that was introduced in . In particular, since we used steps in the exploration from , we have that
[TABLE]
Next, apply the inductive hypothesis on segments for and , and in between use the detour via . Since there are at most intervals for which we use the first item in the inductive hypothesis, the total number of hops we will need is at most . This is at most whenever . It follows that
[TABLE]
In the penultimate inequality we used that both . This demonstrates that item 1 holds in this case.
The final case to consider is that (and ). Let . Since , the definition of implies that
[TABLE]
(Recall that .)
We now claim that item 2 holds for such a choice of . Indeed, by (13), we have
[TABLE]
Hence,
[TABLE]
where the last inequality we used that , and , so that both and . ∎
Taking and picking , the second item of Lemma 6 cannot hold for any (because ), so we have for every such that that
[TABLE]
Recall that . Rescaling and taking , we derive the following theorem.
Theorem 4**.**
For any weighted graph on vertices, an integer , and parameters , , there is a distributed algorithm in the Congested Clique model running in rounds, that computes a -hopset of size at most , where
[TABLE]
Remark 1**.**
We note that by (11) and Claim 5, the memory requirement from every vertex is . This is because the latter shows that this is a bound on the number of messages every vertex needs to send in each round, and the former indicates that whp storing for any requires only so much space.
We remark that one can achieve independent of by either applying the construction recursively, as we do in Section 4 for the parallel implementation, or by using an idea from [EN16a]. We next describe the latter: fix a parameter , and use the hopset to compute the hopset ; Since is also a -hopset, we need explorations to range in order for an appropriate variant of (9) to hold. There will be only levels until is built, so we gain a factor of in . We derive the following result.
Theorem 5**.**
For any weighted graph on vertices, integers , , and parameters , , there is a distributed algorithm in the Congested Clique model that runs in rounds, and computes of size at most , which is a -hopset, where
[TABLE]
In particular, taking and rescaling , gives
Corollary 7**.**
For any weighted graph on vertices, an integer , and parameters , , there is a distributed algorithm in the Congested Clique model that runs in rounds, and computes of size at most , which is a -hopset, where
[TABLE]
3.2 CONGEST Model
Given a weighted graph representing the network, in the CONGEST model we will be interested in a setting where there is a ”virtual” graph embedded in , i.e., . We would like to construct a hopset for . It is motivated by distributed applications of hopsets for approximate shortest paths computation, distance estimation and routing [HKN14, Nan14, HKN16, LP15, EN16b, EN16a], which require a hopset for a virtual graph embedded in the underlying network in the above way.
In a similar manner to [EN16a], we can modify our algorithm in the Congested Clique model to the CONGEST model. The following lemma provides a way to perform Bellman-Ford exploration using small memory.
Lemma 8**.**
Let be a virtual graph on vertices embedded in a graph of hop-diameter , such that edges in correspond to -bounded distances in , and has arboricity (i.e., one can orient the edges of to have out-degree at most ). Moreover, every vertex knows at most its outgoing edges in . Then one can compute iterations of Bellman-Ford in in the CONGEST model within rounds, so that every vertex requires only memory.
Proof.
To implement a single iteration of the Bellman-Ford exploration, every vertex , which holds a current distance estimate, will need to communicate it to its neighbors in . First, it will initiate an exploration in for rounds. In each round, every vertex will forward the smallest value it received so far. This guarantees that if , then will receive ’s message (or a smaller value).
We now have to handle the edges of . Let be a spanning tree of with hop-depth . Every will broadcast via its value to the entire graph, and will also send all the existing edges of incident on it that knows about. All vertices that know of a hopset edge (or that learn about it from ’s message) will update their value accordingly. Since there are messages, this can be done in rounds. In order to guarantee small internal memory, each selects at random a number from for each message it sends, as a round to start its broadcast (clearly this increases the number of rounds by at most ). Since each message of will reach every vertex of at most once, the probability that some receives messages in a single round is at most . Thus, with high probability, no vertex will receive more than messages each round. By increasing the number of rounds by , whp there will be no congestion. The total number of rounds required is thus . ∎
We now show how to use Lemma 8 to construct a hopset for , in the setting where are edges corresponding to -bounded distances in (without computing explicitly). Recall that in the th iteration of constructing , we have already built the previous hopset and the partial hopset . Since we desire limited memory, every vertex stores only the ”outgoing” hopset edges, those to vertices in its bunch . Recall that by (11), whp , for all .
We work in the graph . In order to implement the -bounded exploration rooted at (the second stage of the th iteration), we simply apply Lemma 8 on with . The explorations from vertices of (the second stage of the th iteration) are done in a similar manner. However, there is a larger congestion than in the first stage, due to the multiple sources of limited explorations. Recall that in the limited exploration whose origin is , each intermediate node forwards the message iff its current estimate is strictly less than (this value is part of the message sends). We enforce the exact same rule for vertices as well. If a message concerning should pass in from to its neighbor , then all vertices on the -bounded path in that implements the edge will have estimates smaller than that of , therefore will forward the message on. In the proof of Claim 5 we saw that each participates whp in at most explorations for each iteration . The argument is identical for as well, so the congestion induced in the first stage of Lemma 8 (the exploration in for rounds) by multiple sources is only . Note that in the second phase (broadcasting the edges of ), the number of messages increases to . Thus, the total number of rounds required is still . We summarize the discussion with the following result.
Theorem 6**.**
For any weighted graph with hop-diameter , an integer , and parameters , , and (an implicit) virtual graph embedded in on vertices, there is a distributed algorithm in the CONGEST model that runs in rounds, that computes , which is a -hopset for , of size at most , where
[TABLE]
Remark 2**.**
In the case that corresponds to -bounded distances in , the hopset can be computed where every vertex has internal memory .
Path-reporting Hopsets:
Every hopset edge is implemented via some path in . For our application to routing, we would like that every vertex on a path implementing a certain hopset edge will be aware of this hopset edge. This means that for every hopset edge , there exists a path in of length , and every vertex knows about the hopset edge, and the distances , , and its neighbors on . It was shown in [EN16a] how to adapt the Bellman-Ford exploration, so that paths information can be stored as well, at a cost of increasing the size of messages by a factor of . However, there was no guarantee on the number of hopset edges a vertex can be a part of, which can be devastating when one desires small memory per vertex. We describe now an approach that eliminates the need for the message’s size increase, and also ensures that each vertex belongs to a bounded number of paths that implement hopset edges. The issue that may cause a vertex to be in a path for many hopset edges, is that we use previous hopsets to construct a new one. Then the vertices implementing paths in these previous hopsets may not be discovered by the current explorations. So the argument of Claim 5 bounding the number of explorations that visit a certain vertex does not apply as is.
In order to guarantee that every will need to store information for only hopset edges, we need to slightly change the construction. First, we will define , so that every hopset will contain all the previous hopsets. (Recall that in our algorithm in Section 3.1 that computes non-path-reporting hopsets, we only used lower-scale hopsets to compute a higher-scale one. Once the mission of lower-scale hopsets was completed, they were ruthlessly erased.) Second, rather than performing the exploration from in steps, we apply Lemma 8 with steps of Bellman-Ford. Note that in the proof of correctness we only used that there are at least steps. Using more steps will only increase the number of rounds (by a poly-logarithmic factor). Recall that when computing the hopset at phase , we have already computed , and work in the graph . We can now argue that whp, there will not be too many hopset edges whose path in contains . The intuition is that the exploration from has sufficiently many hops in order to discover this , and so an argument similar to the one of Claim 5 will apply.
Fix , and order the vertices of in increasing order according to their distance to , where the distance from to is the shortest path consisting of at most edges of and then at most edges of . Let be the first vertex in that order that is included in . We claim that the vertex cannot belong to a path that implements a hopset edge , such that is after in the ordering of .
Consider how the path is built. One can initially start with , and then recursively replace the hopset edge in that contains , with the -bounded path in some that induces it. Note that this recursion depth is at most , thus has at most edges. Since contains all the edges of all previous hopsets, the exploration from starting at for steps would have reached after edges of (the edges of are an edge of , and thus of as well), and then after additional edges of , it would have surely have reached (because is closer to than ). We conclude that
[TABLE]
which is a contradiction to the fact that joins .
Next, we have to show that each will indeed learn the relevant information on all hopset edges it implements. Assume inductively that for any hopset edge , if is the path in that implements this edge, then every knows about the edge, , , and its neighbors on . A new hopset edge is created whenever the exploration rooted at discovers a vertex . Recall that this exploration is done in for rounds. Whenever joins it will send an acknowledgement on the -bounded path back to in (every vertex discovered by takes note of its ”parent”, the vertex who sent it the message of ). The acknowledgement phase can take place after the exploration concludes, and it will induce congestion that is no larger that the congestion created when sending the messages, so the number of rounds will at most double. Now, every vertex in the -bounded path from to that receives ’s acknowledgement, knows that the edge to its parent is part of the path implementing the hopset edge . Recall that the edge is either an edge of , which is discovered via a -round exploration in – in which case all vertices along the path in from to can update the relevant information about when does a -round exploration in (this is the acknowledgement step), or otherwise . In the latter case, will broadcast that the edge implements , and its distances to . By the induction hypothesis, each vertex that implements a path for the hopset edge knows about it and its distances to , thus when hears this broadcast (which is sent to all vertices of ), it knows it implements , and can computes distances to and .
We conclude that whp every vertex needs to store only the hopset edges that it implements. Note that the final hopset can omit all the previous hopsets (which were used only for calculations). We summarize this discussion with the following theorem.
Theorem 7**.**
For any weighted graph with hop-diameter , an integer , and parameters , , and (an implicit) virtual graph embedded in on vertices, there is a distributed algorithm in the CONGEST model that runs in rounds, that computes , which is a path-reporting hopset for , of size at most , where
[TABLE]
In the case that corresponds to -bounded distances in , the hopset can be computed where every vertex has internal memory .
4 PRAM Model
The algorithm described in Section 3.1 can be easily adapted to the PRAM model. For each , we build the hopset based on the previous hopset . Each of the -bounded Bellman-Ford explorations for constructing can be implemented in parallel in rounds, where the congestion of per vertex translates to extra work (rather than multiplying the number of rounds, as was the case in distributed models). Since there are values of , and steps in each level, the number of rounds is only . We have the following result.
Theorem 8**.**
For any weighted graph on vertices, an integer , and parameters , , there is a parallel algorithm running in rounds and has work, that computes of size at most , which is a -hopset, where
[TABLE]
We can also apply the construction recursively: If is the hopset given by Theorem 8 with given in (19), then apply the construction on the graph , but only for levels up to , to obtain a hopset . Since for any we have , then adding both and guarantees , where , where is the constant hidden by the notation in (19). This bound follows because needs to be rescaled by ; the rescaling by is to compensate for the number of levels, and by 3 to reduce the error from back to . Continuing in this manner for the next level with levels, we obtain in general a recursion for , and it can be shown by induction that as long as we have
[TABLE]
After at most iterations, we get that . To summarize, this yields a hopset with constant parameter that is computed in rounds.
Theorem 9**.**
For any weighted graph on vertices, an integer , and parameters , , there is a parallel algorithm running in rounds and has work, that computes of size at most , which is a -hopset, where
[TABLE]
5 Distributed Routing with Small Memory
Here we improve the results of [EN16b, LPP16], and devise a compact routing scheme that can be efficiently implemented in a distributed network. The previous result of [EN16b] provides, for any parameter , a scheme with stretch , labels of size and routing tables of size . The computation time of this scheme is rounds (in the CONGEST model). One drawback of this result (and also of [LPP16], which obtained slightly weaker results), is that although the final memory requirement from each vertex is , the preprocessing step requires high memory (at least ). Indeed, some of the classical works on compact routing schemes [ABNLP90] addressed the issue of each vertex having only a limited memory throughout the construction of the routing scheme (albeit their round complexity was at least linear in ). Here we present a distributed construction that has that desirable property, and in addition we improve both the label and table size by a logarithmic factor, almost matching the best known bounds of [TZ01a, Che13] that are computed in a sequential manner.
We briefly sketch the approach of [EN16b], and the current improvement allowing low memory and improved bounds. First, construct the Thorup-Zwick hierarchy , where each vertex in is sampled to independently with probability . Then the cluster for can be viewed as tree rooted at . Computing this cluster is done by a limited Dijkstra exploration from , i.e., only vertices in continue the exploration of . Routing from to is done by finding an appropriate cluster containing both , and routing in that tree. Whenever , these trees have whp depth . Hence they can be easily computed in a distributed manner within rounds. The main issue is computing the clusters for .
The method of [EN16b] was to work with a virtual graph , whose vertices are , and whose edges correspond to -bounded distances in between the vertices of . Then a hopset is computed for this virtual graph, which enables the computation of Bellman-Ford explorations in only rounds. The fact that -bounded distances can suffer stretch creates additional complications; one needs to define approximate clusters, and make sure that these approximate clusters correspond to actual trees in . Finally, since the trees corresponding to for the high level vertices , , can have large depth, one needs to adapt the Thorup-Zwick routing scheme for trees [TZ01b]. In both [EN16b, LPP16] this adaptation induced a logarithmic factor to both the table and the label size.
Our improved result has two main ingredients. First, we do not explicitly construct ; In both [EN16b, LPP16], computing the weights of edges in was a rather expensive step, and required large memory and induced a factor depending logarithmically on the aspect ratio to the running time. In addition, only approximate values were obtained. We observe that not all the edges of are required for the algorithm, and thus we do not compute at all. Rather we compute only those edges of that are really needed for either the hopset or for the routing hierarchy. (This idea is reminiscent of [Elk17], where the virtual graph is also never entirely computed.)
Instead, we conduct the explorations in by implementing in each iteration a -bounded search in , which not only saves memory and running time, but also simplifies the analysis, since now there is no error in the edge weights of . Second, our new tree-routing scheme has both improved label and routing table size, and can be computed with small memory. (For more details, see Section 5.1.) Our result is summarized below.
Theorem 10**.**
Let be a weighted graph with vertices and hop-diameter , and let be a parameter. Then there exists a routing scheme with stretch at most , labels of size and routing tables of size , that can be computed in a distributed manner within rounds, such that every vertex has memory of size .
Alternatively, whenever , the number of rounds can be made with memory at each vertex.
In particular, taking for a small constant yields rounds with memory per vertex.
Construction of Routing Scheme.
Let be a weighted graph, fix . Sample a collection of sets , where for each , each vertex in is chosen independently to be in with probability . A point is called an -pivot of if . The cluster of a vertex is defined as
[TABLE]
It was shown in [TZ01a] that
Claim 9**.**
With high probability, each vertex is contained in at most clusters.
We recall a few definitions from [EN16b]. For each and , a point is called an approximate -pivot of if
[TABLE]
Define
[TABLE]
The approximate cluster will be any set that satisfies the following:
[TABLE]
It was shown in [EN16b] that once we obtain approximate clusters as trees of , with , and provide a routing scheme for these trees, it implies a routing scheme for with stretch . In fact, it suffices that the routing scheme for each tree always routes through the root of the tree, not necessarily via the shortest path in the tree.
Let denote the number of vertices on the shortest path from to in . The following were also shown in [EN16b] to hold with high probability.888For the sake of simplicity we will assume is even. For odd , we can improve the running time by a factor of .
Claim 10**.**
For any with , there exists a vertex of on the shortest path between them.
Claim 11**.**
For any , and , it holds that .
In particular, for we can find the ”exact” cluster for each , by a simple limited Bellman-Ford exploration from all such vertices to hop-depth . By Claim 9, the congestion induced at each by the merit of being a part of many clusters is only . So the total number of rounds required is , and each vertex needs to store at most words (the clusters containing it). Finally, note that these clusters indeed correspond to trees, since every vertex can store as a parent the vertex who last updated the distance estimate that has for .
From now on we consider the high levels, where . Define as a virtual graph where , and corresponds to -bounded distances in . Observe that Claim 10 implies that for any (because any shortest path in has a vertex of within any hops on that path). First, we compute a -hopset for the virtual graph as in Theorem 7, with parameters , and . If one desires the second assertion of the Theorem 10, pick . Note that the graph is implicit, and every node has internal memory . Since whp, the number of rounds required to compute is at most (recall and ).
Approximate Pivots
To compute the approximate pivots, conduct a Bellman-Ford exploration to depth in , as in Lemma 8, rooted in , to compute for each a value . We perform another -bounded exploration in , where initially every vertex sends its current estimate, and in every step every vertex forwards the smallest value it has heard so far. We claim that every will learn of an approximate ()-pivot . To see this, let be the ()-pivot of . If , then will hear ’s message in the last -bounded exploration. Otherwise, by Claim 10, there exists a vertex on the shortest path from to within hops from , and since is a -hopset, we have that the first rounds of Bellman-Ford exploration from caused to update . In the final exploration to range , the vertex will communicate this value on the path towards . Thus, will have a value at most
[TABLE]
where the last inequality used that . This follows since lies on the shortest path from to the nearest vertex of . We conclude that no matter which is the approximate pivot of , the distance estimate that has for it cannot be larger than . Computing the approximate pivots requires rounds.
Approximate Clusters
Fix some , and for each we conduct a limited Bellman-Ford exploration in for rounds rooted at , as in Lemma 8. By “limited”, we mean that any vertex receiving a message originated at , will forward it to its neighbors iff the current distance estimate is strictly less than . We will refer to this condition, the inclusion condition of the exploration of . We need to avoid congestion at intermediate vertices during the -bounded exploration in described in Lemma 8, so these vertices will also need to implement some sort of limitation. Concretely, vertices will forward ’s message iff their current estimate is strictly less than . The exploration over edges of is done as before, where Claim 9 guarantees every vertex participates in clusters (we will soon show that the approximate clusters are indeed contained in the clusters), so this bounds the number of rounds required by . Also the memory per vertex required from this computation is bounded by (the number of cluster containing the vertex).
This exploration constructs a virtual tree rooted at . For every edge on this tree, we add to the cluster all the vertices in on the -bounded path from to . This can be done via an acknowledgement message from back to on this path, and every vertex updates its parent accordingly. For every hopset edge of the tree (which was broadcast to the entire graph during the exploration), every vertex , where is the path in implementing the edge , joins the tree ( knows about being a part of this edge by the path-reporting property of our hopset), and sets its distance estimate as if this value is smaller than its current estimate. If this is the case, the vertex also sets its parent as the neighbor on which is closer to .
Finally, we perform another limited Bellman-Ford exploration to depth in , where every vertex in the tree of sends its current distance estimate, and every vertex will forward the smallest estimate it heard so far, but iff it is strictly less than . In that case it will also join the approximate cluster of , and will update its parent as its neighbor in whose message caused to update its distance estimate to for the last time.
Observe that the same vertex may join a tree more than once, due to several edges in whose paths contain it. In such a case the vertex will have as a parent the vertex which minimize the estimated distance to the root. Since every vertex has a single parent, we will have that the approximate cluster of , , is indeed a tree. It remains to prove (24). Let be the distance estimate that has to in the exploration rooted at .
Claim 12**.**
For any , .
Proof.
Consider any . If it is the case that joined the approximate cluster by the exploration rooted at , either by being in or on a -bounded path in that implements an edge of , then it must satisfy . Now,
[TABLE]
so indeed . The other case is that for a path implementing a hopset edge that was added to the virtual tree. Since joins the approximate cluster, it must satisfy . Recall that the weight of the hopset edge is the weight of the path from to in that lies on. Hence . It follows that
[TABLE]
where in the penultimate inequality we used the fact that the vertex knows , and thus it could have updated its distance estimate to as (note that it may have used a smaller estimate). Thus in this case, as required. ∎
The next claim proves the second inequality of (24).
Claim 13**.**
For any , .
Proof.
Let . We would like to show that . Consider the shortest path from to in . Then by Claim 10, there is a vertex on that is within hops from . Notice that
[TABLE]
Hence too.
We will show that the limited exploration originated at will reach , and in the final depth exploration it will reach and include it in .
Since is a -hopset, there is a path in from to that contains at most edges that satisfies
[TABLE]
Let be any vertex on that lies hops from , . Then after steps of Bellman-Ford exploration from we have that
[TABLE]
(We used that .) We conclude that satisfies the inclusion condition for the exploration rooted at , and forwards the message of onwards. In particular, by (27), . In the final phase we make a Bellman-Ford exploration for rounds in from each vertex that received the message of . Thus, will start such an exploration with distance estimate . Consider the subpath from to . We have to show that every vertex on this path forwards the message of , that is, that it satisfies the inclusion condition of the exploration of . Let be such a vertex. Since this is a shortest path in , we have
[TABLE]
as required.
∎
5.1 Distributed Tree Routing with Small Memory
In this section we present our compact routing scheme for trees that can be computed in a distributed manner using small internal memory. In previous constructions of distributed routing schemes for trees [EN16b, LPP16], the internal memory was as high as , and it was also somewhat inefficient: the label size is and the routing tables are of size . Compare this to the classical [TZ01b] tree routing, which has label size and routing tables of size .
We follow the basic framework of previous works, by selecting a set , such that each vertex is sampled to independently with probability ( is a parameter, which we shall optimize later). Fix a tree on vertices with root . The vertices partition the tree into subtrees, by removing the edges from each vertex in to its parent. Each of the subtrees is rooted in a vertex of . Denote by the subtree rooted at . We also consider , the virtual tree on the vertices of , which is rooted at , and contains an edge if the parent of lies in . It is not hard to see (e.g., [EN16b]) that whp the depth of each is , and that .
In both [EN16b, LPP16], routing schemes were created for each , and also a routing scheme for the virtual tree . This computation required large internal memory, since had to locally compute the scheme for . The inefficiency in the size was due to the fact that when routing in , traveling over a virtual edge , one has to route in from to the parent of . This seems to require storing additional routing information for this subtree, increasing both label and table size by a logarithmic factor. We overcome this issue by storing routing information only with respect to the actual tree, while applying pointer jumping techniques to quickly compute the full labels. However, we do not know how to construct exact tree routing with small memory. Fortunately, to implement our routing scheme for general graphs, it suffices to provide a root-tree routing scheme, where the routing is always done via the root of the tree , and not necessarily via the shortest path. (We stress that using larger memory, we can compute exact tree routing tables and labels within rounds, with label size and routing tables of size , substantially improving previous results.)
Before describing our approach, let us briefly recall the Thorup-Zwick construction of tree routing. The idea is to assign to every (non-leaf) vertex its heavy child, which is the child whose subtree has maximal size. Note that the subtree of any non-heavy child of contains at most half of the vertices of the subtree of rooted at . For this reason, any path from the root to some contains at most non-heavy edges. For an exact routing scheme they also conducts a DFS search in that assigns to each the DFS entry and exit times for its subtree. The label of is these entry and exit times, and also the names of the non-heavy edges on the to path. The routing table consists of the DFS times, the name of the heavy child, and the name of the parent of in the tree. The routing towards a target in the tree is done as follows. At any intermediate vertex , if is not in the subtree rooted at (this can be checked via the DFS times), then forwards to its parent. If is in the subtree, inspects ’s label to see if an edge appears there. If this is the case, it forwards to , otherwise to its heavy child. Note that if one desires root-tree routing then there is no need to implement a DFS – initially route to the parent until the root is reached, and then follow the path using heavy edges unless the label indicates otherwise.
Now we show how to implement our scheme in a distributed manner, and with internal memory. First, every sends a message about itself to the vertices of , informing them they are in . Note that this message will arrive to all vertices in who are children of in the virtual tree , so they will know their parent. Next, for each , every vertex in sends to its parent the size of the subtree rooted at it, beginning with the leaves. Every vertex that received messages from all its children, sums up the values and sends to its own parent. This can be done in parallel for all trees for , and will take (the bound on the height of each ) rounds.
For a vertex in a tree , rooted at a vertex , and a positive integer , we say that a vertex is an -ancestor of , if lies on the unique path in at distance from .
We would like that every will know the entire size of the subtree of rooted at . Initially, we compute this value only for the virtual vertices of . For a vertex , its subtree size is exactly the sum of sizes of subtrees for that are in the subtree of rooted at . Note that computing these values from the leaves of up will not be efficient, since every message on a virtual edge may require rounds, and the depth of may be as large as (which will be approximately ). Thus, this results in rounds. To alleviate this issue, we use the following ”pointer jumping” technique. Initially, set for the current size , and its first ancestor as its parent in (and for the root , set ). For rounds, every vertex will broadcast in the th round (using the BFS tree of ), the current size and the name of its -ancestor in . Then whenever hears a message that some broadcasts with , then adds to its current size . In addition, the vertex hears the message of , and it updates as . (It could be the case that . In this case, indeed, .) We claim that this process correctly computes for any the size of the subtree of rooted at . It can be shown by induction on , that before the th round, is the size of the subtree rooted at that contains at most vertices of on any root-leaf path. There are messages sent on each round for rounds. Hence, it will take rounds to implement this step.
In order to compute , the size of the subtree of rooted at , for all , every informs its parent in with the value . Then once again, for every in parallel, the leaves of start to send to their parent their current size. This time, some of these leaves and internal vertices could be parents of vertices in , so these sizes are the actual subtree size in . In rounds, every vertex will know . After sending these values to the parents, every vertex can infer who is its heavy child.
The label needed for root-tree routing is just the collection of edges that are on the path in , such that is not the heavy child of . Clearly, there can be at most such edges on this path, because the size of the subtree decreases by a factor of 2 for every non-heavy edge. If , we start by computing a partial label that contains non-heavy edges on the path from to . This can be done by initializing , and starting at , any vertex which received a label , sends to its heavy child, and for any non-heavy child . These labels are also sent to the children of in (recall that these are the vertices whose -parents belong to ). Once this computation is completed, every vertex knows the non-heavy edges on the path from , its parent in , to . We again apply pointer jumping to compute the full labels. For , every vertex of will broadcast in the th round its current label. In each round, when hears the message from its -ancestor (recall that computed previously its -ancestors, for all , and it stored them in its internal memory), it will update . Once again, it can be proved by induction on that before the th round, every knows all the non-heavy edges on the path in from to (or from the root to if ). Since every label has size , this will require rounds. Finally, in another rounds, each sends its updated label to every vertex , and they update their label by appending .
If one desires a routing scheme for a single tree, just take , so the running time will be . If we desire to compute a routing scheme in parallel for multiple trees, but have the guarantee that every belongs to at most trees, then we can use the argument as in [EN16a] to obtain running time (rather than the naive ). We conclude by formally summarizing our result.
Theorem 11**.**
For any tree on vertices, lying in a network with hop-diameter , there exists a distributed algorithm in the CONGEST model running in rounds, that computes a root-tree routing scheme with label size and routing tables of size , such that every vertex uses only words of memory throughout the computation.
Moreover, if there are no restriction on the memory used throughout the computation, then exact tree routing tables of size and labels of size can be computed in time.
In addition, given a network with vertices and a set of trees so that each vertex is contained in at most trees, one can compute a root-tree routing scheme as above for all trees in parallel, within rounds, while using memory at each vertex.
Acknowledgements
We wish to thank Christoph Lenzen for raising to us the problem of distributed routing with small individual memory requirements, and for permitting us to use a quotation from [Len16].
The reference list from the paper itself. Each links out to its DOI / PubMed record.
- 1[ABCP 93] Baruch Awerbuch, Bonnie Berger, Lenore Cowen, and David Peleg. Near-linear cost sequential and distribured constructions of sparse neighborhood covers. In 34th Annual Symposium on Foundations of Computer Science, Palo Alto, California, USA, 3-5 November 1993 , pages 638–647, 1993.
- 2[ABNLP 90] Baruch Awerbuch, Amotz Bar-Noy, Nathan Linial, and David Peleg. Improved routing strategies with succinct tables. J. Algorithms , 11(3):307–341, September 1990.
- 3[ABP 17] Amir Abboud, Greg Bodwin, and Seth Pettie. A hierarchy of lower bounds for sublinear additive spanners. In Proceedings of the Twenty-Eighth Annual ACM-SIAM Symposium on Discrete Algorithms, SODA 2017, Barcelona, Spain, Hotel Porta Fira, January 16-19 , pages 568–576, 2017.
- 4[AGM 04] Ittai Abraham, Cyril Gavoille, and Dahlia Malkhi. Routing with improved communication-space trade-off. In Distributed Computing, 18th International Conference, DISC 2004, Amsterdam, The Netherlands, October 4-7, 2004, Proceedings , pages 305–319, 2004.
- 5[AGM + 08] Ittai Abraham, Cyril Gavoille, Dahlia Malkhi, Noam Nisan, and Mikkel Thorup. Compact name-independent routing with minimum stretch. ACM Trans. Algorithms , 4(3):37:1–37:12, July 2008.
- 6[AP 92] B. Awerbuch and D. Peleg. Routing with polynomial communication-space tradeoff. SIAM J. Discrete Mathematics , 5:151–162, 1992.
- 7[Ber 09] Aaron Bernstein. Fully dynamic (2 + epsilon) approximate all-pairs shortest paths with fast query and close to linear update time. In 50th Annual IEEE Symposium on Foundations of Computer Science, FOCS 2009, October 25-27, 2009, Atlanta, Georgia, USA , pages 693–702, 2009.
- 8[Che 13] Shiri Chechik. Compact routing schemes with improved stretch. In ACM Symposium on Principles of Distributed Computing, PODC ’13, Montreal, QC, Canada, July 22-24, 2013 , pages 33–41, 2013.
