Transcript Towards an Evolvable Internet Architecture

change IP (routers, headers, addressing, …)
Towards an Evolvable
Internet Architecture
IP layer
Sylvia Ratnasamy (Intel Research),
Scott Shenker (U.C. Berkeley/ICSI),
Steven McCanne (Riverbed Tech.)
Presenter: Kai Chen and Alex Kiaie
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 don’t deploy these fixes
– Exception: IP Multicast, IPv6 are the successful stories!
• This contradiction produces two reactions.
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)
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
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
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.
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
Overlays (v2)
Use overlays to undermine ISPs [Peterson, etc., 04]
•
•
Next-Generation Service Provider (NGSP)
Eventually, NGSP replaces ISPs
– By leasing dedicated lines
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)
Overlays (v2)
Use overlays to undermine ISPs [Peterson, Shenker, Turner 04]
•
Next-Generation Service Provider (NGSP)
•
Eventually, NGSP replaces ISPs
•
Are therepractical
other (more
conservative) options?
Technically,
and broad
But, requires disrupting the existing market structure
•
Evolution through (repeated) revolution
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
–
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 aren’t the right ones
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
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
Deploying IPvN
Scalable,
flexible
 partial
a necessity
partial
deployment
deployment
partial usability
CP
Servers
IPv4
ISP A
partial deployment  partial usability
partial usability
global usability
development of
global deployment
applications/services
Proposal: separate deployment from usability
stalled on global usability
• require global usability under partial deployment
any ISP can gate usability
low usage, user demand
no incentive for
ISPs to deploy IPvN
high risk, yet offers no
competitive advantage
for ISPs to deploy IPvN.
partial deployment  global usability
X
IPv4
ISP A
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
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
(1) partial deployment  multi-provider overlays*
IPv4
ISP A
Achieving UA: Two components
(2) universal access  need redirection
IPv4
ISP A
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
Redirection: Options
Who
Recall Constraints
•
1.
partial deployment
2.
partial ISP participation
3.
participant ISP control
4.
no new players
5.
existing contracts
user: unwieldy
Redirection: Options
Who
Recall Constraints
•
user: unwieldy
1.
partial deployment
•
user’s ISP
2.
partial ISP participation
3.
participant ISP control
4.
no new players
5.
existing contracts
Redirection: Options
Who
Recall Constraints
•
user: unwieldy
1.
partial deployment
•
user’s ISP
2.
partial ISP participation
•
participant ISPs
3.
participant ISP control
4.
no new players
5.
existing contracts
Redirection: Options
Who
Recall Constraints
•
user: unwieldy
1.
partial deployment
•
user’s ISP
2.
partial ISP participation
•
participant ISPs
3.
participant ISP control
•
application-layer
4.
no new players
5.
existing contracts
Redirection: Options
Who
Recall Constraints
•
user: unwieldy
1.
partial deployment
•
user’s ISP
2.
partial ISP participation
•
participant ISPs
3.
participant ISP control
•
application-layer
4.
no new players
•
network-layer
5.
existing contracts
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
IPv4 DST = A
A
A
A
A
A
A
Redirection: Options
Who
•
user: unwieldy
•
user’s ISP
•
participant ISPs
•
application-layer
•
network-layer*
Recall Constraints
1.
2.
 3.
 4.
 5.
*Caveat: less flexible redirection
partial deployment
partial ISP participation
participant ISP control
no new players
existing contracts
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
Case 1: Destination’s ISP supports IPvN
IPvN DST =Dn
IPvN DST =Dn
IPv4 DST = A
IPv4 DST = R
A
source
A
A
A
A
R
Dn
Case 2: Destination’s ISP does not supports IPvN
Two issues:
1. Addressing hosts in non-participant ISP domains
IPvN DST = ?
IPv4 DST = A
A
source
A
A
A
?
Case 2: Destination’s ISP does not supports IPvN
Two issues:
1. Addressing hosts in non-participant ISP domains
• proposal: interim addressing à la RFC 3056
IPvN DST = D4-to-n
IPv4 DST = A
A
source
A
A
A
D4-to-n  from D4
Case 2: Destination’s ISP does not supports IPvN
Two issues:
1. Addressing hosts in non-participant ISP domains
2. Routing to hosts in non-participant ISP domains (paper)
• one proposal: R advertises D4’s prefix into IPvN routing
D4-to-n ?
A
source
A
A
A
R
D4-to-n  from D4
Case 2: Destination’s ISP does not supports IPvN
Two issues:
1. Addressing hosts in non-participant ISP domains
2. Routing to hosts in non-participant ISP domains (paper)
A
source
A
A
IPv4 DST = D4
A
D4-to-n = from 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!