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.) Presenter Kai Chen and Alex
Kiaie
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 these fixes
• Exception IP Multicast, IPv6 are the successful
  stories!
• This contradiction produces two reactions.

3
Overlays to the Rescue (v1)

• Use overlays to augment IP
• Overlays have been proposed for many services
• 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
• Overlays have been proposed for many services
• Overlay is practical
• bypass CISCO and the ISPs

5
Overlays to the Rescue (v1)

• Use overlays to augment IP
• Overlays have been proposed for many services
• Overlay is practical
• Overlay is often appropriate
• keep complexity out of IP

6
Overlays to the Rescue (v1)

• Use overlays to augment IP
• Overlays have been proposed for many services
• Overlay is practical
• Overlay is often appropriate
• Although these overlay technologies would not
  lead to fundamental changes in the underlying
  Internet architecture, they would only mask some
  of its most obvious deficiencies.

7
Overlays (v2)

• Use overlays to undermine ISPs Peterson, etc.,
  04
• Next-Generation Service Provider (NGSP)
• Use overlays for a new architecture atop existing
  ISPs
• Legacy ISPs only serve to access NGSP

8
Overlays (v2)

• Use overlays to undermine ISPs Peterson, etc.,
  04
• Next-Generation Service Provider (NGSP)
• Eventually, NGSP replaces ISPs
• By leasing dedicated lines

9
Overlays (v2)

• Use overlays to undermine ISPs Peterson, etc.,
  04
• Next-Generation Service Provider (NGSP)
• 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)
• 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
• Internet service providers have little incentive
  to innovate
• 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

13
This Paper Focus on architectural barriers 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

14
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

15
Deploying IPvN
Scalable, flexible ? partial deployment a
necessity
partial deployment ? partial usability
CP
IPv4
ISP A
16
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
high risk, yet offers no competitive advantage
for ISPs to deploy IPvN.
no incentive for ISPs to deploy IPvN
17
partial deployment ? global usability
X
IPv4
ISP A
18
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

19
Outline

• Toy Example deploying IPvN
• Universal Access
• Implementing Universal Access
• constraints
• two components
• putting it all together
• Conclusion

20
Achieving UA

• Constraints
• partial deployment
• partial ISP participation
• allow participating ISPs control
• existing players
• existing contractual agreements

21
Achieving UA Two components
(1) partial deployment ? multi-provider overlays
IPv4
ISP A
22
Achieving UA Two components
(2) universal access ? need redirection
IPv4
ISP A
23
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

24
Redirection Options

• Who

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

25
Redirection Options

• Who
• user unwieldy

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

26
Redirection Options

• Who
• user unwieldy
• users ISP

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

27
Redirection Options

• Who
• user unwieldy
• users ISP
• participant ISPs

• 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
• application-layer

• 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
• network-layer

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

30
Network-Layer Redirection
Routers perform redirection
31
Network-Layer Redirection
Routers perform redirection
Challenge no explicit participation from

32
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

IPv4 DST A
A
A
A
A
A
A
33
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
34
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

35
Outline

• Toy Example deploying IPvN
• Universal Access
• Implementing Universal Access
• constraints
• two pieces
• putting it all together
• Conclusion

36
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
37
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
?
38
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
39
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
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)

A
A
IPv4 DST D4
A
source
A
D4-to-n from D4
41
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

42
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

43
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

44
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

45
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

46

• Thank you!