Internet design history and goals
This presentation is the property of its rightful owner.
Sponsored Links
1 / 76

Internet Design History and Goals PowerPoint PPT Presentation


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

Internet Design History and Goals. EE122 Fall 2012 Scott Shenker http:// inst.eecs.berkeley.edu /~ee122/ Materials with thanks to Jennifer Rexford, Ion Stoica , Vern Paxson and other colleagues at Princeton and UC Berkeley. Administrivia. Keep those questions coming!

Download Presentation

Internet Design History and Goals

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


Internet design history and goals

Internet Design Historyand Goals

EE122 Fall 2012

Scott Shenker

http://inst.eecs.berkeley.edu/~ee122/

Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley


Administrivia

Administrivia

  • Keep those questions coming!

    • It will take a while for me to calibrate length of lectures

  • Questions about switching sections?

    • Email Kay [email protected], cc me.

  • Check your bspace email address!

    • Make sure it is an account you check

    • If you miss a future bspace message, it is your fault

  • Everyone should be on Piazza now

    • Again, we now view Piazza communications as reliable


Outline for today

Outline for Today

  • Finishing up queueing

  • Statistical Multiplexing

  • Why did we choose packet-switching?

  • Internet history

  • Internet design goals

  • Protocols, Clients and Servers,….


Finishing up queueing delays

Finishing Up Queueing Delays


Queueing delay review

QueueingDelay Review

  • Does not happen if packets are evenly spaced

    • And arrival rate is less than service rate

  • Queueing delay caused by “packet interference”

    • Burstiness of arrival schedule

    • Variations in packet lengths

  • Made worse at high load

    • Less “idle time” to absorb bursts

    • Think about traffic jams in rush hour….


Jitter

Jitter

  • Difference between minimum and maximal delay

  • Latency (propagation delay) plays no role in jitter

    • Nor does transmission delay for same sized packets

  • Jitter typically just differences in queueing delay

  • Why might an application care about jitter?


Packet losses

Packet Losses

  • Packets can be “dropped” or lost

  • How?


Packet losses buffers full

Packet Losses: Buffers Full


Packet losses corruption

Packet Losses: Corruption


Packet losses1

Packet Losses

  • Where should packet corruption be detected?

    • In network?

    • At host?

  • Other ways packets can be lost?

    • TTL!


Basic queueing theory terminology

Basic Queueing Theory Terminology

  • Arrival process: how packets arrive

    • Average rate A

    • Peak rate P

  • Service process: transmission times

    • Average transmission time

    • For networks, function of packet size

  • W: average time packets wait in the queue

    • W for “waiting time”

  • L: average number of packets waiting in the queue

    • L for “length of queue”

  • Two different quantities


Little s law 1961

Little’s Law (1961)

L = A x W

  • Compute L: count packets in queue every second

    • This is the straightforward approach, easy to compute

  • How often does a packet get counted? W times

    • The average arrival rate determines how frequently this total queue occupancy should be added to the total

  • Why do you care?

    • Easy to compute L, harder to compute W

    • But W is what applications notice, so that’s what we want


Statistical multiplexing

Statistical Multiplexing


Three flows with bursty arrivals

Three Flows with Bursty Arrivals

Data Rate 1

Time

Data Rate 2

Capacity

Time

Data Rate 3

Time


When each flow gets 1 3 rd of capacity

When Each Flow Gets 1/3rd of Capacity

Frequent Overloading

Data Rate 1

Time

Data Rate 2

Time

Data Rate 3

Time


When flows share total capacity

When Flows Share Total Capacity

Time

No Overloading

Time

Statistical multiplexing relies on the assumption

that not all flows burst at the same time.

Very similar to insurance, and has same failure case

Time


Demonstration i need 8 volunteers

Demonstration: I need 8 volunteers!

  • Each generates 0, 1, or 2 chocolates per cycle

    • But can’t eat more than one per cycle

    • Must discard excess

  • One group of 4: each keeps own chocolates

  • Other group of 4: share all chocolates

  • Who eats more chocolate?


Observations

Observations

  • In no case does sharing result in less consumption

    • Sharing is strictly better in terms of utilization

    • It does need to deal with congestion (later)

  • When the number of entities sharing grows large,can use the “law of large numbers”

    • The average of n samples from any probability distribution is close to the average of the distribution

  • When you have many flows sharing a link, you can provision for the average (plus a little) load, not the peak loads.


Improved delays m m 1 queue

Improved Delays: M/M/1 Queue

  • Consider n flows sharing a single queue

  • Flow: random (Poisson) arrivals at rate l

  • Random (Exponential) service with average 1/m

  • Utilization factor: r = nl/m

    • If r >1, system is unstable

  • Case 1: Flows share bandwidth

    • Delay = 1/( - n)

  • Case 2: Flows each have 1/nth share of bandwidth

    • No sharing

    • Delay = n/( - n) Not sharing increases delay by n


If you still don t understand stat mux

If you still don’t understand stat mux

  • Will cover in section….

  • Will not be tested on M/M/1 content

    • This is just for “fun”


Recurrent theme in computer science

Recurrent theme in computer science

  • Greater efficiency through “sharing”

    • Statistical multiplexing

  • Phone network rather than dedicated lines

    • Ancient history

  • Packet switching rather than circuits

    • Lastlecture

  • Cloud computing

    • Shared datacenters, rather than single PCs


Choosing a network design

Choosing a Network Design


If you were building a network

If you were building a network….

  • Which would you choose?

    • Circuit switched?

    • Packet-switched (Datagram)?

  • Let’s review the strengths and weaknesses


Advantages of circuit switching

Advantages of Circuit Switching

  • Guaranteed bandwidth

    • Predictable communication performance

    • Not “best-effort” delivery with no real guarantees

  • Simple abstraction

    • Reliable communication channel between hosts

    • No worries about lost or out-of-order packets

  • Simple forwarding

    • Forwarding based on time slot or frequency

    • No need to inspect a packet header

  • Low per-packet overhead

    • Forwarding based on time slot or frequency

    • No headers on each packet


Disadvantages of circuit switching

Disadvantages of Circuit-Switching

  • Wasted bandwidth

    • Bursty traffic leads to idle connection during silent period

  • Blocked connections

    • Connection refused when resources are not sufficient

    • Unable to offer “okay” service to everybody

  • Network state

    • Network nodes must store per-connection information

    • This makes failures more disruptive!


Advantages of datagram

Advantages of Datagram

  • Recovery from failures

    • Routers don’t know about individual flows, so it is easy to fail over to a different path

  • Efficiency

    • Exploits of statistical multiplexing

  • Deployability

    • Easier for different parties to link their networks together because they are not promising to reserve resources for one another


Disadvantages of datagram

Disadvantages of Datagram

  • Worse service for flows

    • No promises made about delays, just “best effort”

    • Packets might be dropped or delivered out of order

    • End hosts must cope with out-of-order packets

  • Must deal with congestion

    • Without reserved resources, must cope with overloads

    • Overloads can result in bad service for flows

  • More complicated forwarding

    • Per-packet lookups, etc.


Choosing a design for the internet

Choosing a Design for the Internet

  • Which would you choose? And why?

  • Not so fast…..

    • Hindsight is great

    • But there were important reasons to choose differently


The paradox of the internet s design

The paradox of the Internet’s design

  • As we will discuss later, one of the main design goals is to support a wide range of apps

  • These applications have different requirements

  • Shouldn’t the Internet support them all?


Diversity of application requirements

Diversity of application requirements

  • Size of transfers

  • Bidirectionality (or not)

  • Delay sensitive (or not)

  • Tolerance of jitter(or not)

  • Tolerance of packet drop (or not)

  • Need for reliability (or not)

  • Multipoint (or not)

  • …..


Diversity of application requirements1

Diversity of application requirements

  • Size of transfers

  • Bidirectionality (or not)

  • Delay sensitive (or not)

  • Tolerance of jitter(or not)

  • Tolerance of packet drop (or not)

  • Need for reliability (or not)

  • Multipoint (or not)

  • …..


What service should internet support

What service should Internet support?

  • Strict delay bounds?

    • Some applications require them

  • Guaranteed delivery?

    • Some applications are sensitive to packet drops

  • No applications mind getting good service

    • Why not require Internet support these guarantees?


Important life lessons

Important life lessons

  • People (applications) don’t always need what they think they need

  • People (applications) don’t always need what we think they need

  • Flexibility often more important than performance

    • But typically only in hindsight!

    • Example: cell phones vs landlines

  • Architect for flexibility, engineer for performance


Applying lessons to internet

Applying lessons to Internet

  • Requiring performance guarantees would limit variety of networks that could attach to Internet

  • Many applications don’t need these guarantees

  • And those that do?

    • Well, they don’t either (usually)

    • Tremendous ability to mask drops, delays

  • And ISPs can work hard to deliver good service without changing the architecture

  • If the Internet had focused on voice applications early, it might have made different choices


Bottom line

Bottom Line

  • The choice of datagram service is not as obvious as it might seem today

  • Great vision on the part of the Internet designers

  • And lucky that they were focused on applications that did not need great service


Internet history

Internet History


Timeline

Timeline

1961Baran and Kleinrock advocate packet switching

1962Licklider’s vision of Galactic Network

1965Roberts connects two computers via phone

1967Roberts publishes vision of ARPANET

  • BBN installs first IMP at UCLA

    IMP: Interface Message Processor

    1971 Network Control Program (protocol)

    1972Public demonstration of ARPANET


The beginning of the internet revolution

The beginning of the Internet revolution

  • Kleinrock’s group at UCLA tried to log on to Stanford computer: His recollection of the event…

  • We typed the L…

    • “Do you see the L?”

    • “Yes, we see the L.”

  • We typed the O…

    • “Do you see the O?”

    • “Yes, we see the O.”

  • Then we typed the G…

    • …and the system crashed!


Timeline continued

Timeline continued…

  • Email invented

    1972 Telnet introduced

    1972Kahn advocates Open Architecture networking


The problem

The Problem

  • Many different packet-switching networks

  • Only nodes on the same network could communicate


Kahn s rules for interconnection

Kahn’s Rules for Interconnection

  • Each network is independent and must not be required to change (why?)

  • Best-effort communication (why?)

  • Boxes (routers) connect networks

  • No global control at operations level (why?)


Solution

Solution

Gateways


Kahn s vision

Kahn’s vision

  • Kahn imagined there would be only a few networks (~20) and thus only a few routers

  • He was wrong

    • Why?

  • Imagined gateways would “translate” between networks

    • We think of it as all routers supporting IP


Timeline continued1

Timeline continued….

1973 FTP introduced

1974Cerf and Kahn paper on TCP/IP

1980TCP/IP adopted as defense standard

1983Global NCP to TCP/IP flag day

198xXNS, DECbit, and other protocols

1984Janet (British research network)

1985NSFnet (picks TCP/IP)

198xInternet meltdowns due to congestion

1986Van Jacobson saves the Internet (BSD TCP)


Unsung hero of internet david d clark

Unsung hero of Internet: David D. Clark

  • Chief Architect 1981-1988

  • Great consistency of vision

  • Kept the Internet true to its basic design principles

  • Authored what became known as the End-to-end principle (next lecture)

  • Conceives and articulates architectural concepts

    • Read his “Active Networking and End-To-End Arguments”

  • Perhaps the only “irreplaceable” Internet pioneer


Timeline continued2

Timeline continued…

  • Deeringand Cheriton propose multicast

  • Birth of the web….Tim Berners-Lee


Why did it take physicist to invent web

Why did it take physicist to invent web?

  • Physicists are the smartest people in the world?

  • Computer scientists were trying to invent nirvana

    • Well, actually Xanadu (Ted Nelson)

    • More generally, CS researchers focused on hyptertext

  • Again, users didn’t need what we wanted to invent

    • Think about it: a paper on the web design would have been rejected by every CS conference and journal

  • In general, the CS research community is great at solving well-defined problems, but terrible at guessing what users will actually use

    • “Academics get paid for being clever, not for being right.”

      …Don Norman


Timeline continued3

Timeline continued…..

1993 Search engines invented (Excite)

199xATM rises and falls (as internetworking layer)

199xQoS rises and falls

1994 Internet goes commercial

  • IPv6 specification

    1998 Google reinvents search

    200xThe Internet boom and bust

    2012EE122 enrollment suggests boom is back!

    ~80 in 2010 to ~200 in 2011 to ~340 in 2012


5 minute break

5 Minute Break

Questions Before We Proceed?


Internet design goals

Internet Design Goals


Internet design goals clark 88

Internet Design Goals (Clark ‘88)

  • Connect existing networks

  • Robust in face of failures

  • Support multiple types of delivery services

  • Accommodate a variety of networks

  • Allow distributed management

  • Easy host attachment

  • Cost effective

  • Allow resource accountability


Connect existing networks

Connect Existing Networks

  • Internet (e.g., IP) should be designed such that all current networks could support IP.

  • This is where the need for best effort arose….


Robust

Robust

  • As long as network is not partitioned, two hosts should be able to communicate (eventually)

  • Failures (excepting network partition) should not interfere with endpoint semantics

  • Very successful, not clear how relevant now

    • Availability more important than recovering from disaster

  • Second notion of robustness is underappreciated

    • Key to modularity of Internet


Types of delivery services

Types of Delivery Services

  • Use of the term “communication services” already implied an application-neutral network

  • Built lowest common denominator service

    • Allow end-based protocols to provide better service

    • For instance, turn unreliable service into reliable service

  • Example: recognition that TCP wasn’t needed (or wanted) by some applications

    • Separated TCP from IP, and introduced UDP


Variety of networks

Variety of Networks

  • Incredibly successful!

    • Minimal requirements on networks

    • No need for reliability, in-order, fixed size packets, etc.

    • A result of aiming for lowest common denominator

  • IP over everything

    • Then: ARPANET, X.25, DARPA satellite network..

    • Now: ATM, SONET, WDM…


Decentralized management

Decentralized Management

  • Both a curse and a blessing

    • Important for easy deployment

    • Makes management hard today


Host attachment

Host Attachment

  • Clark observes that cost of host attachment may be higher because hosts have to be smart

  • But the administrative cost of adding hosts is very low, which is probably more important

    • Plug-and-play kind of behavior….


Cost effective

Cost Effective

  • Cheaper than telephone network

  • But much more expensive than circuit switching

  • Perhaps it is cheap where it counts (low-end) and more expensive for those who can pay….

    • i.e., high-speed circuit switching cheaper, but that’s ok


Resource accountability

Resource Accountability

  • Failure!


Internet motto

Internet Motto

We reject kings, presidents, and voting. We believe in rough consensus and running code.”

David Clark


Real goals

Real Goals

  • Build something that works!

  • Connect existing networks

  • Robust in face of failures

  • Support multiple types of delivery services

  • Accommodate a variety of networks

  • Allow distributed management

  • Easy host attachment

  • Cost effective

  • Allow resource accountability


Questions to think about

Questions to think about….

  • What priorities would a commercial design have?

  • What would the resulting design look like?

  • What goals are missing from this list?


Protocols

Protocols


What is a protocol

What Is A Protocol?

  • Protocol: an agreement on how to communicate

    • To exchange data

    • To coordinate sharing of resources

  • Protocols specifies syntaxand semantics

  • Syntax: how protocol is structured

    • Format, order messages are sent and received

  • Semantics: what these bits mean

    • How to respond to various messages, events, etc.


Examples of protocols in life

Examples of Protocols in Life

  • Asking a question in class

  • Turn-taking in conversations

    • Pause is a signal for the next person’s response

    • When do these rules break?

  • Boarding and exiting an airplane

    • Not all countries have the same protocol!

  • Answering the phone

    • Starting with hello as signal for other party to talk

    • Other party identifies themselves, then conversation

  • Teenagers (an example of unreliable transport!)

    • Information and money only flow in one direction


Example hypertext transfer protocol

Example: HyperText Transfer Protocol

GET /courses/archive/spring06/cos461/ HTTP/1.1

Host: www.cs.princeton.edu

User-Agent: Mozilla/4.03

CRLF

Request

HTTP/1.1 200 OK

Date: Mon, 6 Feb 2006 13:09:03 GMT

Server: Netscape-Enterprise/3.5.1

Last-Modified: Mon, 6 Feb 2006 11:12:23 GMT

Content-Length: 21

CRLF

Site under construction

Response


Example ip packet

Example: IP Packet

4-bit

Header

Length

8-bit Type of

Service (TOS)

4-bit

Version

16-bit Total Length (Bytes)

3-bit

Flags

16-bit Identification

13-bit Fragment Offset

20-byte

header

8-bit Time to

Live (TTL)

8-bit Protocol

16-bit Header Checksum

32-bit Source IP Address

32-bit Destination IP Address

Options (if any)

Payload


Example transmission control protocol

Example: Transmission Control Protocol

  • Communication service

    • Ordered, reliable byte stream

  • Both data transfer and resource sharing

    • Packet exchanges to make sure data arrives

    • Congestion control to share bandwidth fairly with others


Protocol standardization

Protocol Standardization

  • All hosts must follow same protocol

    • Very small modifications can make a big difference

    • Or prevent it from working altogether

    • Cisco bug compatible!

  • This is why we have standards

    • Can have multiple implementations of protocol

  • Internet Engineering Task Force

    • Based on working groups that focus on specific issues

    • Produces “Request For Comments” (RFCs)

    • IETF Web site is http://www.ietf.org

    • RFCs archived at http://www.rfc-editor.org


Alternative to standardization

Alternative to Standardization?

  • Have one implementation used by everyone

  • Open-source projects

    • Which has had more impact, Linux or POSIX?

  • Or just sole-sourced implementation

    • Skype, many P2P implementations, etc.


Clients and servers

Clients and Servers


Many different hosts on internet

Many Different Hosts on Internet

Internet

Also known as a “host”…


Clients and servers1

Client program

Running on end host

Requests service

E.g., Web browser

Clients and Servers

GET /index.html


Clients and servers2

Client program

Running on end host

Requests service

E.g., Web browser

Server program

Running on end host

Provides service

E.g., Web server

Clients and Servers

GET /index.html

“Site under construction”


Client server communication

Client “sometimes on”

Initiates a request to the server when interested

E.g., Web browser on your laptop or cell phone

Doesn’t communicate directly with other clients

Needs to know the server’s address

Server is “always on”

Services requests from many client hosts

E.g., Web server for the www.cnn.com Web site

Doesn’t initiate contact with the clients

Needs a fixed, well-known address

Client-Server Communication


Peer to peer designs

Peer-to-Peer Designs

  • No always-on server at the center of it all

    • Hosts can come and go, and change addresses

    • Hosts may have a different address each time

  • Example: peer-to-peer file sharing

    • All hosts are both servers and clients!

    • Scalability by harnessing millions of peers

    • “self-scaling”

  • Not just for file sharing!

    • This is how many datacenter applications are built

    • Better reliability, scalability, less management…

      • Sound familiar?


  • Login