1.end to end arguments in system design (1981) 2.tussles in cyberspace: defining tomorrow’s...

32
1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and Principles

Upload: shauna-emmeline-rose

Post on 15-Jan-2016

218 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

1. End to end arguments in system design (1981)

2. Tussles in cyberspace: Defining Tomorrow’s Internet (2005)

Nick McKeown

CS244 Lecture 3

Architecture and Principles

Page 2: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

2

End-to-End Arguments in System Design

[Saltzer, Reed, Clark 1981] End-to-end in a nutshell

“The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)”

Page 3: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

3

Commonly used examples

1. Error handling in file transfer

2. End-to-end, versus in-network encryption

3. The partition between TCP and IP of error handling, flow control and congestion control.

Page 4: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

What you said

“For some applications, such as banking, application specific acknowledgements or transactions may be necessary to ensure consistency. In this respect, I think the question of what we define as an acceptable end-point is crucial in terms of what services we can expect the communication system to provide.”

4

Page 5: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

What you said

“I feel like this [paper] leads people to say, ‘This is bad because it violates the End to End Principle’, rather than, for example, ‘This is bad because it makes assumptions about what future applications might want.’ ”

-- Jason Clavelli

5

Page 6: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

6

Some consequences

• In layered design, the E2E principle provides guidance on where functions belong.

• “Dumb, minimal” network and “intelligent” end-points.

Many argue that:

E2E principle allowed the Internet to grow rapidly because innovation took place at the edge, in applications and services.

Page 7: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

7

On the other hand…

E2E principle appears to have become diluted: NATs, firewalls, VPN tunnel endpoints, …– Perhaps not surprising: E2E principle grew in an era

of trust among users. Now network must protect itself.

The network is no longer “dumb, minimal”– Now over 7,000 RFCs.– Router OS’s based on 100M lines of source code.

Q: Is this a problem?

Page 8: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

8

What belongs in, what out?

Questions:

•Does routing belong in the “dumb, minimal” network?

•How about multicast, mobility, QoS…?

•Are NATs necessary, good, or evil?

•Is the E2E principle constraining innovation of the infrastructure?

Page 9: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

9

Additional references

[rfc3724] “The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture” - Kempf et al.

[Blumenthal] “Rethinking the design of the Internet: The end-to-end arguments vs. the brave new world”, ACM Transactions on Internet Technology, Vol. 1, No. 1, August 2001, pp 70-109.

Page 10: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Tussle in Cyberspace: Defining Tomorrow’s Internet

10

Actor-Network Theory (ANT)

•Assumes equal treatment of humans and non-humans in an interacting network.•Distinction between ‘mediators’ and ‘intermediaries’: “silk and nylon”.

Page 11: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Context

Why did the authors write the paper?

What had changed since the Internet was invented?

11

Page 12: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Problem Statement“The Internet was created in simpler times. Its creators and early users shared a common goal —they wanted to build a network infrastructure to hook all the computers in the world together so that as yet unknown applications could be invented to run there. All the players, whether designers, users or operators, shared a consistent vision and a common sense of purpose.”

“Perhaps the most important consequence of the Internet’s success is that the common purpose that launched and nurtured it no longer prevails.”

12

Page 13: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Types of Tussle

1. Economics

2. Trust

1. Openness

13

Page 14: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Trust

“One of the most profound and irreversible changes in the Internet is that by and large, many of the users do not trust each other. The users of the Internet no longer represent a single community with common motivation and shared trust.”

“[There] is a profound tussle, between people who want to be left alone, and people who want to bother them.”

Q: How are we encouraged to think about this?

14

Page 15: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

What you said

“The design of interfaces is the common theme linking the Tussle paper and the end-to-end argument paper we are discussing…I agree the end-to-end argument is still valid today, but the transparency it encourages needs more careful considerations in a playing field where trust cannot be taken for granted.”

-- Ana Klimovic

15

Page 16: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

What you said

“I'm pessimistic that there is much that system designers can do to bias the tussle in favor of the user at this point. Consider the recent net neutrality debate…”

--Wen-Chen Chen

16

Page 17: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Questioning sacred cows

1. End to end argumentQ: How is it affected by “tussles”?

1. Separate policy from mechanismQ: What does it mean?

If the goal is to hook computers together and let users run any application they want, then a simple transparent network enables “user empowerment”, choice and innovation.

17

Page 18: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

A lesson

Hypothesis about QoS: Internet providers had no incentive to deploy.

1.There is a real cost to deploy

2.Users had no way to choose providers (local or remote).

Q: How is this related to tussles?

18

Page 19: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Consequences

What do the authors recommend we do?

What are the concrete steps?

19

Page 20: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Context for Next Class

20

Page 21: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Software Defined Network (SDN)

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

PacketForwarding

ControlControl

ControlControl

ControlControl

ControlControl

ControlControl

Global Network Map

Control Plane

ControlProgram

ControlProgram

ControlProgram

Page 22: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Software Defined Network

A network in which the control plane is physically separate from the forwarding

plane.

and

A single control plane controls several forwarding devices.

(That’s it)

Page 23: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

Software Control PlaneSoftware Control Plane

Intended consequences...1.Put network owners and operators in control.2.Networks that are more reliable and more secure.3.Networks that cost less: simpler, streamlined hardware.4.Networks that cost less to operate (fewer features).

SDN

Page 24: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

An exampleRouting

Page 25: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and
Page 26: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and
Page 27: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

function Dijkstra(Graph, source):for each vertex v in Graph:

dist[v] := infinity ;

previous[v] := undefined;

dist[source] := 0 ;

Q := the set of all nodes in Graph ;

while Q is not empty: // The main loop

u := vertex in Q with smallest distance in dist[] ;

remove u from Q ;

if dist[u] = infinity:

break ;

for each neighbor v of u:

alt := dist[u] + dist_between(u, v) ;

if alt < dist[v]:

dist[v] := alt ;

previous[v] := u ;

decrease-key v in Q;

return dist[], previous[];

end function

Edsger Dikjstra 1930-2002

Photo: Hamilton Richards

Page 28: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

The Opte Project

Page 29: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and
Page 30: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

1 2

3

“If , send to 3”

“If a packet is going to B, then send it to output 3”

1. Figure out which routers and links are present.2. Run Dijkstra’s algorithm to find shortest paths.

Page 31: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

95%

5%

50,000 lines of code50,000 lines of code

50,000 lines of code

1. Figure out which routers and links are present.2. Run Dijkstra’s algorithm to find shortest paths.

Page 32: 1.End to end arguments in system design (1981) 2.Tussles in cyberspace: Defining Tomorrow’s Internet (2005) Nick McKeown CS244 Lecture 3 Architecture and

DijkstraDijkstra

Network OSNetwork OS

IS-ISIS-IS BGPBGP MPLSMPLS Firewall…Firewall…

Global Network Map