Advanced Topics in Routing

1. Advanced Topics in Routing EE 122: Intro to Communication Networks Fall 2010 (MW 4-5:30 in 101 Barker) Scott Shenker TAs: Sameer Agarwal, Sara Alspaugh, Igor Ganichev, Prayag Narula http://inst.eecs.berkeley.edu/~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley

2. Routing Lectures • Link-layer (L2) • Self-learning • Intradomain (L3) • Link-state • Distance vector • Interdomain • Path-vector

3. But there is more to the story…. • Normally these three approaches (LS, DV, PV) are presented as the holy trinity of routing • But we know how to do better • That is what we will talk about today….. • Augmenting LS with Failure-Carrying Packets • Augmenting DV with Routing Along DAGs • Augmenting PV with Policy Dispute Resolution

4. Self-Learning • Requirements: • Plug-and-play (no management needed) • Flat address space • Forwarding rules: • Watch which port MAC addresses come from • When in doubt, flood to all other ports • Spanning tree needed for flooding • Does not use shortest data paths • Network unusable while spanning tree recomputed

5. Intradomain (L3) • Link-state: • Global state, local computation • Flood local topology information • Each router computes shortest paths on graph • Requires routers to have globally consistent state • Distance-vector: • Local state, global computation • Routers participate in distributed computation • Exchange current views on “shortest paths” • Hard to prevent loops while responding to failures • E.g., count-to-infinity

6. Interdomain: Path-vector • Path-vector enables: • General policy autonomy for import and export • Easy detection of loops • Disadvantages of path-vector • High churn rate (many updates) [why higher than DV?] • Convergence after failure can be slow • Policy oscillations possible • Even limited degrees of autonomy can result in policy oscillations

7. Three Routing Challenges • Resilience • Slow convergence after failures, worse as networks grow • Network not reliable during convergence • Most important barrier to a more reliable Internet • Goal is 99.999% availability, now 99.9% at best • Gaming, media, VoIP, finance (trading) make this more important • Traffic engineering (what is this?) • Current traffic engineering mechanisms cumbersome • Must find more adaptive methods • Policy oscillations in interdomain routing

8. Outline of Lecture • Multipath Routing (one slide) • Failure-Carrying Packets • Routing Along DAGs • Policy Dispute Resolution

9. Multipath Routing • Multipath: • Providing more than one path for each S-D pair • Allow endpoints to choose among them • Helps to solve: • Resilience: if one path goes down, can use another • Traffic engineering: let network or endpoints spread traffic over multiple paths • Challenges: • Scalability (various approaches, none ideal) • Delay for endpoints to detect failure and switch paths

10. Failure-Carrying Packets(FCP)

11. Dealing with Link Failures • Traditional link-state routing requires global reconvergence after failures • Flood new state, then recompute • In the meantime, looping is possible due to inconsistencies • Can speed up by tuning timers, etc. • Can precompute some number of backup paths • Need backup paths for every failure scenario • Question: can we completely eliminate the need to “reconverge” after link failures?

12. Our Approach: Step 1 • Ensure all routers have consistent view of network • But this view can be out-of-date • Consistency is easy if timeliness not required • Use reliable flooding • Each map has sequence number • Routers write this number in packet headers, so packets are routing according to the same “map” • Routers can decrement this counter, not increment it • Eventually all routers use the same graph to route packet

13. Our Approach: Step 2 • Carry failure information in the packets! • Use this information to “fix” the local maps • When a packet arrives and the next-hop link for the path computed with the consistent state is down, insert failure information into packet header • Then compute new paths assuming that link is down • If failure persists, it will be included in next consistent picture of network

14. Example: FCP routing B D IP packet A F source destination C E

15. (D,F) (C,E) (C,E) IP packet IP packet Example: FCP routing B D IP packet A F source destination C E

16. Properties of FCP • Eliminates the convergence process • Guarantees packet delivery • As long as a path exists during failure process • Major conceptual change • Don’t rely solely on protocols to keep state consistent • Information carried in packets ensures eventual consistency of route computation

17. OSPF-overhead FCP-lossrate Results: OSPF vs. FCP • Unlike FCP, OSPF cannot simultaneously provide low churn and high availability OSPF-lossrate Overhead [msgs/sec per link]

18. Bkup-state Bkup-lossrate FCP-state FCP-lossrate Results: Backup-paths vs. FCP • Unlike FCP, Backup-paths cannot simultaneously provide low state and lossrate

19. Problems with FCP • Requires changes to packet header • Does not address traffic engineering

20. Routing Along DAGs(RAD)

21. Avoiding Recomputation: Take II • Recover from failures without global recomputation • Support locally adaptive traffic engineering • Do so in ways that work at both L2 and L3 • Without any change in packet headers, etc.

22. Our Approach: Shift the Paradigm Routing compute paths from source to destination If a link fails, all affected paths must be recomputed Move from path to DAG (Directed Acyclic Graph) Path DAG X X • Packets can be sent on any of the DAG’s outgoing links • No need for global recomputation after each failure

23. DAG Properties • Guaranteed loop-free • Local decision for failure recovery • Adaptive load balancing X X 0.7 0.3

24. Load Balancing • Use local decisions: • Choose which outgoing links to use • Decide how to spead the load across these links • Push back when all outgoing links are congested • Send congestion signal on incoming links to upstream nodes • Theorem: • When all traffic goes to a single destination, local load balancing leads to optimal throughput • Simulations: • In general settings, local load balancing close to optimal

25. Computing DAG • DAG iff link directions follow global order • Computing a DAG for destination v is simple: • Essentially a shortest-path computation • With consistent method of breaking ties

26. What about Connectivity? • Multiple outgoing links improve connectivity • But can RAD give “perfect” connectivity? • If all outbound links fail that node is disconnected • Even if underlying graph is still connected • How can we fix this?

27. Link Reversal • If all outgoing links fail, reverse incoming links to outgoing X X X X

28. Link Reversal Properties • Always loop-free • Local reaction, not global recomputation • The scope of link reversal is as local as possible • Connectivity guaranteed! • If graph is connected, link reversal process will restore connectivity in DAG • This has been known in wireless literature • Now being applied to wired networks

29. Summary of RAD • Local responses lead to: • Guaranteed connectivity • Close-to-optimal load balancing • Can be used for L2 and/or L3 • No change in packet headers

30. 5 Minute Break Questions Before We Proceed?

31. Announcements • HW3a was due today • HW3b will be posted tonight, due in two weeks • Midterm regrading requests due today • Check our addition!

32. Policy Dispute Resolution

33. Problem: Policy Oscillations • Policy Oscillations are: • Persistent • Hard to determine in advance • Involve delicate interplay of domain policies • Not issue of correctness, but of conflicting preferences • Therefore, can’t just define them away • Need new approach

34. Objectives • Do not reveal any ISP policies • Distributed, online dispute detection and resolution • Routers get to select most preferred route if no dispute resulting in oscillations exist • Account for transient oscillations, don’t permanently blacklist routes

35. 1 2 3 Example of Policy Oscillation “1” prefers “1 3 0” over “1 0” to reach “0” 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

36. 1 2 3 Step-by-Step of Policy Oscillation Initially: nodes 1, 2, 3 know only shortest path to 0 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

37. 1 2 3 Step-by-Step of Policy Oscillation 1 advertises its path 1 0 to 2 1 3 0 1 0 advertise: 1 0 0 2 1 0 2 0 3 2 0 3 0

38. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

39. 1 2 3 Step-by-Step of Policy Oscillation 3 advertises its path 3 0 to 1 1 3 0 1 0 advertise: 3 0 0 2 1 0 2 0 3 2 0 3 0

40. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

41. 1 2 3 Step-by-Step of Policy Oscillation 1 withdraws its path 1 0 from 2 1 3 0 1 0 withdraw: 1 0 0 2 1 0 2 0 3 2 0 3 0

42. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

43. 1 2 3 Step-by-Step of Policy Oscillation 2 advertises its path 2 0 to 3 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0 advertise: 2 0

44. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

45. 1 2 3 Step-by-Step of Policy Oscillation 3 withdraws its path 3 0 from 1 1 3 0 1 0 withdraw: 3 0 0 2 1 0 2 0 3 2 0 3 0

46. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

47. 1 2 3 Step-by-Step of Policy Oscillation 1 advertises its path 1 0 to 2 1 3 0 1 0 advertise: 1 0 0 2 1 0 2 0 3 2 0 3 0

48. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0

49. 1 2 3 Step-by-Step of Policy Oscillation 2 withdraws its path 2 0 from 3 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0 withdraw: 2 0

50. 1 2 3 Step-by-Step of Policy Oscillation 1 3 0 1 0 0 2 1 0 2 0 3 2 0 3 0 We are back to where we started!