Internet Design History and Goals
description
Transcript of Internet Design History and Goals
![Page 1: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/1.jpg)
1
Internet Design Historyand GoalsEE122 Fall 2012
Scott Shenkerhttp://inst.eecs.berkeley.edu/~ee122/
Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley
![Page 2: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/2.jpg)
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
2
![Page 3: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/3.jpg)
Outline for Today• Finishing up queueing• Statistical Multiplexing• Why did we choose packet-switching?• Internet history• Internet design goals• Protocols, Clients and Servers,….
3
![Page 4: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/4.jpg)
Finishing Up Queueing Delays
![Page 5: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/5.jpg)
Queueing Delay 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….
5
![Page 6: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/6.jpg)
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?
6
![Page 7: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/7.jpg)
Packet Losses• Packets can be “dropped” or lost
• How?
7
![Page 8: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/8.jpg)
Packet Losses: Buffers Full
8
![Page 9: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/9.jpg)
Packet Losses: Corruption
9
![Page 10: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/10.jpg)
Packet Losses• Where should packet corruption be detected?
– In network?– At host?
• Other ways packets can be lost?– TTL!
10
![Page 11: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/11.jpg)
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 quantities11
![Page 12: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/12.jpg)
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
12
![Page 13: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/13.jpg)
Statistical Multiplexing
![Page 14: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/14.jpg)
Se-ries1
Se-ries1
Se-ries1
Data Rate 1
Data Rate 2
Data Rate 3
Three Flows with Bursty Arrivals
Time
Time
TimeCapacity
![Page 15: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/15.jpg)
Se-ries1
Se-ries1
Se-ries1
Data Rate 1
Data Rate 2
Data Rate 3
When Each Flow Gets 1/3rd of Capacity
Time
Time
Time
Frequent Overloading
![Page 16: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/16.jpg)
When Flows Share Total Capacity
Se-ries1
Se-ries1 Time
Time
TimeSe-ries1
No Overloading
Statistical multiplexing relies on the assumption that not all flows burst at the same time.
Very similar to insurance, and has same failure case
![Page 17: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/17.jpg)
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?17
![Page 18: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/18.jpg)
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. 18
![Page 19: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/19.jpg)
Improved Delays: M/M/1 Queue
19
• 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/(m - nl)
• Case 2: Flows each have 1/nth share of bandwidth– No sharing– Delay = n/(m - nl) Not sharing increases delay by n
![Page 20: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/20.jpg)
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”
20
![Page 21: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/21.jpg)
Recurrent theme in computer science• Greater efficiency through “sharing”
– Statistical multiplexing
• Phone network rather than dedicated lines– Ancient history
• Packet switching rather than circuits– Last lecture
• Cloud computing– Shared datacenters, rather than single PCs 21
![Page 22: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/22.jpg)
Choosing a Network Design
![Page 23: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/23.jpg)
If you were building a network….• Which would you choose?
– Circuit switched?– Packet-switched (Datagram)?
• Let’s review the strengths and weaknesses
23
![Page 24: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/24.jpg)
24
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
![Page 25: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/25.jpg)
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!
25
![Page 26: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/26.jpg)
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
26
![Page 27: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/27.jpg)
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.
27
![Page 28: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/28.jpg)
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
28
![Page 29: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/29.jpg)
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?
29
![Page 30: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/30.jpg)
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)• …..
30
![Page 31: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/31.jpg)
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)• …..
31
![Page 32: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/32.jpg)
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?
32
![Page 33: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/33.jpg)
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 33
![Page 34: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/34.jpg)
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
34
![Page 35: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/35.jpg)
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
35
![Page 36: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/36.jpg)
Internet History
![Page 37: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/37.jpg)
Timeline1961 Baran and Kleinrock advocate packet switching
1962 Licklider’s vision of Galactic Network
1965 Roberts connects two computers via phone
1967 Roberts publishes vision of ARPANET
1969 BBN installs first IMP at UCLAIMP: Interface Message Processor
1971 Network Control Program (protocol)
1972 Public demonstration of ARPANET37
![Page 38: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/38.jpg)
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!
38
![Page 39: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/39.jpg)
Timeline continued…1972 Email invented
1972 Telnet introduced
1972 Kahn advocates Open Architecture networking
39
![Page 40: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/40.jpg)
40
The Problem• Many different packet-switching networks • Only nodes on the same network could
communicate
![Page 41: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/41.jpg)
41
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?)
![Page 42: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/42.jpg)
42
Solution
Gateways
![Page 43: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/43.jpg)
43
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
![Page 44: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/44.jpg)
Timeline continued….1973 FTP introduced
1974 Cerf and Kahn paper on TCP/IP
1980 TCP/IP adopted as defense standard
1983 Global NCP to TCP/IP flag day
198x XNS, DECbit, and other protocols
1984 Janet (British research network)
1985 NSFnet (picks TCP/IP)
198x Internet meltdowns due to congestion
1986 Van Jacobson saves the Internet (BSD TCP) 44
![Page 45: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/45.jpg)
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
45
![Page 46: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/46.jpg)
Timeline continued…1988 Deering and Cheriton propose multicast
1989 Birth of the web….Tim Berners-Lee
46
![Page 47: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/47.jpg)
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 47
![Page 48: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/48.jpg)
Timeline continued…..1993 Search engines invented (Excite)
199x ATM rises and falls (as internetworking layer)
199x QoS rises and falls
1994 Internet goes commercial
1998 IPv6 specification
1998 Google reinvents search
200x The Internet boom and bust
2012 EE122 enrollment suggests boom is back!~80 in 2010 to ~200 in 2011 to ~340 in 2012 48
![Page 49: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/49.jpg)
49
5 Minute Break
Questions Before We Proceed?
![Page 50: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/50.jpg)
Internet Design Goals
![Page 51: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/51.jpg)
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
51
![Page 52: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/52.jpg)
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….
52
![Page 53: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/53.jpg)
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
53
![Page 54: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/54.jpg)
54
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
![Page 55: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/55.jpg)
55
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…
![Page 56: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/56.jpg)
Decentralized Management• Both a curse and a blessing
– Important for easy deployment– Makes management hard today
56
![Page 57: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/57.jpg)
57
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….
![Page 58: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/58.jpg)
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
58
![Page 59: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/59.jpg)
Resource Accountability• Failure!
59
![Page 60: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/60.jpg)
60
Internet MottoWe reject kings, presidents, and voting. We believe
in rough consensus and running code.”
David Clark
![Page 61: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/61.jpg)
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 61
![Page 62: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/62.jpg)
62
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?
![Page 63: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/63.jpg)
Protocols
![Page 64: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/64.jpg)
64
What Is A Protocol?• Protocol: an agreement on how to communicate
– To exchange data– To coordinate sharing of resources
• Protocols specifies syntax and 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.
![Page 65: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/65.jpg)
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
65
![Page 66: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/66.jpg)
66
Example: HyperText Transfer Protocol
GET /courses/archive/spring06/cos461/ HTTP/1.1Host: www.cs.princeton.eduUser-Agent: Mozilla/4.03CRLF
HTTP/1.1 200 OKDate: Mon, 6 Feb 2006 13:09:03 GMTServer: Netscape-Enterprise/3.5.1Last-Modified: Mon, 6 Feb 2006 11:12:23 GMTContent-Length: 21CRLFSite under construction
Request
Response
![Page 67: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/67.jpg)
67
Example: IP Packet
4-bitVersion
4-bitHeaderLength
8-bit Type ofService (TOS) 16-bit Total Length (Bytes)
16-bit Identification 3-bitFlags 13-bit Fragment Offset
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
20-byteheader
![Page 68: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/68.jpg)
• 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
68
Example: Transmission Control Protocol
![Page 69: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/69.jpg)
69
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
![Page 70: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/70.jpg)
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.
70
![Page 71: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/71.jpg)
Clients and Servers
![Page 72: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/72.jpg)
72
Many Different Hosts on Internet
Internet
Also known as a “host”…
![Page 73: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/73.jpg)
73
Clients and Servers• Client program
– Running on end host– Requests service– E.g., Web browser
GET /index.html
![Page 74: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/74.jpg)
74
Clients and Servers• Client program
– Running on end host– Requests service– E.g., Web browser
• Server program– Running on end host– Provides service– E.g., Web server
GET /index.html
“Site under construction”
![Page 75: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/75.jpg)
75
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
![Page 76: Internet Design History and Goals](https://reader036.fdocuments.net/reader036/viewer/2022062521/56816950550346895de0f3b2/html5/thumbnails/76.jpg)
76
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?