1: \documentclass[10pt,letterpaper]{article}
2:
3: \usepackage{mascots04,epsfig,amsmath,amssymb,url,bibspacing,tweaklist}
4:
5: \setlength{\textfloatsep}{3pt}
6: \setlength{\intextsep}{0pt}
7:
8: \setlength{\dbltextfloatsep}{0pt}
9: \setlength{\dblfloatsep}{0pt}
10:
11: \setlength{\abovedisplayskip}{0pt}
12: \setlength{\belowdisplayskip}{0pt}
13:
14: \renewcommand{\itemhook}{\setlength{\topsep}{0pt}
15: \setlength{\itemsep}{0pt}}
16:
17: \renewcommand{\leq}{\leqslant}
18: \renewcommand{\geq}{\geqslant}
19:
20: \begin{document}
21:
22: \title{
23: Toward Compact Interdomain Routing
24: }
25:
26: \author{
27: Dmitri Krioukov \and kc claffy \\
28: CAIDA \\
29: \{dima,kc\}@caida.org
30: }
31:
32: \maketitle
33:
34: \begin{abstract}
35:
36: Despite prevailing concerns that the current Internet interdomain
37: routing system will not scale to meet the needs of the 21st century
38: global Internet, networking research has not yet led to the
39: construction of a new routing architecture with satisfactory and
40: mathematically provable scalability characteristics. Worse,
41: continuing empirical trends of the existing routing and topology
42: structure of the Internet are alarming: the foundational principles
43: of the current routing and addressing architecture are an inherently
44: bad match for the naturally evolving structure of Internet
45: interdomain topology. We are fortunate that a sister discipline,
46: theory of distributed computation, has developed routing algorithms
47: that offer promising potential for genuinely scalable routing on
48: realistic Internet-like topologies. Indeed, there are many recent
49: breakthroughs in the area of {\em compact routing}, which has been
50: shown to drastically outperform, in terms of efficiency and
51: scalability, even the boldest proposals developed in networking
52: research. Many open questions remain, but we believe the
53: applicability of compact routing techniques to Internet interdomain
54: routing is a research area whose potential payoff for the future of
55: networking is too high to ignore.
56:
57: \end{abstract}
58:
59: \section{Introduction}
60:
61: The relentless growth of the Internet has brought with it
62: inevitable, and inextricable, economic and social dependence
63: on this infrastructure. In reality, the dependence is mutual:
64: without a robust source of economic support, the Internet will be
65: unable to evolve toward the potential it quite imaginably holds.
66: We believe that we will soon be faced with a critical
67: architectural inflection point in the Internet. Most experts
68: agree\footnote{See~\cite{NanogScalability,huston01-03,huston01-02,griffin-wired,routing-requirements}
69: for few examples.}
70: that the existing data network architecture is severely stressed
71: and reaching its capability limits. The evolutionary dynamics of
72: several critical components of the infrastructure suggest that the
73: existing system will not scale properly to accommodate even
74: another decade of growth. While ad hoc patches, some of them
75: quite clever, have offered temporary relief, both the research and
76: operational communities concur that a fundamental top-to-bottom
77: reexamination of the routing architecture is requisite to a
78: lasting solution.
79:
80: In this paper we set to work on such reexamination. We clarify up front
81: that we adhere to standard scientific reductionism
82: in this work: given a complex system---existing interdomain routing---that
83: we want to fix, we seek to decompose it into constituents that
84: we can tackle one-by-one, since each constituent problem
85: has a chance of admitting formalization and rigorous solution.
86: We can then construct the final
87: solution---a future Internet routing architecture---from the solutions
88: to subproblems. The constituent problem we will
89: examine in this paper is routing scalability, though it is
90: well-established that scalability is only one of many
91: problems of the current Internet routing architecture.\footnote{Other
92: problems include security, isolation,
93: configuration control, etc. See~\cite{routing-requirements} for a long
94: list of future routing architecture requirements.}
95:
96: More specifically, we analyze the fundamental causes of the global
97: interdomain routing scalability problems, and how they imply the need for
98: dramatically more efficient routing algorithms with rigorously
99: proven worst-case performance guarantees. Fortunately, such algorithms
100: exist---they
101: are known collectively as {\em compact routing}. But before we
102: review these techniques (Section~\ref{sect:compact_routing}),
103: we first reduce Internet scalability problems to compact
104: routing formalism. In Section~\ref{sect:scalability} we will peel
105: off the surface layers of the complexity of the current interdomain
106: routing system to reveal the roots of its scalability inefficiencies.
107: One of the serious practical concerns with compact routing is that
108: it does not guarantee the use of shortest paths: it ``stretches'' them.
109: We discuss the stretch of a routing
110: algorithm in Section~\ref{sect:stretch}, and contrast it
111: with more familiar forms
112: of path-length inflation in today's interdomain routing. This discussion
113: naturally leads to our explanation of why {\em hierarchical routing\/} will
114: not scale if deployed in the Internet (Section~\ref{sect:noscale}).
115: After we survey the history of compact routing in
116: Section~\ref{sect:compact_routing},
117: we analyze the key aspects of its applicability to Internet
118: interdomain routing in Section~\ref{sect:applicability}. Such analysis
119: yields an outline of future work in this area. We conclude
120: in Section~\ref{sect:conlcusion} with a vivifying summary.
121:
122: \section{Routing scalability}
123: \label{sect:scalability}
124:
125: Poor scaling of a routing protocol expresses itself in terms
126: of rapid (linear) rates of growth of the routing table~(RT) size
127: as well as convergence parameters (convergence time, churn,
128: instabilities, etc.). In this paper we concentrate on the
129: subproblem associated with the former component, but we also
130: discuss the latter in Section~\ref{sect:applicability}.
131:
132: The immediate causes of Internet RT growth have been extensively
133: studied and analyzed~\cite{huston01-03,huston01-02,BroNeCla02,NaGoVa03}.
134: Several studies, proposals, and even new routing architectures seek to
135: directly address these causes. Prominent efforts in this area
136: include~\cite{beyond-bgp,atoms,multi6,islay,nimrod} and most
137: recently~\cite{GuKoKi04,SuKaEe05}.
138: However, we argue that even if
139: we could manage to deploy any of the proposed approaches, it would
140: represent only a short-term patch, because they address
141: symptoms rather than the root of the problem. It is empirically
142: clear that the Internet needs more than a short-term fix.
143:
144: As an example, we consider the idea of
145: {\em routing on AS numbers}, where AS numbers replace IP prefixes
146: in the role of interdomain routing addresses.
147: This idea is now a common part of many
148: proposals~\cite{atoms,islay,nimrod,GuKoKi04,SuKaEe05}.
149: At first glance routing on AS numbers looks like a final
150: solution to the RT size problem. Indeed, such an approach
151: could immediately reduce the RT size by an order of magnitude,
152: since there are an order of $10^5$ IP prefixes and $10^4$ ASs
153: in the global RT today. However, even if a protocol implementing
154: this idea were deployed, there is no reason to believe it would
155: change the empirically observed trend\footnote{In the existing Internet,
156: the total number of ASs grows faster than the total number of IP
157: prefixes~\cite{huston-bgp-site,BroNeCla02}.}
158: that an increasing number of small (stub) networks want to participate
159: in interdomain routing, e.g., for traffic engineering reasons,
160: and to do so they require their own interdomain routing addresses
161: (AS numbers). Such small networks utilize tiny portions of
162: the public IP address space,
163: which implies that inevitably the total number of ASs will
164: continue to grow at roughly the same rate as the total number
165: of IP prefixes, and we will soon face, albeit a few years later,
166: essentially the same problem we have today.
167:
168: \begin{figure}[t]
169: \centering
170: \includegraphics[width=3in]{scaling.eps}
171: \caption{\footnotesize {\bf Constant-factor improvement vs.~better scaling.}
172: Scalability means effective scaling, not a one-time reduction.
173: Although the difference in impact between alternatives to
174: the existing architecture may be small today, in the long run
175: a constant factor reduction is negligible compared to the
176: performance gain from a genuinely scalable solution.
177: Any solution that scales in essentially the same way as
178: the existing architecture is only postponing the problem.
179: \label{fig:scaling}}
180: \end{figure}
181:
182: We learn two important lessons from this example. The first is of
183: general significance: {\bf when considering scalability aspects of a
184: new routing architecture, what matters is not any one-time improvement
185: it produces, but how well it scales}. A routing protocol that yields
186: a constant reduction in RT size but the same rate of growth does not
187: actually solve the RT size problem, it simply postpones it.
188: Figure~\ref{fig:scaling} illustrates this consideration: as
189: network size grows, the difference between the current architecture
190: and an architecture providing a constant-factor improvement becomes
191: negligible. No less important is the {\em mathematical provability\/}
192: of the protocol's scaling behavior. In the case of RT size
193: such provability implies rigorously derived worst-case (upper) bounds
194: of the RT size as a function of the network size.
195: The fact that we face interdomain routing scalability problems
196: today is at least in part due to the lack of any rigorous performance
197: guarantees embedded in the BGP design. We should not repeat the same
198: mistake in the future.
199:
200: The second lesson is more specific: organization (AS) boundaries do
201: offer a natural level of aggregation and abstraction of routing
202: information. It would be thus unexpected to neglect such a possibility
203: for RT size reduction. Indeed, we adopt the idea of routing on AS
204: numbers, and the natural level of network topology abstraction we
205: consider in our work is thus the {\em Internet AS-level topology graph}.
206:
207: Furthermore, faithful to our reductionistic spirit, we temporarily
208: avoid discussing routing policies. T.~Griffin {\it et al.}'s independent
209: scope of work focuses specifically on policy-related problems.
210: In addition, one design goal of their latest abstract routing
211: protocol model~\cite{GriSo05} is explicit modularity with respect to
212: the routing {\em algorithm\/} and {\em policy\/} components of the
213: protocol.\footnote{Note
214: the difference between terms {\em routing protocol\/} and
215: {\em routing algorithm}.
216: The algorithm is a part of a protocol. In BGP case, for example, the protocol
217: is BGP itself, while algorithm is path-vector.}
218: Thus we believe that our work on the algorithmic component
219: can proceed in parallel and virtually independently of the
220: vitally important policy-related research. Satisfactory
221: results in both domains would powerfully position the
222: research community to offer a complete solution.
223:
224: To summarize this section, we assert that in order to find sustainable
225: solutions to the global Internet routing problem, we need to
226: investigate the scalability issues at their most fundamental level.
227: For interdomain routing the framing question appears to be the
228: performance guarantees of routing algorithms operating on graphs with
229: topologies similar to the Internet AS-level topology. In particular,
230: we are interested in rigorous upper bounds of the RT size.
231: It turns out that compact routing is
232: exactly what we are looking for:
233: a research area focused on construction of efficient routing algorithms with
234: proven worst-case performance guarantees. However, before we describe compact
235: routing, we need to discuss stretch.
236:
237: \section{Routing stretch}
238: \label{sect:stretch}
239:
240: The {\em stretch} of a routing algorithm
241: is defined as a worst-case multiplicative path-length increase factor.
242: More specifically, for every pair of nodes in all graphs
243: in the set of graphs the algorithm can operate on,
244: we find the ratio of the length of the path produced by the
245: algorithm to the length of the shortest path between the same pair
246: of nodes. The maximum of this ratio among all node pairs in all
247: the graphs
248: is the algorithm's stretch.
249: The average stretch is the average of this ratio on a subset of graphs.
250:
251: We emphasize that {\bf stretch has nothing in common with known
252: forms of path inflation} in contemporary Internet
253: routing. Path inflation is today's Internet is {\em not\/} due to the non-trivial
254: stretch of an underlying routing algorithm, but rather due to
255: intra- and inter-domain routing policies, various incongruities
256: across multiple levels of network topology abstraction
257: (geographical, router-, AS-level), etc.~\cite{SprMaAn03}
258:
259: In fact, we are not aware of any currently used routing protocol
260: that would implement a routing algorithm with stretch greater
261: than~1 (stretch$>$1): link-state (LS) in OSPF or ISIS,
262: distance-vector (DV) in RIP, LS/DV hybrid in EIGRP, and path-vector in
263: BGP are all forms of
264: {\em trivial}\footnote{The word {\em trivial} is not a judgment
265: but a reference to {\em trivial shortest-path
266: routing\/} in Section~\ref{sect:compact_routing}.}
267: shortest-path routing (stretch-1). Consider two examples:
268: BGP and OSPF. Non-trivial policy configurations generally
269: prevent BGP from routing along the actual shortest path,
270: but without policies the BGP route selection process
271: would always select the shortest paths in the AS-level graph.
272: Similarly, non-trivial area configurations prevent OSPF
273: from routing along the shortest paths, but routing inside
274: an area is always along the shortest path in the weighted router-level graph.
275:
276: The above examples seem straightforward but we identify them
277: to eliminate any possible confusion between stretch of a
278: routing {\em algorithm\/} and inflation of paths produced by a routing
279: {\em protocol}. Clarifying the difference allows us to formulate
280: both necessary and sufficient requirements for routing stretch.
281: The {\em sufficient routing stretch requirement} is that
282: {\bf the routing algorithm underlying
283: any realistic interdomain routing protocol must be of stretch-1.}
284: Our reasoning behind this requirement is as follows.
285: Consider a {\em generic}\footnote{A {\em generic} routing algorithm
286: works correctly on all graphs.} stretch$>$1 routing algorithm and
287: apply it to a complete graph, which has all nodes directly
288: connected to all other nodes so that all shortest paths are of length~1.
289: If the routing algorithm does not guarantee to find all shortest paths,
290: it would imply that some nodes in a complete graph would
291: not know about their own directly connected neighbors.
292:
293: Of course, the Internet interdomain topology is not a full mesh,
294: and it might turn out that the same routing algorithm that fails
295: to be stretch-1 on a full mesh does in fact find all shortest paths
296: to each node's neighbors in realistic Internet-like topologies.
297: We thus might also pursue the explicit task of finding
298: a non-generic routing algorithm that is applicable only to Internet-like
299: topologies. We do not require this algorithm be stretch-1, but it
300: must be of stretch-1 on paths of length~1 leading to nodes' neighbors.
301: In other words, the {\em necessary routing stretch requirement}
302: is that {\bf the routing algorithm underlying any realistic
303: interdomain routing protocol must be of stretch-1 on paths
304: of length~1 in realistic Internet-like topologies.}
305:
306: These requirements are purely practical: if a link exists between
307: a pair of ASs, they must be able to route traffic over this
308: link. If our sophisticated routing algorithm removes routing
309: information about this link from the ASs' RTs, then the ASs'
310: network operators will have to manually reinsert it, which counters
311: the scalability objective of reducing the RT size. We will refer to
312: this administrative re-adding of information about shortest
313: paths to nodes' neighbors as {\em neighbor reinsertion}.
314:
315: The absence of a neighbor of a node in that node's RT appears
316: to contradict common sense, but one can verify that it
317: occurs with the algorithms we discuss in
318: Section~\ref{sect:compact_routing}. We emphasize
319: that we have not had to deal with this effect in practice yet
320: because the routing algorithms in operation today are all of stretch-1.
321: Indeed, this effect reflects the inevitable trade-off between
322: RT size and stretch. Intuitively, we can explain this trade-off
323: as follows: shortest path routing implies complete knowledge of the
324: network topology, complete knowledge suggests a lot of information,
325: and a lot of information suggests large RTs. In order to shrink RTs,
326: we must prepare to lose topological information, and such loss
327: necessarily increases path lengths. In addition, the meshier the
328: network, the more information about node neighbors there is to lose.
329: The full mesh is an extreme example of this dilemma.
330:
331: This fundamental and unavoidable trade-off between stretch of a
332: routing algorithm and sizes of RTs it generates is at the center of
333: compact routing research going on today, but the first formalization of
334: this trade-off was introduced many years ago in the context of
335: hierarchical routing.
336:
337: \section{Why hierarchical routing will not work}
338: \label{sect:noscale}
339:
340: The pioneering paper on routing scalability was
341: Kleinrock and Kamoun's~\cite{KK77}, which introduced the
342: idea of hierarchical routing. The key idea is to group (or aggregate)
343: nearby nodes into areas, areas into super-areas, and so on.
344: Such grouping is a form of the {\em network partitioning\/} problem.
345: Hierarchical aggregation and addressing offer
346: substantial RT size reduction by abstracting out
347: unnecessary topological details about
348: remote portions of the network: nodes in one \mbox{(super-)area} need to keep
349: only one RT entry for all nodes in another \mbox{(super-)area.}
350: To our knowledge, all proposals for future Internet routing
351: architectures trying to address the RT size problem are based,
352: explicitly or implicitly, on this concept of hierarchical routing. In
353: fact, no other kind of RT size reduction technique has
354: been considered in the networking literature.\footnote{Recall
355: that we have already adopted routing on AS numbers,
356: so that we consider here the RT size reduction {\em below\/}
357: the total number of ASs in the interdomain topology graph.}
358: Unfortunately, according to the best available data,
359: hierarchical routing is simply not a good candidate for
360: interdomain routing.
361:
362: Indeed, in the same paper~\cite{KK77}, Kleinrock and Kamoun were the
363: first to analyze the stretch/RT size trade-off. They showed
364: that the
365: routing stretch produced by the hierarchical approach
366: is satisfactory only for
367: topologies with average shortest path hop-length (distance)~$\bar{d}(n)$
368: that grows quickly with network size~$n$, which means
369: it works well only for graphs where long paths prevail.
370: In fact, they assumed \mbox{$\bar{d}(n) \sim n^\nu$} with~$\nu>0$.
371: Such graphs have many remote nodes, i.e., nodes at long hop distances
372: from each other, and one can efficiently, without substantial
373: multiplicative path length increase, aggregate details about topology
374: around remote nodes, simply because those remote nodes are abundant.
375:
376: Unfortunately, according to the best available data,
377: the Internet topology does not meet those conditions.
378: The Internet AS-level topology is a {\em scale-free\/}
379: network with characteristics described, for example,
380: in~\cite{MaKrFoHuDiKcVa05-tr}.
381: To avoid terminology disputes, by {\em scale-free\/}
382: we simply mean networks with fat-tail, e.g., power-law,
383: node degree distributions. In theory, the average
384: distance in such topologies grows with network size
385: much more slowly than~\cite{KK77} assumed:
386: it is at most \mbox{$\bar{d}(n) \sim \log n$}~\cite{ChLu03}. In practice,
387: the average hop distance between ASs in the Internet stays virtually
388: constant or even decreases due to increasing inter-AS
389: connectivity~\cite{huston-bgp-site,BroNeCla02}. According
390: to multiple data sources, the average AS-hop distance
391: in the current Internet is between~3.1 and~3.7,
392: with more than~80\% of AS pairs~\mbox{2-4} hops away from each
393: other~\cite{MaKrFoHuDiKcVa05-tr}.
394: We call a network {\em small-world\/} if most of its nodes are at small
395: distances from each other.
396: Thus the Internet AS-level topology is small-world:
397: {\em it has essentially no remote nodes}, which is extremely
398: bad news since the effectiveness of network partitioning
399: depends on their abundance.
400: In other words,
401: {\bf the unsettling but plainly observed reality is that
402: one cannot efficiently apply hierarchical routing to small-world
403: Internet-like topologies}.
404:
405: The previous arguments might sound too general since
406: we could still apply some generic hierarchical routing algorithm
407: to the Internet. However, such application cannot be efficient and
408: we must prepare to see high stretch.
409: And indeed, simple analytical estimates~\cite{KrFaYa04}
410: show that applying hierarchical routing to an Internet AS-level
411: topology incurs a $\sim$15-time path length increase, which,
412: although alarming enough by itself, would also lead to a substantial
413: RT size surge caused by neighbor reinsertion.
414: If we accept our argument in Section~\ref{sect:stretch}
415: that any truly scalable Internet routing algorithm must have
416: stretch as close as possible to~1, we must also accept the
417: fact that hierarchical routing will not meet our needs.
418: We conclude that all previous Internet interdomain routing
419: proposals heavily based on hierarchical routing
420: ideas\footnote{Classic examples of such proposals are~\cite{nimrod,islay}.
421: Note that recent work in~\cite{SuKaEe05} advocates hierarchical
422: routing, but the authors do not try to use it to reduce RT size.
423: They do reduce RT size, but only by routing on AS numbers.}
424: are not realistic and, if deployed, would not genuinely scale.
425:
426: \section{History of compact routing}
427: \label{sect:compact_routing}
428:
429: Fortunately, Kleinrock and Kamoun's results~\cite{KK77} are the
430: first but not the last results of research on scalable routing.
431: The history of this research is not linear; we outline it in
432: this section.
433:
434: We have not mentioned yet that~\cite{KK77} also suffered from
435: a problem more serious than high stretch on small-world
436: graphs. It did not provide any algorithms to actually
437: construct, for a given topology, a network partitioning
438: upon which hierarchical routing can operate.
439: Therefore, in works that followed~\cite{KK77}, first
440: L.~Kleinrock himself, then R.~Perlman, and then in the late
441: 1980s and in the 1990s B.~Awerbuch, D.~Peleg and others,
442: all spent much time and effort trying to salvage hierarchical
443: routing and to find efficient network partitioning algorithms.
444: It did not become clear that hierarchical routing does not have
445: any future until~1999 when L.~Cowen~\cite{cowen99}
446: delivered her brilliant compact routing scheme.
447: Her scheme had four
448: attractive features: 1)~it was non-hierarchical, so required
449: no network partitioning; 2)~it was generic and so worked for
450: any topology; 3)~it had a fixed stretch of 3 for any topology of
451: any size;
452: and 4)~it had a sub-linear RT size upper bound of
453: $\tilde{O}(n^{2/3})$. Cowen's algorithm was also beautifully
454: simple compared to numerous hierarchical routing algorithms
455: accumulated by that time.
456:
457: In retrospect, we can say that compact routing, which is
458: the state-of-the-art in efficient routing algorithm research today,
459: built on numerous findings from hierarchical routing,
460: which had been the state-of-the-art for decades.
461: Today, compact routing is a research
462: area in the theory of distributed computation, a part of theoretical
463: computer science. There is no strict definition of a compact routing
464: algorithm, or {\em scheme}, but it usually means an algorithm with
465: a sublinear RT size
466: upper bound---the RT size is also called {\em local memory space},
467: or simply {\em space} in compact routing terminology---and
468: with stretch bounded by a constant, in contrast to many
469: hierarchical routing algorithms for which stretch grows to infinity
470: with network size.\footnote{One can verify that on an $n$-node full mesh,
471: for example, \cite{KK77}~produces stretch growing to infinity as~$\Theta(\log n)$.}
472:
473: Since 1999 progress has been much more rapid than in the preceding~22
474: years. In 2001, M.~Thorup
475: and U.~Zwick~\cite{ThoZwi01b}~(TZ) improved on Cowen's RT size (space)
476: upper bound, bringing it to~$\tilde{O}(n^{1/2})$ while maintaining stretch of~3.
477: This result was particularly significant because the authors had previously
478: proven~\cite{ThoZwi01a} that any routing with stretch
479: below~5 cannot guarantee space smaller than~$\Omega(n^{1/2})$.
480: Therefore the TZ scheme was the first stretch-3 scheme whose
481: memory space upper and lower bounds were nearly the same
482: (up to a poly-logarithmic factor implied by~\mbox{` $\tilde{}$ '} in
483: the $\tilde{O}$ notation). In other words, the TZ scheme was
484: the first generic nearly {\em optimal} routing scheme of stretch~3.
485:
486: The main problem with both the Cowen and TZ schemes is that they
487: are name-dependent, meaning that topological information is embedded
488: in node addresses which thus cannot be arbitrary.
489: Such schemes cannot be used in dynamic topologies, since any
490: topology change potentially requires renaming many nodes.
491: In 2003, M.~Arias {\em et al.}~\cite{ArCoLaRaTa03}, delivered
492: a {\em name-independent}, i.e., name/addresses of nodes can be
493: arbitrary, routing scheme with a memory space upper bound
494: of~$\tilde{O}(n^{1/2})$ and stretch of~5.
495: In 2004, I. Abraham {\em et al.}~\cite{AbGaMaNiTho04} improved
496: on~\cite{ArCoLaRaTa03} by decreasing stretch to~3, which makes
497: it the first generic nearly optimal {\em name-independent\/} stretch-3
498: routing scheme.
499:
500: Why do we mention stretch-3 so often?
501: For \mbox{stretch-1} (shortest path) routing,
502: one can construct RTs at each node
503: by storing, for every destination node, the ID of the
504: outgoing port on the shortest path to the destination.
505: The number of destinations is \mbox{$n-1$}, the maximum number of ports
506: a node can have (equal to maximum possible node degree)
507: is also \mbox{$n-1$}, and thus a maximum $O(n \log n)$
508: bits of memory is required for an RT. This
509: construction is called {\em trivial shortest path routing}.
510: However, in 1996, C.~Gavoille and S.~P\'{e}renn\`{e}s~\cite{GaPe96}
511: showed that the {\em lower\/} bound of generic stretch-1
512: routing is also $\Omega(n \log n)$, i.e., there is no shortest
513: path routing scheme that guarantees local memory space smaller than
514: $\Omega(n \log n)$ at all nodes of all topologies.
515: In other words, shortest path routing is incompressible.
516: In order to decrease the maximum RT size, we
517: must allow maximum stretch to increase. Finally,
518: in 1997, C.~Gavoille and M.~Genegler~\cite{GaGe97} showed that
519: for any stretch strictly below~3, the local space
520: lower bound is nearly the same as for stretch-1 routing,~$\Omega(n)$,
521: meaning that {\em no\/} generic stretch$<$3 routing scheme can
522: guarantee sublinear RT sizes: the minimum value of maximum stretch
523: allowing sublinear RT sizes is~3.
524:
525: \section{Compact routing applicability}
526: \label{sect:applicability}
527:
528: The end of the last section sounds alarming: it conflicts with
529: considerations in Section~\ref{sect:stretch}, where we
530: discuss why stretch should be close to~1 for practical
531: applicability. Do shortest path routing incompressibility and
532: impossibility of sublinear-space \mbox{stretch$<$3} routing mean
533: that scalable interdomain routing with sublinear RT sizes is not
534: achievable at all?
535:
536: To answer this question, recall from Section~\ref{sect:stretch}
537: that stretch refers to the {\em maximum\/} path length increase among all
538: paths in {\em all the graphs\/} on which a routing algorithm operates,
539: meaning that there exists some worst-case graph\footnote{See~\cite{GaGe97}
540: for the explicit construction of this graph.} on which this
541: maximum is achieved. Recall also that all schemes mentioned
542: in Section~\ref{sect:compact_routing} are generic; they can
543: work on {\em any\/} graph, meaning that the worst-case graph does not have
544: to be Internet-like. We can consequently expect the {\em average
545: stretch\/} of these schemes on the class of Internet-like
546: graphs to be lower than~3. But how close can it be to~1? At first
547: thought it seems unlikely to be close to~1 at all, since we saw
548: in Section~\ref{sect:noscale}
549: that the stretch of hierarchical routing
550: tends to be high on small-world graphs, and there is no reason to
551: believe that compact routing would be drastically better. However,
552: in 2004, \cite{KrFaYa04}~showed that the
553: average performance of the first optimal stretch-3 scheme~(TZ)~\cite{ThoZwi01b}
554: on Internet-like topologies is spectacularly better than its worst case:
555: while its upper bounds are around~2200 for RT size and~3 for stretch,
556: {\bf the average RT size of the TZ scheme on the real Internet topology
557: was found to be around~50 entries (for the whole Internet!)
558: and the average stretch was only~1.1!}\footnote{We remind that while
559: these numbers are overwhelming, they correspond to a one-time improvement.
560: In the long-term, what matters is the mathematically
561: proven scaling behavior of the scheme (cf.~Section~\ref{sect:scalability}).}
562: These numbers are striking evidence that, on the same topology and
563: under the same assumptions,
564: compact routing dramatically outperforms both hierarchical
565: routing~\cite{KK77}, with its stretch of~15 and RTs of unknown sizes,
566: and simple routing on AS numbers (e.g.,~\cite{SuKaEe05}),
567: with RT sizes of the order of~$10^4$.
568:
569: An interesting question is why compact routing turns out to be
570: so spectacularly efficient on Internet-like topologies. There is no
571: rigorous answer to this question yet, but intuitively
572: we can think of a scale-free network as a dense interconnection
573: of star graphs, and one can verify that the stretch of many
574: compact routing schemes, e.g., Cowen, TZ,
575: on stars is~1. In addition, the scalability of the most
576: efficient routing on trees---and stars are trees---is
577: dazzling: RT sizes and RT lookup times are nearly constant
578: (they do not grow with network size), and stretch is~1~\cite{ThoZwi01b}!
579: Of course, the Internet topology is not at
580: all tree-like, since strong
581: clustering~\cite{MaKrFoHuDiKcVa05-tr} renders its treewidth high.
582: But surprisingly, \cite{fraigniaud05}~finds that strongly clustered
583: networks and networks with low
584: treewidth both possess the set of properties allowing for
585: remarkable performance of an important class of routing strategies.
586:
587: While the preliminary findings in~\cite{KrFaYa04} clearly demonstrate the
588: potential power and superiority of compact routing to everything
589: previously considered in networking in pursuit of routing
590: scalability, many open questions remain. In the remainder
591: of this section we catalog the four open problems we consider
592: most important.
593:
594: The average stretch was found to be close to~1 in~\cite{KrFaYa04},
595: but not~1. In fact, the average stretch does not even approach~1
596: in the limit of large networks. One can verify that if the average
597: stretch does not approach~1 on scale-free graphs at least as fast as
598: $1+\tilde{\Theta}(n^{-1/2})$, then the average number of non-shortest
599: paths per node is such that the neighbor reinsertion from Section~\ref{sect:stretch}
600: will break the theoretical RT size upper bound of~$\tilde{O}(n^{1/2})$.
601: If the average stretch does not approach~1 at all, as in~\cite{KrFaYa04},
602: then neighbor reinsertion forces the RT size to
603: go from~$\tilde{O}(n^{1/2})$
604: back to its trivial linear scaling~$\tilde{O}(n)$. Therefore, {\bf {\em the
605: stretch scaling problem\/}
606: is to find a compact routing scheme with satisfactory
607: scaling of stretch}, at least for length-1 paths.
608: Such a scheme likely exists given our intuition behind why the
609: stretch of the TZ scheme
610: on the Internet is so low in the first place: larger scale-free networks
611: are increasingly ``star-like''.
612:
613: A stronger formulation of the same problem is to find {\em shortest path\/}
614: routing with sublinear RT sizes on scale-free graphs. Sublinear-space
615: \mbox{stretch-1} routing applicable to all graphs cannot exist
616: (cf.~Section~\ref{sect:compact_routing}), but if we narrow
617: the class of graphs to scale-free graphs then there are
618: no results so far that prove the non-existence of such routing.
619: In addition,
620: it may turn out that we can significantly decrease RT size upper bounds,
621: a likely possibility given how far below its upper bound
622: the RT size of the TZ scheme is in~\cite{KrFaYa04}. In more general terms,
623: {\bf {\em the scale-free routing problem\/}
624: is to utilize peculiarities of scale-free networks to obtain
625: non-generic algorithms optimized specifically for Internet-like topologies}.
626:
627: {\bf The most vital open problem,
628: {\em the dynamic routing problem}, is to construct
629: truly dynamic schemes}. All currently existing schemes
630: are {\em static}. A {\em dynamic\/} scheme would have rigorous
631: upper bounds for its performance parameters
632: in dynamic networks, where nodes
633: and links can fail, be added or removed. Dynamic performance parameters
634: include the number of control messages the algorithm generates to converge after
635: a topology change, sizes of those messages, number of affected nodes, etc.
636: We refer to these parameters collectively as {\em convergence costs}.
637: Note that all currently deployed routing algorithms are
638: essentially static algorithms applied to dynamic environments,
639: an approach we know can be costly, e.g., the convergence costs
640: of BGP are infinite given that it can oscillate persistently and not
641: converge at all~\cite{GriWil99,GriWil02}.
642: The convergence costs of BGP's routing algorithm
643: (path-vector) are also astronomically high,~$O(n!)$~\cite{LaAhBo01}.
644: We need a solution with satisfactory bounds of convergence costs.
645:
646: Unfortunately, this problem is fundamentally hard, as illustrated by
647: the notable but pessimistic result~\cite{AfGaRi89} which says that
648: even with unbounded RT sizes, there is no generic dynamic stretch-$s$
649: routing scheme that guarantees less than~$\Omega(n/s)$ routing
650: messages. Simply put, there is no generic routing scheme that
651: scales sublinearly in the number of control packets per topology
652: change.\footnote{Although linear scaling in practically unacceptable,
653: it is still much better than the $O(n!)$ scaling of the path-vector
654: algorithm.} As in the static case we hope that narrowing the
655: problem from the class of all graphs to the class of Internet-like
656: graphs will yield more auspicious scaling.
657:
658: An alternative shortcut is to disregard the fact that all existing compact
659: routing schemes are static and to test them in dynamic networks anyway.
660: The intuition behind why these schemes might still work well even
661: in the dynamic environment lies in their ultra-optimal static performance.
662: Since the existing {\em name-dependent\/} schemes are not appropriate
663: candidates for such experimentation for
664: reasons we mentioned in Section~\ref{sect:compact_routing}, {\bf
665: {\em the name-independent routing problem\/} is to analyze the
666: performance of static name-independent routing schemes on dynamic
667: Internet-like topologies}. Work
668: in this direction has already begun: in~\cite{AbBaBi04} the authors
669: tested the first optimal \mbox{stretch-3} name-independent routing
670: scheme~\cite{AbGaMaNiTho04} which they implemented and deployed
671: in an overlay on PlanetLab in October~2004.
672:
673: \section{Conclusion}
674: \label{sect:conlcusion}
675:
676: The ultimate goal of our work is to build an incrementally
677: deployable interdomain routing {\em protocol\/} that will encompass
678: not only a new routing {\em algorithm\/} with satisfactory rigorous
679: bounds for routing table size, stretch, and convergence costs, but
680: also routing {\em policies} with appropriate performance guarantees.
681: We believe it is too early to discuss protocol details since we do
682: not yet even have constituents with acceptable characteristics, much
683: less understand their idiosyncrasies.
684:
685: On the positive side, this quest has already begun. Current
686: circumstances in the fields of theoretical computer science (TCS) and
687: networking have created a rare opportunity to pursue a fundamental
688: breakthrough in the search for truly scalable routing. Recent
689: developments in TCS yield shockingly promising results: alternative
690: {\em compact routing} algorithms offer dramatically superior
691: scalability characteristics than those being used or even considered
692: in networking. We recognize the need for a radical change in our
693: approach to routing research in order to build on these contemporary
694: results from TCS. The first task is to determine how applicable
695: these results are to real-world networks.
696:
697: Construction of practical, efficient, and scalable routing for the
698: next-generation Internet is a key motivator of our work, but we
699: recognize that we are only at the beginning of an extensive analysis
700: of our most fundamental assumptions about routing in data networks.
701: One such assumption is the adequacy of representing a real dynamic
702: network using an intrinsically static construct, a graph. This
703: assumption underlies, either explicitly or implicitly, all forms of
704: routing we have discussed in this paper. If we discover in the
705: future that scalable dynamic routing cannot even exist in principle
706: within the static graph-theoretic framework constraints, then some
707: unknown but presumably paradigm-shifting approaches to data network
708: routing will become inevitable. Regardless of the outcome, what
709: matters today is that we have a unique opportunity to explore a
710: radical new path, which initially looks more promising than any
711: previously considered approach to scalable routing.
712:
713: \section{Acknowledgements}
714:
715: This work is supported by NSF CNS-0434996.
716:
717: \bibliographystyle{unsrt}
718: \bibliography{bib}
719:
720: \end{document}
721: