Building a Coreless Internet Without Ripping Out the Core - - PowerPoint PPT Presentation

▶
building a coreless internet without ripping out the core
SMART_READER_LITE
LIVE PREVIEW

Building a Coreless Internet Without Ripping Out the Core - - PowerPoint PPT Presentation

Apr 08, 2024 232 likes •597 views

Building a Coreless Internet Without Ripping Out the Core (goodell@eecs.harvard.edu) Geoffrey Goodell (sob@harvard.edu) Scott Bradner (mema@eecs.harvard.edu) Mema Roussopoulos VE R I TAS Harvard University HOTNETS-IV: 14 November 2005 1

slide-1
SLIDE 1

Building a Coreless Internet Without Ripping Out the Core

Geoffrey Goodell

(goodell@eecs.harvard.edu)

Scott Bradner

(sob@harvard.edu)

Mema Roussopoulos

(mema@eecs.harvard.edu)

VE TAS R I

Harvard University HOTNETS-IV: 14 November 2005

1

slide-2
SLIDE 2

The Dream

  • All clients have access to all resources.

2

slide-3
SLIDE 3

The Reality

  • Access to network resources is a function of location

within the topology.

3

slide-4
SLIDE 4

Blossom Approach

  • A peer-to-peer overlay network for sharing

perspectives.

4

slide-5
SLIDE 5

Blossom Vision

  • A Coreless Internet: the meaning of names and

addresses is a function of their context.

5

slide-6
SLIDE 6

“The IP suite imposes a single networking model and addressing scheme over the many different underlying network types it supports... Although helpful for a number of years, while the network was undergoing its initial ‘big bang’ phase, the approximations in the model are now becoming too out-of-step with reality.” —Jon Crowcroft et al., Plutarch, 2003

6

slide-7
SLIDE 7

“Without consensus, some experts say that countries might move ahead with setting up their own domain name system, or DNS, as a way of bypassing Icann. “The United States argues that a single addressing system is what makes the Internet so powerful, and moves to set up multiple Internets would be in no one’s interest.” —Tom Wright, “EU Tries to Unblock Internet Impasse.” The New York Times, 30 September 2005

7

slide-8
SLIDE 8

Some Types of Fragmentation

  • Firewalls (Security)
  • NAT

– Network Isolation (Management) – Perception of Address Scarcity (Business Model)

  • Others: Content Filtering, Multiple Namespaces

(Political), Anycast (Efficiency), etc.

8

slide-9
SLIDE 9

The Inherent Conflict

  • Homogenization promotes universal access and

consistency

  • Fragmentation provides distributed management

and location specificity

  • Both are essential to the success of the Internet

9

slide-10
SLIDE 10

Blossom Central Principles

  • [1] Eliminate access restrictions derived from how an
  • bserver is connected to the network.
  • [2] Allow an observer to select a perspective from

which to view and access network resources.

10

slide-11
SLIDE 11

What We Gain

11

slide-12
SLIDE 12

What We Gain [1]: Locality

Multiple services with the same name may coexist within different local namespaces (meaningful names within a local space).

12

slide-13
SLIDE 13

What We Gain [2]: Universal Access

If A can talk to B and B can talk to C, then B can talk to C

  • n behalf of A (circumvent technical barriers).

13

slide-14
SLIDE 14

What We Gain [3]: Distributed Management

Adding a network and its abundance of resources to the system need not require specific allocation of names, anddresses, or routing from centralized authorities.

14

slide-15
SLIDE 15

What We Gain [4]: Deployability

  • Must function in the absence of explicit participation
  • f service providers:

– Network access providers (ISPs) – Content providers (legacy Internet services)

  • Must provide substantial benefit in the absence of

widespread adoption

  • Must require minimal (preferably zero) modification to

OS or application software

15

slide-16
SLIDE 16

Accessing a Resource

  • Our implementation uses Tor to build circuits.

16

slide-17
SLIDE 17

Blossom Setup

17

slide-18
SLIDE 18

Establish persistent connection

18

slide-19
SLIDE 19

Publish to directory server

19

slide-20
SLIDE 20

Clients can now access Resources

20

slide-21
SLIDE 21

Coreless Approach: LOCAL directory servers

21

slide-22
SLIDE 22

Directory Propagation (Control Plane)

22

slide-23
SLIDE 23

Design Tradeoffs (What We Lose)

  • New Namespace Constraints.

– Do we need globally unique identifiers? – Do we need a new DNS?

  • New Discovery Constraints.

– Request forwarders by attributes rather than name

  • New Scalability Constraints.

– Directory Size. – Control Messages.

23

slide-24
SLIDE 24

Empirical Questions

  • How far can Blossom scale...

– ...before connection latency becomes intolerable for users? – ...before directory sizes become unmanageable?

  • What can we do to minimize the size and frequency
  • f control messages?
  • How can we measure the performance of our

transport mechanism (e.g. Tor)?

24

slide-25
SLIDE 25

Philosophical Questions

  • What do we lose by building circuits rather than

sending independent datagrams?

  • How can we use Blossom to enhance Internet

search?

  • How can Blossom co-exist with reasonable policies

established to restrict access to Internet resources?

  • How can Blossom co-exist peacefully with

unreasonable causes of fragmentation (e.g.

  • ppressive regimes)?

25

slide-26
SLIDE 26

http://afs.eecs.harvard.edu/˜goodell/blossom/

26

slide-27
SLIDE 27

Tor Architecture

27

slide-28
SLIDE 28

Blossom Architecture

28

slide-29
SLIDE 29

Routing Around Obstacles

  • TRIAD (Cheriton/Gritter 00)

– uses globally-unique, hierarchical, DNS-style names to identify networks – names propagate through system using BGP-like advertisements

  • RON (Andersen et al. 01)

– heal network topology by responding faster than BGP – limited to small confederations

29

slide-30
SLIDE 30

Indirection

  • I3 (Stoica et al. 02)

– register services with the infrastructure – use a commonly-accessible rendezvous point for connectivity – substantial inspiration for later work

30

slide-31
SLIDE 31

Decoupling Policy from Mechanism

  • FARA (Clark et al. 03)

– create associations between nodes without requiring global namespace – provides a general framework for discovery

  • Platypus (Snoeren/Raghavan 03)

– enforce routing policy should on forwarding plane rather than control plane – relies upon cooperation from network access providers

31

slide-32
SLIDE 32

Interoperating with Middleboxes

  • UIP (Ford 03)

– argument: hierarchical naming provides efficiency/scalability at the cost of flexibility – create single, flat namespace for accessing UIP-enabled resources

  • DOA (Walfish 04)

– middleboxes no longer considered harmful – create network extension boxes to provide seamless e2e access to DOA resources

32

slide-33
SLIDE 33

Non-Universal Namespaces

  • Untangling the Web (Walfish 04)

– DNS hostnames have special value derived from content provided by web services – semantic-free referencing to provide globally-unique self-certifying names – client resolves names to semantic-free tags using third-party service, uses resolved tag to access content

33

slide-34
SLIDE 34

Extending NATs

  • IPNL (Francis/Gummadi 01)

– FQDNs as end-system identifiers – stateless routers (part of network-layer infrastructure) – site-centric: requires configuration and deployment

  • f “frontdoors” between private networks and the

core

34

slide-35
SLIDE 35

Embracing Heterogeneity

  • Plutarch (Crowcroft et al. 03)

– coreless – acknowledges fragmentation as inevitable – requires special configuration of middleboxes to act as gateways between “contexts” – resolves names via a peer-to-peer search

35