1
Preliminaries, Protocols, PreviewPriorities, and Principles
EE122 Fall 2011
Scott Shenkerhttp://inst.eecs.berkeley.edu/~ee122/
Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxsonand other colleagues at Princeton and UC Berkeley
2
Announcements• TAs gave me brutal feedback
– Need to cover more of the basics– Goal today: fluency in packets, probability, terminology
• Homework #1 Out– This is about learning, not evaluation– But please try to do it on your own first– Will entertain questions in office hours and in class
• Today’s lecture will spill over into next week• There is a special place in hell reserved for the
designer of Powerpoint’s animation package…..
Outline• Preliminaries
– Life of a packet, types of delay, Little’s Law, etc.– Protocols– Client-server architectures
• Preview of homework assignment– Clear up any misunderstanding
• Design priorities (probably today)– Clark’s 1988 paper
• Design Principles (I hope not today)– The good stuff…..
3
Preliminaries
Nodes and Links• Link: transmission technology
– Twisted pair, optical, radio, whatever
• Node: computational devices on end of links– Host: general-purpose computer– Network node: switch or router
5
Node NodeLink
Properties of Links• Latency (delay)
– Propagation time for data sent along the link– Corresponds to the “length” of the link
• Bandwidth (capacity)– Amount of data sent (or received) per unit time– Corresponds to the “width” of the link
• Bandwidth-delay product: (BDP)– Amount of data that can be “in flight” at any time– Propagation delay × bits/time = total bits in link
6
bandwidth
latency
delay x bandwidth
Examples of Bandwidth-Delay• Same city over slow link:
– B~100mbps– L~.1msec– BDP ~ 10000bits ~ 1.25MBytes
• Cross-country over fast link:– B~10Gbps– L~10msec– BDP ~ 108bits ~ 12.5GBytes
• Another example where the Internet has to be prepared for a wide range of conditions! 7
Examples of Transmission Times• 1500 byte packet over 14.4k modem: ~1 sec
• 1500 byte packet over 10Gbps link: ~10-6sec
8
Utilization• Fraction of time link is busy transmitting
– Often denoted by ρ
• Ratio of arrival rate to bandwidth– Arrival: A bits/sec on average– Utilization = A/B
9
Packets• Payload (Body)
– Data being transferred
• Header– Instructions to the network for how to handle packet– Think of the header as an interface!
10
The Lifecycle of Packets
11
Excess Packets Stored in Buffer
Packet Arriving at Switch
PacketBeing
Transmitted
Packet BufferLink
Packet Currently Being Transmitted
The Delays of Their Lives
12
QueueingDelay
Transmission Delay
Propagation Delay is how long it takesto reach the next switch after transmission
Round-Trip Time (RTT) is the time it takesa packet to reach the destination and the response to return to the sender
Review of Networking Delays• Propagation delay: latency
– Time spent in traversing the link– “speed of propagation” delay
• Transmission delay:– Time spent being transmitted– Ratio of packet size to bandwidth
• Queueing delay:– Time spent waiting in queue– Ratio of total packet bits ahead in queue to bandwidth
• Roundtrip delay (RTT)– Total time for a packet to reach destination and a
response to return to the sender 13
Trends• Propagation delay?
– No change
• Transmission delay? – Getting smaller!
• Queueing delay? – Usually smaller
• How does this affect applications?– CDNs work very hard to move data near clients– Reduces backbone bandwidth requirements– But also decreases latency– Google: time is money!
14
Queueing Delay• Does not happen if packets are evenly spaced
– And arrival rate is less than service rate
15
Smooth Arrivals = No Queueing Delays
16
Queueing Delay• 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
17
Bursty Arrivals = Queueing Delays
18
There is substantial queueing delay even though link is underutilized
Queueing Delay• 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….
19
Jitter• Difference between minimum and maximal delay• Latency 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?
20
Packet Losses: Buffers Full
21
Packet Losses: Corruption
22
Reviewing Queueing: java applet
23
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 quantities24
Little’s Law (1961)
L = A x W
• Compute L: count packets in queue every second– How often does a single packet get counted? W times
• Could compute L differently – On average, every packet will be 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
25
Statistical Multiplexing
Se-ries1
Se-ries1
Se-ries1
Data Rate 1
Data Rate 2
Data Rate 3
Three Flows with Bursty Arrivals
Time
Time
TimeCapacity
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
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
• Assume time divided into frames– Frames divided into slots
• Flows generate packets during each frame– Peak number of packets/frame P– Average number of packets/frame A
• Single flow: must allocate P slots to avoid drops– But P might be much bigger than A– Very wasteful!
• Use the “Law of Large Numbers”….
Another Take on “Stat Mux”
30
Frame
Slots
Law of Large Numbers (~1713)• Consider any probability distribution
– Can be highly variable, such as varying from 0 to P
• Take N samples from probability distribution– In this case, one set of packets from each flow
• Thm: the sum of the samples is very close to N×A– And gets percentage-wise closer as N increases
• Sharing between many flows (high aggregation), means that you only need to allocate slightly more than average A slots per frame.– Sharing smooths out variations
31
If you still don’t understand stat mux• Come to office hours and I can try another
explanation…
32
Protocols
34
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.
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
35
36
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
37
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
• 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
38
Example: Transmission Control Protocol
39
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
40
Internet MottoWe reject kings, presidents, and voting. We believe
in rough consensus and running code.”
David Clark
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.
41
Clients and Servers
43
Many Different Hosts on Internet
Internet
Also known as a “host”…
44
Clients and Servers• Client program
– Running on end host– Requests service– E.g., Web browser
GET /index.html
45
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”
46
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
47
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…
o Sound familiar?
48
5 Minute Break
Questions Before We Proceed?
Internet Design Goals
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
50
Connect Existing Networks• Internet (e.g., IP) should be designed such that all
current networks could support IP.
51
Robust• As long as the network is not partitioned, two
endpoints should be able to communicate• Failures (excepting network partition) should not
interfere with endpoint semantics
• Very successful, not clear how relevant now• Second notion of robustness is underappreciated
52
53
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
• Example: recognition that TCP wasn’t needed (or wanted) by some applications– Separated TCP from IP, and introduced UDP
54
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• Both a curse and a blessing
– Important for easy deployment– Makes management hard today
55
56
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
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….
57
Resource Accountability• Failure!
58
59
Internet MottoWe reject kings , presidents, and voting. We believe
in rough consensus and running code.”
David Clark
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 60
61
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?
• Which goals led to the success of the Internet?
Internet Design Principles
The Networking Dilemma• Many different networking technologies
• Many different network applications
• How do you prevent incompatibilities?
63
64
The Problem
• Re-implement every application for every technology?• No! But how does the Internet design avoid this?
Skype SSH NFS
RadioCoaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
65
Solution: Intermediate Layers
• Introduce intermediate layers that provide set of abstractions for various network functionality and technologies– A new app/media implemented only once– Variation on “add another level of indirection”
Skype SSH NFS
Packetradio
Coaxial cable
Fiberoptic
Application
TransmissionMedia
HTTP
Intermediate layers
66
Network Architecture• Architecture is not the implementation itself
• Architecture is how to organize/structure the elements of the system and their implementation
• What interfaces are supported?– Using what sort of abstractions
• Where functionality is implemented?– The modular design of the network
67
Computer System ModularityPartition system into modules & abstractions:• Well-defined interfaces give flexibility
–Hides implementation - can be freely changed– Extend functionality of system by adding new modules
• E.g., libraries encapsulating set of functionality
• E.g., programming language + compiler abstracts away how the particular CPU works …
Computer System Modularity (cnt’d)• Well-defined interfaces hide information
– Isolate assumptions – Present high-level abstractions
• But can impair performance!
• Ease of implementation vs worse performance
68
69
Network System ModularityLike software modularity, but:• Implementation distributed across many machines
(routers and hosts)• Must decide:
– How to break system into moduleso Layering
– Where modules are implementedo End-to-End Principle
– Where state is storedo Fate-sharing
• We will address these choices in turn
Remember that slide!• The relationship between architectural principles
and architectural decisions is crucial to understand
70
