1 / 70

Preliminaries, Protocols, Preview Priorities, and Principles

Preliminaries, Protocols, Preview Priorities, and Principles. EE122 Fall 2011 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. Announcements. TAs gave me brutal feedback

bethan
Download Presentation

Preliminaries, Protocols, Preview Priorities, and Principles

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Preliminaries, Protocols, PreviewPriorities, and Principles EE122 Fall 2011 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

  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…..

  3. 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…..

  4. Preliminaries

  5. 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 Link Node Node

  6. 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 delay x bandwidth bandwidth latency

  7. 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!

  8. Examples of Transmission Times • 1500 byte packet over 14.4k modem: ~1 sec • 1500 byte packet over 10Gbps link: ~10-6sec

  9. 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

  10. Packets • Payload (Body) • Data being transferred • Header • Instructions to the network for how to handle packet • Think of the header as an interface!

  11. The Lifecycle of Packets Packet Currently Being Transmitted Link Packet Buffer Packet Arriving at Switch Packet Being Transmitted Excess Packets Stored in Buffer

  12. The Delays of Their Lives Transmission Delay Queueing Delay Round-Trip Time (RTT) is the time it takes a packet to reach the destination and the response to return to the sender Propagation Delay is how long it takes to reach the next switch after transmission

  13. 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

  14. Trends • Propagation delay? • No change • Transmission delay? • Getting smaller! • Queueingdelay? • 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!

  15. Queueing Delay • Does not happen if packets are evenly spaced • And arrival rate is less than service rate

  16. Smooth Arrivals = No Queueing Delays

  17. 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

  18. Bursty Arrivals = Queueing Delays There is substantial queueing delay even though link is underutilized

  19. 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….

  20. 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?

  21. Packet Losses: Buffers Full

  22. Packet Losses: Corruption

  23. Reviewing Queueing: java applet

  24. 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

  25. 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

  26. Statistical Multiplexing

  27. Three Flows with Bursty Arrivals Data Rate 1 Time Data Rate 2 Capacity Time Data Rate 3 Time

  28. When Each Flow Gets 1/3rd of Capacity Frequent Overloading Data Rate 1 Time Data Rate 2 Time Data Rate 3 Time

  29. 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

  30. Another Take on “Stat Mux” • 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”…. Frame Slots

  31. 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

  32. If you still don’t understand stat mux • Come to office hours and I can try another explanation…

  33. Protocols

  34. 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.

  35. 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

  36. 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

  37. 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

  38. 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

  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 Motto We reject kings, presidents, and voting. We believe in rough consensus and running code.” David Clark

  41. 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.

  42. Clients and Servers

  43. Many Different Hosts on Internet Internet Also known as a “host”…

  44. Client program Running on end host Requests service E.g., Web browser Clients and Servers GET /index.html

  45. 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”

  46. 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

  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… • Sound familiar?

  48. 5 Minute Break Questions Before We Proceed?

  49. Internet Design Goals

  50. 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

More Related