MIT OpenCourseWare http://ocw.mit.edu 6.033 Computer System Engineering Spring 2009 For information about citing these materials or our Terms of Use, visit: http://ocw.mit.edu/terms.6.033 Lecture 9: Networking Introduction ideas for more content load-shedding / feedback options (pricing &c)why did the internet approach win?what was the other plan?voice / video on internet actually works despite best effort non-guarantee why? video is elastic. voice actually a lot harder despite low bitrate why QoS isn't needed (elastic adaptive applications?) burstyness and flat-rate fixed-rate pipes make pricing complexmy dsl company sells one way, buys in bulk anotherthey take on a big risk -- what if i start downloading 24 hours per day? old internet mapshttp://www.nthelp.com/maps.htmMCIWorldcom 2000 most hair-raising First of 5 lectures on data networks. Overview today: identify the problems and design spaceDig into details over next four lectures.* network are a useful systems building block* internal workings are a good case study of system design. Internet in particular an example of a very successful system. complex enough to be a subject of science, like the weather What is the goal of data networking?Allow us to build systems out of multiple computers.Your problem may be too big for one computer.You may want multiple computers for structural reasons: client/server.more fundamental reason: A key use of computers is for communication between people, orgs. People are geographically distributed, along with their computers. So we're forced to deal with inter-computer comms. System picture:Hosts. Maybe millions of them. All over the world.[No cloud yet, but leave room. circular hosts.] What are the key design problems to be solved?I'll classify into three types:O: Organizational, to help human designers cope.E: Economic, to save operators money.P: Physics. E: universality.Want one net, many uses Rather than lots of small incompatible/disconnected network worlds. e.g. Fedex builds its own data net for its customers to track packagesprivate nets sometimes good for reliability, predictable service,securityThe more people that use a network, the more useful it is for everybody.Value to me is proportional to N people using the same net.Value to society is proportional to N^2.What technical tools help us achieve universality?Standard protocols make it easy to build systems.But don't want to prevent evolution by freezing design w/ standards.Hard: standardize just what's required to make net generally useful,but not the things that might need to be changed later. One universal net means it's *not* part of each system design. It's a black box; simplifies design of systems that use it. Symbolically, a cloud that hides internal workings. [draw network cloud] E: topology.[three new pictures; circular hosts, square switches]Look inside the cloud. Wire between every pair?pro: network (wires) is transparent, passes analog signals. It's never busy. Never any question of how to reach someone. con: host electronics. laying wires expensive. Star network. "switch". Federal Express in Memphis. pro: less wire cost. easy to find a path. con: load and cost and unreliability of hub. Mesh topology. Routers and links. pro: low wire cost. limited router fan-out. some path redundancy. con: shared links, higher load. complex routing. O: routing.Find paths given dst "address".Harder in mesh than in star or hierarchy.[diagram: two available paths] change far away may require re-routing -> has a global element, thus scaling problems many goals: Efficiency: low delay, fast links Spread load Adapt to failures Minimize payments Cope w/ huge scale Routing is a key problem. O: addressing.Hosts need to be able to specify destination to network.specifically, the address you give to the routing system18.7.22.69, not web.mit.eduideal: every host has a unique ID, perhaps 128 bits assigned at randomrouting system can find address, wherever it isso i can connect to my PDA, whether i left it at home or in the officeno-one knows how to build a routing system for large #s of flat addresses!maybe can layer on top of something else, but not directlyIn practice, encode location hints in addresses. hierarcical addresses, e.g. 18.7.whatever [diagram: 18 area, 18.7 area, ...] rest of inet knows only 18, not every host in 18 Trouble if hosts move or topology changes. hard to exploit non-hierarchical links (rest of Inet can't use MIT- Harvard)routing and addressing often very intertwinedE: sharing.Must multiplex many conversations on each physical wire.1. how to multiplex?A. isochronous. [input links, router1, router2, link, repeating cycle]reserved b/w, predictable delay, originally designed for voicecalled TDM B. asynchronous data traffic tends to be bursty - not evenly spaced you think, then click on a link that loads lots of big imageswasteful to reserve b/w for a conversationso send and forward whenever data is ready[diagram: input links, router1, link, router2, output links]divide data into packets, each with header w/ info abt dst2. how to keep track of conversations?A. connections like phone systemyou tell network who you want to talk tofigures out path in advance, then you talkreqired for isochronous trafficcan allow control of load balance for async trafficmaybe allow smaller packet headers (just small connection ID)connection setup complex, forwarding simplerB. connectionless / datagramsmany apps don't match net-level connections, e.g. DNS lookupseach packet self-contained, treated separatelypacket contains full src and dst addresseseach may take a different route through network!shifts burden from network to end hosts (connection abstraction) E: Overload more demand than capacityconsequence of sharing and growth and bursty sourceshow does it appear?isochronous net: new calls blocked, existing calls undisturbedmakes sense if apps have constant unchangeable b/w requirementsasync net:[diagram: router with many inputs]overload is inside the net, not apparent to sending hosts.net must do something with excess trafficdepends on time scale of demand > capacityvery long: buy faster linksshort: tell senders to slow down feedback elastic applications (file xfer, video with parameterized compression)can always add more users, just gets slower for everyoneoften better than blocking callsvery short: don't drop -- buffer packets -- "queuing"demand fluctuates over time [graph: varying demand, line for fixed link capacity]buffers allow you to delay
View Full Document
Unlocking...