15-744: Computer Networking L-7 Routing Issues

L -7; © Srinivasan Seshan, Routing Alternatives Overlay routing techniques Landmark hierarchies Synchronization of periodic messages Assigned reading [S+99] The End-to-End Effects of Internet Path Selection [Tsu88] The Landmark Hierarchy: A New Hierarchy for Routing in Very Large Networks

L -7; © Srinivasan Seshan, Outline Multi-homing Landmark Hierarchy Synchronization of Routing Messages Overlay Routing

L -7; © Srinivasan Seshan, Issues with Multi-homing Symmetric routing While preference symmetric paths, many are asymmetric Packet re-ordering May trigger TCP’s fast retransmit algorithm Other concerns: Address aggregation

L -7; © Srinivasan Seshan, Multi-homing to a Single Provider ISP Customer R1 R2 Easy solution: Use IMUX or Multi-link PPP Hard solution: Use BGP Makes assumptions about traffic (same amount of prefixes can be reached from both links)

L -7; © Srinivasan Seshan, Multi-homing to a Single Provider ISP Customer R1 R2 If multiple prefixes, may use MED Good if traffic load to prefixes is equal If single prefix, load may be unequal Break-down prefix and advertise different prefixes over different links R / /16

L -7; © Srinivasan Seshan, Multi-homing to a Single Provider ISP Customer R1R2 For traffic to customer, same as before: Use MED Good if traffic load to prefixes is equal For traffic to ISP: R3 alternates links Multiple default routes R / /16

L -7; © Srinivasan Seshan, Multi-homing to a Single Provider ISP Customer R1R2 Most reliable approach No equipment sharing Use MED R / /16 R4

L -7; © Srinivasan Seshan, Outline Multi-homing Landmark Hierarchy Synchronization of Routing Messages Overlay Routing

L -7; © Srinivasan Seshan, Landmark Hierarchy Details about things nearby and less information about things far away Not defined by arbitrary boundaries Thus, not well suited to the real world that does have administrative boundaries

L -7; © Srinivasan Seshan, A Landmark Router 1 is a landmark of radius 2

L -7; © Srinivasan Seshan, Landmark Overview Landmark routers have “height” which determines how far away they can be seen (visibility) Routers within radius n can see a landmark router LM n See means that those routers have LM n ’s address and know next hop to reach it. Router x as an entry for router y if x is within radius of y Distance vector style routing with simple metric Routing table: Landmark (LM 2 (d)), Level(2), Next hop

L -7; © Srinivasan Seshan, LM Hierarchy Definition Each LM i associated with level (i) and radius (r i ) Every node is an LM 0 landmark Recursion: some LM i are also LM i+1 Every LM i sees at least one LM i+1 Terminating state when all level j LMs are seen by entire network

L -7; © Srinivasan Seshan, LM Self-configuration Bottom-up hierarchy construction algorithm Goal to bound number of children Every router is L 0 landmark All L i landmarks run election to self-promote one or more L i+1 landmarks LM level maps to radius (part of configuration), e.g.: LM level 0: radius 2 LM level 1: radius 4 LM level 2: radius 8 Dynamic algorithm to adapt to topology changes – Efficient hierarchy

L -7; © Srinivasan Seshan, LM Addresses LM(2).LM(1).LM(0) (C.B.A) If destination is more than two hops away, will not have complete routing information, refer to LM(1) portion of address, if not known then refer to LM(2) LM 2 C LM 1 B R2R2 R1R1 LM 0 A aka C.B.A R0R0

L -7; © Srinivasan Seshan, LM Routing LM does not imply hierarchical forwarding It is NOT a source route En route to LM 1,packet may encounter router that is within LM 0 radius of destination address (like longest match) Paths may be asymmetric

L -7; © Srinivasan Seshan, Source wants to reach LM 0 [a], whose address is c.b.a: Source can see LM 2 [c], so sends packet towards c Entering LM 1 [b] area, first router diverts packet to b Entering LM 0 [a] area, packet delivered to a Not shortest path Packet may not reach landmarks Landmark Routing: Basic Idea LM 2 [c] LM 1 [b] r 0 [a] LM 0 [a] r 2 [c] r 1 [b] Network Node Path Landmark Radius

L -7; © Srinivasan Seshan, Landmark Routing: Example d.d.a d.d.b d.d.c d.d.e d.d.d d.d.f d.i.k d.i.g d.d.j d.i.i d.i.w d.i.u d.d.k d.d.l d.n.h d.n.x d.n.n d.n.o d.n.p d.n.q d.n.t d.n.s d.n.r d.i.v

L -7; © Srinivasan Seshan, Routing Table for Router g LandmarkLevelNext hop LM 2 [d] LM 0 [e] LM 1 [i] LM 0 [k] LM 0 [f] f k f k f Router g Router t r0 = 2, r1 = 4, r2 = 8 hops How to go from d.i.g to d.n.t? g-f-e-d-u-t How does path length compare to shortest path? g-k-I-u-t d.d.a d.d.b d.d.c d.d.e d.d.d d.d.f d.i.k d.i.g d.d.j d.i.i d.i.w d.i.u d.d.k d.d.l d.n.h d.n.x d.n.n d.n.o d.n.p d.n.q d.n.t d.n.s d.n.r

L -7; © Srinivasan Seshan, Final Questions Why should the routing algorithm be distance-vector? Link state algorithms need a full topology map What modifications are needed to DV? Must expire information about destination as it propagates Some support of administrative domains How about naming? Addresses may change

L -7; © Srinivasan Seshan, Outline Multi-homing Landmark Hierarchy Synchronization of Routing Messages Overlay Routing

L -7; © Srinivasan Seshan, Routing Update Synchronization Another interesting robustness issue to consider... Even apparently independent processes can eventually synchronize Intuitive assumption that independent streams will not synchronize is not always valid Periodic routing protocol messages from different routers Abrupt transition from unsynchronized to synchronized system states

L -7; © Srinivasan Seshan, Examples/Sources of Synchronization TCP congestion windows Cyclical behavior shared by flows through gateway Periodic transmission by audio/video applications Periodic downloads Synchronized client restart After a catastrophic failure Periodic routing messages Manifests itself as periodic packet loss on pings Pendulum clocks on same wall Automobile traffic patterns

L -7; © Srinivasan Seshan, How Synchronization Occurs T A Message from B Weak Coupling when A’s behavior is triggered off of B’s message arrival! A T No Coupling when A sends at a time that is independent of B’s message arrival Weak coupling can result in eventual synchronization

L -7; © Srinivasan Seshan, Periodic Message Model Router prepares and sends update, resets timer T c seconds after start time Received by other routers T d seconds from start If router receives incoming routing update while preparing its own update Router processes incoming update for T c2 seconds After generating update, sets timer drawn uniformly from [T p -T r, T p +T r ] seconds, T p is avg period, T r random component When timer expires repeat If update occurs reflecting topology event also repeat Why is this a problem???

L -7; © Srinivasan Seshan, The Periodic Message Model A A’s routing update Others’ routing updates TcTc T c2 TdTd [T p -T r, T p +T r ] T c2 Triggered updates cause sending of a message before timer expires

L -7; © Srinivasan Seshan, Routing Source of Synchronization Router resets timer after processing its own and incoming updates Creates weak coupling among routers There are solutions: Set timer based on clock event that is not a function of processing other routers’ updates, or Add randomization, or reset timer before processing update

L -7; © Srinivasan Seshan, What Happens?

L -7; © Srinivasan Seshan, Why Does it Happen?

L -7; © Srinivasan Seshan, Important Results With increasing T r (randomization) Takes longer to synchronize May need T r to be ten times T c A robust choice of timer T r = T p /2 With increasing randomization, abrupt transition From predominantly synchronized to predominantly unsynchronized

L -7; © Srinivasan Seshan, Other Thoughts Emergent large-scale structure likely to result from more complex system interactions Most protocols now incorporate some form of randomization

L -7; © Srinivasan Seshan, Outline Multi-homing Landmark Hierarchy Synchronization of Routing Messages Overlay Routing

L -7; © Srinivasan Seshan, Overlay Routing Basic idea: Treat multiple hops through IP network as one hop in overlay network Run routing protocol on overlay nodes Why? For performance – can run more clever protocol on overlay For efficiency – can make core routers very simple For functionality – can provide new features such as multicast, active processing, IPv6

L -7; © Srinivasan Seshan, Overlay for Performance [S+99] Why would IP routing not give good performance? Policy routing – limits selection/advertisement of routes Early exit/hot-potato routing – local not global incentives Lack of performance based metrics – AS hop count is the wide area metric How bad is it really? Look at performance gain an overlay provides

L -7; © Srinivasan Seshan, Quantifying Performance Loss Measure round trip time (RTT) and loss rate between pairs of hosts ICMP rate limiting Alternate path characteristics 30-55% of hosts had lower latency 10% of alternate routes have 50% lower latency 75-85% have lower loss rates

L -7; © Srinivasan Seshan, Bandwidth Estimation RTT & loss for multi-hop path RTT by addition Loss either worst or combine of hops – why? Large number of flows  combination of probabilities Small number of flows  worst hop Bandwidth calculation TCP bandwidth is based primarily on loss and RTT 70-80% paths have better bandwidth 10-20% of paths have 3x improvement

L -7; © Srinivasan Seshan, Sources of Experimental Error Much of paper targeted at proving accuracy of measurements Use of mean vs. median – checked for one dataset Random sampling noise – compare 95% confidence intervals Time of day effects – alternate paths better during higher load Long-term averaging – looked a simultaneous measurements

L -7; © Srinivasan Seshan, Possible Sources of Alternate Paths A few really good or bad AS’s No, benefit of top ten hosts not great Better congestion or better propagation delay? How to measure? Propagation = 10th percentile of delays Both contribute to improvement of performance

L -7; © Srinivasan Seshan, Overlay for Efficiency Multi-path routing More efficient use of links or QOS Need to be able to direct packets based on more than just destination address  can be computationally expensive What granularity? Per source? Per connection? Per packet? Per packet  re-ordering Per source, per flow  coarse grain vs. fine grain Take advantage of relative duration of flows Most bytes on long flows

L -7; © Srinivasan Seshan, Edge vs. Core Routers Island of routers Edges can perform complex computation to classify flow Cores do extremely simple forwarding How to communicate computation results MPLS Dynamic packet state

L -7; © Srinivasan Seshan, Overlay for Features How do we add new features to the network? Does every router need to support new feature? Choices Reprogram all routers  active networks Support new feature within an overlay Basic technique: tunnel packets Tunnels IP-in-IP encapsulation Poor interaction with firewalls, multi-path routers, etc.

L -7; © Srinivasan Seshan, Examples IP V6 & IP Multicast Tunnels between routers supporting feature Mobile IP Home agent tunnels packets to mobile host’s location QOS Needs some support from intermediate routers

L -7; © Srinivasan Seshan, Overlay Challenges “Routers” no longer have complete knowledge about link they are responsible for How do you build efficient overlay Probably don’t want all N 2 links – which links to create? Without direct knowledge of underlying topology how to know what’s nearby and what is efficient?

L -7; © Srinivasan Seshan, Future of Overlay Application specific overlays Why should overlay nodes only do routing? Caching Intercept requests and create responses Transcoding Changing content of packets to match available bandwidth Peer-to-peer applications

L -7; © Srinivasan Seshan, Next Lecture: TCP Basics TCP connection setup/data transfer TCP reliability TCP options Assigned reading [FF96] Simulation-based Comparisons of Tahoe, Reno, and SACK TCP