Towards an evolvable internet architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 47

Towards an Evolvable Internet Architecture PowerPoint PPT Presentation


  • 102 Views
  • Uploaded on
  • Presentation posted in: General

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.). hh Folklore ff. The Internet Architecture needs fixing

Download Presentation

Towards an Evolvable Internet Architecture

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

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


Hh folklore ff

hhFolkloreff

  • 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

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)


Overlays to the rescue v11

Overlays to the Rescue (v1)

Use overlays to augment IP

  • Implement change in application-level `routers’

  • Practical

    • bypass CISCO and the ISPs


Overlays to the rescue v12

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


Overlays to the rescue v13

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


Overlays v2

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 v21

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


Overlays v22

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)


Overlays v23

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?


This paper

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

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

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


Towards an evolvable internet architecture

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


Toy example

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

    Deploying IPvN

    scale  partial deployment a necessity

    partial deployment  partial usability

    CP

    IPv4

    ISP A


    Partial deployment partial usability

    partial usability

    global usability

    partial deployment  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


    Partial deployment global usability

    partial deployment  global usability

    X

    IPv4

    ISP A


    Universal access

    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

    Outline

    • Toy Example: deploying IPvN

    • Universal Access

    • Implementing Universal Access

      • constraints

      • two components

      • putting it all together

    • Conclusion


    Achieving ua

    Achieving UA

    Constraints:

    • partial deployment

    • partial ISP participation

    • allow participating ISPs control

    • existing players

    • existing contractual agreements


    Achieving ua two components

    Achieving UA: Two components

    (1) partial deployment  multi-provider overlays*

    IPv4

    ISP A


    Achieving ua two components1

    Achieving UA: Two components

    (2) universal access  need redirection

    IPv4

    ISP A


    Redirection for ua

    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

    Redirection: Options

    Who

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Redirection options1

    Redirection: Options

    Who

    • user: unwieldy

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Redirection options2

    Redirection: Options

    Who

    • user: unwieldy

    • user’s ISP

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Redirection options3

    Redirection: Options

    Who

    • user: unwieldy

    • user’s ISP

    • participant ISPs

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Redirection options4

    Redirection: Options

    Who

    • user: unwieldy

    • user’s ISP

    • participant ISPs

    • application-layer

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Redirection options5

    Redirection: Options

    Who

    • user: unwieldy

    • user’s ISP

    • participant ISPs

    • application-layer

    • network-layer

    Recall Constraints

    • partial deployment

    • partial ISP participation

    • participant ISP control

    • no new players

    • existing contracts


    Network layer redirection

    Network-Layer Redirection

    Routers perform redirection


    Network layer redirection1

    Network-Layer Redirection

    Routers perform redirection

    • Challenge: no explicit participation from ‘ ’


    Proposal use ip anycast

    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

    • adiscovers IPvN routers via IPv(N-1) routing protocol

    IPv4 DST = A

    A

    A

    A

    A

    A

    A


    Redirection options6

    Redirection: Options

    Who

    • user: unwieldy

    • user’s 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


    But isn t anycast a non starter

    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


    Outline1

    Outline

    • Toy Example: deploying IPvN

    • Universal Access

    • Implementing Universal Access

      • constraints

      • two pieces

      • putting it all together

    • Conclusion


    Putting it all together

    Putting It All Together

    Case 1: Destination’s ISP supports IPvN

    IPvN DST =Dn

    IPvN DST =Dn

    IPv4 DST = A

    IPv4 DST = R

    A

    A

    A

    source

    A

    A

    R

    Dn


    Towards an evolvable internet architecture

    Case 2: Destination’s ISP does not supports IPvN

    • Two issues:

      • Addressing hosts in non-participant ISP domains

    IPvN DST = ?

    IPv4 DST = A

    A

    A

    A

    source

    A

    ?


    Towards an evolvable internet architecture

    Case 2: Destination’s 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


    Towards an evolvable internet architecture

    Case 2: Destination’s 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 D4’s prefix into IPvN routing

    R

    D4-to-n ?

    A

    A

    A

    source

    A

    R

    D4-to-n from D4


    Towards an evolvable internet architecture

    Case 2: Destination’s 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


    Putting it all together1

    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


    Open questions

    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

    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


    Conclusion1

    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


    Conclusion2

    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


    Towards an evolvable internet architecture

    Thank you!


  • Login