Internet Design History and Goals

Transcription

1 Internet Design History and Goals EE122 Fall 2012 Scott Shenker Materials with thanks to Jennifer Rexford, Ion Stoica, Vern Paxson and other colleagues at Princeton and UC Berkeley 1

2 Administrivia Keep those questions coming! It will take a while for me to calibrate length of lectures Questions about switching sections? Kay keo@eecs.berkeley.edu, cc me. Check your bspace 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

3 Outline for Today Finishing up queueing Statistical Multiplexing Why did we choose packet-switching? Internet history Internet design goals Protocols, Clients and Servers,. 3

4 Finishing Up Queueing Delays

5 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

6 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

7 Packet Losses Packets can be dropped or lost How? 7

8 Packet Losses: Buffers Full 8

9 Packet Losses: Corruption 9

10 Packet Losses Where should packet corruption be detected? In network? At host? Other ways packets can be lost? TTL! 10

11 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 11

12 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

13 Statistical Multiplexing

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

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

16 When Flows Share Total Capacity Time Time Time 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

17 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

18 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

19 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/(m - nl) Case 2: Flows each have 1/n th share of bandwidth No sharing Delay = n/(m - nl) Not sharing increases delay by n 19

20 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

21 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

22 Choosing a Network Design

23 If you were building a network. Which would you choose? Circuit switched? Packet-switched (Datagram)? Let s review the strengths and weaknesses 23

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 24

25 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

26 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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

35 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

36 Internet History

37 Timeline 1961 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 UCLA IMP: Interface Message Processor 1971 Network Control Program (protocol) 1972 Public demonstration of ARPANET 37

38 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

39 Timeline continued invented 1972 Telnet introduced 1972 Kahn advocates Open Architecture networking 39

40 The Problem Many different packet-switching networks Only nodes on the same network could communicate 40

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?) 41

42 Solution Gateways 42

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 43

44 Timeline continued 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

45 Unsung hero of Internet: David D. Clark Chief Architect 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

46 Timeline continued 1988 Deering and Cheriton propose multicast 1989 Birth of the web.tim Berners-Lee 46

47 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. 47 Don Norman

48 Timeline continued 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

49 5 Minute Break Questions Before We Proceed? 49

50 Internet Design Goals

51 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

52 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

53 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

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 54

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 55

56 Decentralized Management Both a curse and a blessing Important for easy deployment Makes management hard today 56

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

58 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

59 Resource Accountability Failure! 59

60 Internet Motto We reject kings, presidents, and voting. We believe in rough consensus and running code. David Clark 60

61 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

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? 62

63 Protocols

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

65 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

66 Example: HyperText Transfer Protocol GET /courses/archive/spring06/cos461/ HTTP/1.1 Host: User-Agent: Mozilla/4.03 CRLF Request Response HTTP/ OK Date: Mon, 6 Feb :09:03 GMT Server: Netscape-Enterprise/3.5.1 Last-Modified: Mon, 6 Feb :12:23 GMT Content-Length: 21 CRLF Site under construction 66

67 Example: IP Packet 4-bit Version 4-bit Header Length 8-bit Type of Service (TOS) 16-bit Total Length (Bytes) 16-bit Identification 3-bit Flags 13-bit Fragment Offset 8-bit Time to Live (TTL) 8-bit Protocol 16-bit Header Checksum 20-byte header 32-bit Source IP Address 32-bit Destination IP Address Options (if any) Payload 67

68 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 68

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 RFCs archived at 69

70 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

71 Clients and Servers

72 Many Different Hosts on Internet Internet Also known as a host 72

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

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 74

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 Web site Doesn t initiate contact with the clients Needs a fixed, well-known address 75

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? 76