Towards an Evolvable Internet Architecture

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

• The Internet Architecture needs fixing
• IPNL, Triad, IP Multicast, Pushback, GIA,
  Traceback, IPv6, SIFF, FQ, CSFQ, XCP,
  Capabilities, DTN, HLP, RCP, AIF, i3, LFN,
• But, ISPs dont 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 doesnt 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 arent the right ones
• This paper architectural barriers
• may well be the least of the problems

14
Paper When a new version of IP, call it IPvN, is
defined, what conditions would lead ISPs to
deploy it?

• Outline
• Toy example deploying IPvN
• Universal Access
• Implementing Universal Access
• Conclusion

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
scale ? partial deployment a necessity
partial deployment ? partial usability
CP
IPv4
ISP A
17
partial deployment ? partial usability

• global usability

• partial usability

development of applications/services stalled on
global usability
global deployment
Proposal separate deployment from usability

• require global usability under partial deployment

any ISP can gate usability
low usage, user demand
independent innovation is high risk, yet offers
no competitive advantage
no incentive for ISPs to deploy IPvN
18
partial deployment ? global usability
X
IPv4
ISP A
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
(1) partial deployment ? multi-provider overlays
IPv4
ISP A
23
Achieving UA Two components
(2) universal access ? need redirection
IPv4
ISP A
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

• Who

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

26
Redirection Options

• Who
• user unwieldy

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

27
Redirection Options

• Who
• user unwieldy
• users ISP

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

28
Redirection Options

• Who
• user unwieldy
• users ISP
• participant ISPs

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

29
Redirection Options

• Who
• user unwieldy
• users ISP
• participant ISPs
• application-layer

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

30
Redirection Options

• Who
• user unwieldy
• users ISP
• participant ISPs
• application-layer
• network-layer

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• 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

• A is the IPv(N-1) address used to deploy IPvN
• IPvN routers advertise A into the IPv(N-1)
  routing protocol
• a discovers IPvN routers via IPv(N-1) routing
  protocol

IPv4 DST A
A
A
A
A
A
A
34
Redirection Options

• Who
• user unwieldy
• users ISP
• participant ISPs
• application-layer
• network-layer

• Recall Constraints
• partial deployment
• partial ISP participation
• participant ISP control
• no new players
• existing contracts

?
?
?
?
?
Caveat less flexible redirection
35
But, Isnt 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
Case 1 Destinations ISP supports IPvN
IPvN DST Dn
IPvN DST Dn
IPv4 DST A
IPv4 DST R
A
A
A
source
A
A
R
Dn
38
Case 2 Destinations ISP does not supports IPvN

• Two issues
• Addressing hosts in non-participant ISP domains

IPvN DST ?
IPv4 DST A
A
A
A
source
A
?
39
Case 2 Destinations ISP does not supports IPvN

• Two issues
• Addressing hosts in non-participant ISP domains
• proposal interim addressing à la RFC 3056

IPvN DST D4-to-n
IPv4 DST A
A
A
A
source
A
D4-to-n ? from D4
40
Case 2 Destinations ISP does not supports IPvN

• Two issues
• Addressing hosts in non-participant ISP domains
• Routing to hosts in non-participant ISP domains
  (paper)
• one proposal advertises D4s prefix into
  IPvN routing

R
D4-to-n ?
A
A
A
source
A
R
D4-to-n ? from D4
41
Case 2 Destinations ISP does not supports IPvN

• Two issues
• Addressing hosts in non-participant ISP domains
• Routing to hosts in non-participant ISP domains
  (paper)

A
A
IPv4 DST D4
A
source
A
D4-to-n from D4
42
Putting It All Together

• Summary Technical requirements for UA
• Redirection
• best achieved at the network-level
• anycast works under partial participation
• 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!