1. Towards an Evolvable Internet Architecture IP layer change IP (routers, headers, addressing, …) Sylvia Ratnasamy (Intel Research), Scott Shenker (U.C. Berkeley/ICSI), Steven McCanne (Riverbed Tech.)

2.   Folklore   The Internet Architecture needs fixing –IPNL, Triad, IP Multicast, Pushback, GIA, Traceback, IPv6, SIFF, FQ, CSFQ, XCP, Capabilities, DTN, HLP, RCP, AIF, i 3, LFN, … But, ISPs don’t deploy (our) fixes –IP Multicast, IPv6 are the success stories! One reaction : ``Who needs the ISPs anyway?’’

3. Overlays to the Rescue (v1) Use overlays to augment IP Implement change in application-level `routers’ –Multicast: ESM (CMU), commercial CDNs –Routing: InterNAP, RON (MIT), SOSR (UW) –Quality-of-Service: OverQoS (UCB/MIT) –DoS: Mayday (MIT), SOS (Columbia), i3 (UCB/CMU)

4. Overlays to the Rescue (v1) Use overlays to augment IP Implement change in application-level `routers’ Practical –bypass CISCO and the ISPs

5. Overlays to the Rescue (v1) Use overlays to augment IP Implement change in application-level `routers’ Practical Often even appropriate –keep complexity out of IP

6. Overlays to the Rescue (v1) Use overlays to augment IP Implement change in application-level `routers’ Practical Often even appropriate But, if the problem is best solved at the IP layer, this doesn’t help

7. Overlays (v2) Use overlays to undermine ISPs [Peterson, Shenker, Turner 04] Next-Generation Service Provider (NGSP) enters the market –overlays a new architecture atop existing ISPs –legacy ISPs soon serve only to access NGSP

8. Overlays (v2) Use overlays to undermine ISPs [Peterson, Shenker, Turner 04] Next-Generation Service Provider (NGSP) enters the market Eventually, NGSP replaces ISPs –lease dedicated lines

9. Overlays (v2) Use overlays to undermine ISPs [Peterson, Shenker, Turner 04] Next-Generation Service Provider (NGSP) enters the market Eventually, NGSP replaces ISPs Technically, practical and broad –(and invaluable as an experimental platform)

10. Overlays (v2) Use overlays to undermine ISPs [Peterson, Shenker, Turner 04] Next-Generation Service Provider (NGSP) enters the market Eventually, NGSP replaces ISPs Technically, practical and broad But, requires disrupting the existing market structure Evolution through (repeated) revolution Are there other (more conservative) options?

11. This Paper Can we enable evolution that –can retain the existing market structure –yet, allows non-incremental change (revolution through evolution ) Approach: –design for evolution ( vs. causing evolution )

12. Design for Evolution The Internet will always be –multi-provider –decentralized in control Common complaint – providers have little incentive to innovate Is this due to flaw(s) in the architecture? –strategies, mechanisms, hooks that assist evolution

13. Disclaimer Many possible reasons for ISP reluctance –architectural barriers to innovation –economic barriers (pricing models, etc.) –disconnect between research and reality maybe the Internet is doing just fine maybe the fixes we propose aren’t the right ones This paper: architectural barriers –may well be the least of the problems

14. Outline Toy example: deploying IPvN Universal Access Implementing Universal Access Conclusion Paper When a new version of IP, call it IPvN, is defined, what conditions would lead ISPs to deploy it?

15. Toy Example IPvN supports comprehensive security –requires router support –new IP headers Software vendor puts out an IPvN stack Router vendors support IPvN Content Provider (CP) is interested in using IPvN ISPs consider deploying IPvN

16. Deploying IPvN IPv4 ISP A CP scale  partial deployment a necessity partial deployment  partial usability

17. partial usability global usability development of applications/services stalled on global usability low usage, user demand no incentive for ISPs to deploy IPvN any ISP can gate usability global deployment independent innovation is high risk, yet offers no competitive advantage require global usability under partial deployment Proposal: separate deployment from usability

18. partial deployment  global usability IPv4 ISP A X

19. Universal Access If even a single ISP deploys IPvN, any endhost can use IPvN –enables customer choice, demand –encourages application development –no ISP can gate adoption –independent innovation; others follow to compete Note assumption: UA leads to increased revenue flow –settlements? –application/service providers

20. Outline Toy Example: deploying IPvN Universal Access Implementing Universal Access –constraints –two components –putting it all together Conclusion

21. Achieving UA Constraints: –partial deployment –partial ISP participation –allow participating ISPs control –existing players –existing contractual agreements

22. Achieving UA: Two components IPv4 ISP A (1) partial deployment  multi-provider overlays*

23. Achieving UA: Two components IPv4 ISP A (2) universal access  need redirection

24. Redirection for UA Involves knowing: –where IPvN routers are located –which IPvN router is the best choice for a source (And the answer to both changes as deployment spreads!) Mechanism is ~tunneling++ Key is who effects redirection

25. Redirection: Options WhoRecall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

26. Redirection: Options Who user: unwieldy Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

27. Redirection: Options Who user: unwieldy user’s ISP Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

28. Redirection: Options Who user: unwieldy user’s ISP participant ISPs Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

29. Redirection: Options Who user: unwieldy user’s ISP participant ISPs application-layer Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

30. Redirection: Options Who user: unwieldy user’s ISP participant ISPs application-layer network-layer Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts

31. Network-Layer Redirection Routers perform redirection

32. Network-Layer Redirection Routers perform redirection Challenge: no explicit participation from ‘ ’

33. Proposal: Use IP Anycast 1.‘A’ is the IPv(N-1) address used to deploy IPvN 2.IPvN routers advertise ‘A’ into the IPv(N-1) routing protocol 3.a discovers IPvN routers via IPv(N-1) routing protocol A A A A A A IPv4 DST = A

34. Redirection: Options Who user: unwieldy user’s ISP participant ISPs application-layer network-layer* Recall Constraints 1.partial deployment 2.partial ISP participation 3.participant ISP control 4.no new players 5.existing contracts      *Caveat: less flexible redirection

35. But, Isn’t Anycast a Non-Starter? Short answer: no. Scales just fine –restricted service model vis-à-vis RFC 1546 deployed/used only by ISPs –a new IP needs one anycast address And is deployable (see paper) –Intra-domain: minor change by participating ISPs –(+) Inter-domain v1 : simple policy change by all ISPs –(~) Inter-domain v2: no change by non-participant ISPs

36. Outline Toy Example: deploying IPvN Universal Access Implementing Universal Access –constraints –two pieces –putting it all together Conclusion

37. Putting It All Together A A A IPv4 DST = A DnDn source IPvN DST = D n A A Case 1: Destination’s ISP supports IPvN IPv4 DST = R IPvN DST = D n R

38. A A A IPv4 DST = A ? source IPvN DST = ? A Two issues: 1.Addressing hosts in non-participant ISP domains Case 2: Destination’s ISP does not supports IPvN

39. A A A IPv4 DST = A D 4-to-n  from D 4 source IPvN DST = D 4-to-n A Two issues: 1.Addressing hosts in non-participant ISP domains proposal: interim addressing à la RFC 3056 Case 2: Destination’s ISP does not supports IPvN

40. A A A D 4-to-n  from D 4 source A Two issues: 1.Addressing hosts in non-participant ISP domains 2.Routing to hosts in non-participant ISP domains (paper) one proposal: advertises D 4 ’s prefix into IPvN routing Case 2: Destination’s ISP does not supports IPvN D 4-to-n ? R R

41. A A A D 4-to-n = from D 4 source A Two issues: 1.Addressing hosts in non-participant ISP domains 2.Routing to hosts in non-participant ISP domains (paper) Case 2: Destination’s ISP does not supports IPvN IPv4 DST = D 4

42. Putting It All Together Summary: Technical requirements for UA 1.Redirection –best achieved at the network-level –anycast: works under partial participation 2.Multi-provider virtual backbones –similar to the MBone, etc. –but, details of addressing and routing to destinations in non-IPvN domains requires some attention

43. Open Questions End-host software architecture –dual-stack, NAT-PT, BIS, OCALA [UCB] Exploring revenue flow: –ongoing work at SIMS (UCB) [Laskowski, Chuang] Architectural limitations due to partial deployment, overlays Clean-slate design for evolvability

44. Conclusion Proposal: A conservative approach to evolution [Floyd] –a preference for incremental strategies (that lead in the fundamentally right direction?) –value to understanding the compromises possible with existing network vs. brave new solutions

45. Conclusion Proposal: A conservative approach to evolution [Floyd] Conjecture: UA could enable ISP innovation –achievable with no change to the current architecture –a bit of synthesis, but no new mechanisms

46. Conclusion Proposal: A conservative approach to evolution [Floyd] Conjecture: UA could enable ISP innovation Maybe the Internet is evolvable Maybe the problem is not a technical one –worth exploring to avoid repeating the same mistake Or, maybe there is no problem

47. Thank you!