1. Routing in Multi-Layered Networks Srinivasan Seetharaman Georgia Institute of Technology srini@cc.gatech.edu Case Western Reserve University March 2007

2. 2 Internet Architecture Current Internet architecture has been guided by the end-to-end principle: network layer implements simple primitives useful for a broad range of end-to-end applications for good balance between cost vs benefit

3. 3 Internet Evolution A survey of Cisco router software features… FeatureYearVersion Fault restoration1986SSR 1 Multicast1994IOS 10.2 DiffServ prioritization1997IOS 11.0 Tag switching (pre-MPLS)1997IOS 11.1 Security – 1: Encryption, Firewalls2000IOS 11.2 Security – 2: NAT2001IOS 12.0 No dramatic change in services offered to end-user 2007IOS 12.4T

4. 4 Internet Evolution (contd.) Common observations: Core features are gradually beginning to ossify Routers are becoming faster and more reliable Deployability concerns are common with most services All-or-nothing implementation problems For example, we still do not see deployment of Secure-BGP Need for ways to offer new services and enhance existing services!

5. 5 Overlay Networks Overlay networking helps overcome functionality limitations by forming a virtual network that is: Independent Customizable over the IP network (Native layer).

6. 6 Overlay routing is independent of native layer routing Each Overlay path comprises one or more Overlay links, based on a certain selfish objective Example: Latency-Optimized Overlay A A D D C C B B 50ms 20ms Relaying Overlay link Overlay nodes

7. 7 Service Overlay NetworksClassification Overlay networks Peer-to-peer networks End-system overlays (e.g. Skype) Routing overlay networks Service overlays (e.g. VINI)  Multicast (e.g. ESM, Overcast)  Better routes (e.g. RON, Detour, X-Bone)  Customized forwarding (e.g. I3, Scattercast)  QoS (e.g. OverQoS, SON)  Security (e.g. DynaBone, SOS) … and much more

8. 8 A D EF G H F H G A E C C B E C B OVERLAY 1 LAYER NATIVE IP LAYER OVERLAY 2 LAYER D B Generalized Multi-layer Routing Enhanced services

9. 9 Service Overlay Networks (contd.) A D EF G H F H G A E C C B OVERLAY LAYER NATIVE IP LAYER D B Throughput optimized overlay Latency optimized overlay

10. 10 Cross-Layer Interaction Performing dynamic routing at both layers leads to: Functionality overlap (Both overlay layer and IP layer perform similar set of functions) Mismatch or misalignment of routing objectives Contention for limited physical resources

11. 11 Cross-Layer Interaction (contd.) These issues are amplified in the presence of Selfish motives Lack of information about other layer Increasing impact ( #overlays  |Traffic| )

12. 12  Overlay routing conflicts with native layer load balancing. - [Infocom07]  Overlay routing can violate inter-domain policies. - [ICNP06]  Failure detected by both layers and rerouted twice, with each rerouting disrupting the optimality of the previous. - [Infocom06]  A framework for improved support of overlay services - [Hotnets05] Outline of my work Potential for Indefinite Conflict!

13. Conflict 1. Intra-domain Overlay routing vs Traffic Engineering

14. 14 Repeated Non-Cooperative Game Player1: Overlay Routing - Latency-optimized paths between nodes Player2: Traffic Engineering - MPLS-based scheme that solves a linear program (LP) to obtain optimal routes Overlay Routing Overlay Link Latencies Overlay layer traffic Overlay routes  Traffic Engineering Traffic on each overlay link  Background traffic Native routes Native link delays  TM

15. 15 Illustration of OR vs TE A E I D F B H C G A B D C OVERLAY NATIVE J 3 2ms 3 2 3ms 2 2 10ms 2 2 2ms 4 4 3ms 3 4 2ms 4ms 5 3 6ms 2ms 3 4ms 14ms 10ms 4ms 23ms 5ms Initial State Numbers on each link represent the avail-bw Shortest latency routes Minimize (Max util)

16. 16 2 2 1 1 0 0 Illustration of OR vs TE (contd.) A E I D F B H C G A B D C OVERLAY NATIVE J 2ms 2 3ms 2 2 10ms 2 2 2ms 4 2 3ms 4 2ms 4ms 6ms 2ms 4ms 14ms 10ms 6ms 23ms 5ms Overlay traffic introduced Multihop paths A  B  C A  B  D Avail-bw changed

17. 17 A E I D F B H C G A B D C OVERLAY NATIVE J 1 2ms 1 1 3ms 1 2 10ms 2 2 2ms 2 4 3ms 2 2 2ms 4ms 3 1 6ms 2ms 2 14ms 10ms 4ms 23ms 5ms SPLIT After TE reacts Multihop paths A  B  C A  B  D Latency changed Illustration of OR vs TE (contd.) 5ms

18. 18 A E I D F B H C G A B D C OVERLAY NATIVE J 1 2ms 1 1 3ms 1 2 10ms 2 2 2ms 0 4 3ms 0 0 2ms 4ms 5 3 6ms 2ms 0 5ms 14ms 10ms 23ms 5ms SPLIT After Overlay routing reacts 4ms Avail-bw changed Illustration of OR vs TE (contd.) Multihop paths A  B  C A  B  C  D B  C  D 2 2 2 3 1 2

19. 19 Simulation Results TE objective Overlay objective Overall stability  Round 

20. 20 General Approach: Similar to Stackelberg’s game: Designate leader/follower. Make Leader act after predicting (or) counteracting the subsequent reaction of the follower Leader undertakes preemptive action such that a.Follower has no desire to change  Friendly b.Follower has no alternative to pick  Hostile Use history to learn desired action gradually. Resolving Conflict

21. 21 Preemptive Strategies for Overlay Friendly: Native layer only sees a set of src-dest demands Improve latency of overlay routes, while retaining the same load pressure on the native network?  Load-constrained LP Hostile: Push TE to such an extent that it does not reroute the overlay links after overlay routing Send dummy traffic in an effort to render TE ineffective  Dummy traffic injection

22. 22 Preemptive Strategies: Summary We proposed four strategies that improve performance for one layer and achieve a stable operating point Inflation factor = Steady state obj value with strategy Best obj value achieved LeaderStrategyOverlayTE OverlayFriendly: Load-constrained LP Hostile: Dummy traffic injection 1.082 1.023 1.122 1.992 NativeFriendly: Hopcount-constrained LP Hostile: Load-based Latency tuning 1.027 1.938 1.184 1.072 Inflation

23. 23 Preemptive Strategies: Summary (contd.) Each strategy achieves best performance for the target layer within a few rounds with no interface between the two layers with all information inferred through simple measurements

24. Conflict 2. Inter-domain Overlay routing vs Inter-Domain Policy

25. 25 Inter-Domain Policy Violations Objective of overlay layer: Offer better latency routes to end-systems But, what is assumed here? Harvard is not unhappy with relaying overlay packets Colorado State Univ Harvard Univ Univ of NC 30 ms 24 ms 61 ms

26. 26 Provider 1 Inter-Domain Policy Violations (contd.) A more realistic picture… Unhappy  Money  Load Client 1 Client 1 A Client 2 B Client 3 C Provider 2 Peer Legitimate native route Overlay route Valley-free violation $ $

27. 27 Planetlab Overlay Measurements Topology: 58 geographically distributed Planetlab nodes (Univ + Commercial). This represents 3306 overlay paths Measurement steps: 1. Determine AS path of each overlay link (Rockettrace / traceroute for hop list + IP  AS mapping) 2. Determine overlay path based on shortest path algorithm (For Cost = latency, 56.6% overlay paths prefer relaying) 3. AS relationships inferred using Gao’s algorithm Data: http://www.cc.gatech.edu/~srini/code

28. 28 Only multihop overlay paths are violating Extent of transit policy violations in multihop paths Measurement Results Violation Type% paths Provider-AS-Provider63.1 Provider-AS-Peer 2.4 Peer-AS-Provider 2.0 Peer-AS-Peer 2.4 Total69.9

29. 29 Policy Enforcement by Native Layer As ISPs become aware of the negative impact of overlays and commence filtering, this leads to drastic deterioration in overlay route performance commensurate with the number of ASes enforcing policy

30. 30 Overlay service provider shares some of the cost incurred by the native layer  For a certain fee, we adopt one of the following strategies for achieving good legitimate paths: 1. Obtain transit permit from certain AS 2. Add new node to certain provider AS Cost-sharing approach Resolving Conflict

31. 31 With no filtering, Illustration of Cost Sharing 31 21 32 22 1113 23 33 Cust-Prov relation Peering relation Transit violation AS hosting overlay node Tier-1 provider Tier-2 provider Stub customer

32. 32 With filtering, we have no multi-hop paths Illustration of Cost Sharing (contd.) 31 21 32 22 1113 23 33 Cust-Prov relation Peering relation AS hosting overlay node Tier-1 provider Tier-2 provider Stub customer

33. 33 Option 1: Add new overlay node to provider AS 22 Option 2: Obtain transit permit from stub AS 32 Illustration of Cost Sharing (contd.) 31 21 32 22 1113 23 33 Cust-Prov relation Peering relation AS hosting overlay node Tier-1 provider Tier-2 provider Stub customer 22

34. 34 Greedy Heuristics Pay ASes along unrestricted best-gain path Obtain transit permits from stub ASes that have high betweenness (# of overlay paths through the node) Next, add overlay nodes to upstream providers, starting with the overlay paths which achieve the highest gain

35. 35 In Summary, Overlays… … offer valuable services needed by end-systems … leads to complex cross-layer interaction with potentially detrimental effects … are hard to detect, as seen from efforts with identifying Skype traffic

36. 36 Ongoing Work Conflict-aware overlay node placement Multi-layer testbed using Planetlab-VINI that allows control of multiple layers Analysis of other “performance-aware” overlays (like Bittorrent)

37. 37 Other Work There exists other forms of collaboration that are malicious. I work on exposing their memberships in a scalable manner

38. 38 Future of Overlays Overlays are essential as… Means for end-systems to collaborate Environment for testing future innovations (GENI) Architecture for Future Internet in the form of Network Virtualization  Cross-layer interaction will affect performance. How best to design protocols and services in the future?

39. 39 Future Research – Native Layer How to prepare ISPs for overlay applications? To promote it To contain it No effective solution for identifying relayed traffic. Need an orthogonal policy between overlay/native. Need to address the network impasse. How to tune the network for.. the new breed of Internet applications? (e.g., file sharing) …and new paradigms of communication? (e.g., wireless)

40. 40 Future Research – Service Layer How best to support multiple Internets? Researchers suggest a future with multiple coexisting Internets (Potential outcome of NSF-FIND program) Model as multiple coexisting overlays Which layer to implement a service at? For example, a service like multicast can be performed at both native layer and overlay layer! Which layer to use for a particular scenario? Which layer needs optimizing?

41. Thank you! See: http://www.cc.gatech.edu/~srini Questions