towards an evolvable internet architecture

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.)

Folklore

• 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 don’t deploy (our) fixes– IP Multicast, IPv6 are the success stories!

• One reaction: ``Who needs the ISPs

anyway?’’

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)



`routers’• Practical

– bypass CISCO and the ISPs



`routers’• Practical• Often even appropriate

– keep complexity out of IP



`routers’• Practical• Often even appropriate

But, if the problem is best solved at the IP layer, this doesn’t help

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

Overlays (v2)



• Eventually, NGSP replaces ISPs– lease dedicated lines

Overlays (v2)



• Eventually, NGSP replaces ISPs

• Technically, practical and broad– (and invaluable as an experimental platform)

Overlays (v2)



• 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?

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)

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

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

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?

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 Servers

Deploying IPvN

IPv4ISP A

CP

Servers

scale partial deployment a necessitypartial deployment partial usability

partial deployment partial usability

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

partial deployment global usability

IPv4ISP A

X

Servers

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

Outline

• Toy Example: deploying IPvN• Universal Access• Implementing Universal Access

– constraints– two components– putting it all together

• Conclusion

Achieving UA

Constraints:– partial deployment

– partial ISP participation

– allow participating ISPs control

– existing players– existing contractual agreements

Achieving UA: Two components

IPv4ISP A

(1) partial deployment multi-provider overlays*

Achieving UA: Two components

IPv4ISP A

(2) universal access need redirection

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

Redirection: Options

Who Recall Constraints

1. partial deployment

2. partial ISP

participation

3. participant ISP

control

4. no new players

5. existing contracts


Who

• user: unwieldy

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players



Who

• user: unwieldy

• user’s ISP

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players



Who

• user: unwieldy

• user’s ISP

• participant ISPs

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players



Who

• user: unwieldy

• user’s ISP


• application-layer

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players



Who

• user: unwieldy

• user’s ISP



• network-layer

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players


Network-Layer Redirection

Routers perform redirection

Network-Layer Redirection

Routers perform redirection

Challenge: no explicit participation from ‘ ’

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 AA

AAA

IPv4 DST = A


Who

• user: unwieldy

• user’s ISP



• network-layer*

Recall Constraints


2. partial ISP

participation

3. participant ISP

control

4. no new players


*Caveat: less flexible redirection

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

Outline

• Toy Example: deploying IPvN• Universal Access• Implementing Universal Access

– constraints– two pieces– putting it all together

• Conclusion

Putting It All Together

A AA

IPv4 DST = A

Dn

source

IPvN DST =Dn

A A

Case 1: Destination’s ISP supports IPvN

IPv4 DST = R

IPvN DST =Dn

R

A AA

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

A AA

IPv4 DST = A

D4-to-n from D4

source

IPvN DST = D4-to-n

A

Two issues:


• proposal: interim addressing à la RFC 3056


A AA

D4-to-n from D4

sourceA

Two issues:


2. Routing to hosts in non-participant ISP domains (paper)

• one proposal: advertises D4’s prefix into IPvN routing


D4-to-n ?

R

R

A AA

D4-to-n = from D4

sourceA

Two issues:


2. Routing to hosts in non-participant ISP domains (paper)


IPv4 DST = D4

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

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

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

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

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

Thank you!

towards an evolvable internet architecture

Documents