Part 1 Packets. Baochun Li Department of Electrical and Computer Engineering University of Toronto

Transcription

1 Part 1 Packets Baochun Li Department of Electrical and Computer Engineering University of Toronto

2 Episode 3. Principles in Network Design Part 1 Baochun Li Department of Electrical and Computer Engineering University of Toronto

3 Designing the network as a system Every complex computer system involves one or more communication links, usually organized to form a network The basic abstractions across the board send(message) and receive(message) 3

4 Part 1 of this episode: an outline Identify and investigate interesting (challenging) properties of a network A fresh look on a system design using the layering principle Throughout the episode: a focus on design principles 4

5 Reading: Salzer 7.1, 7.2, Keshav Chapter 5.1, 5.2, 5.3

6 Interesting properties of networks The design of communication networks is dominated by three intertwined considerations: A trio of fundamental physical properties The mechanics of sharing A remarkably wide range of parameter values 6

7 A trio of fundamental physical properties The speed of light is finite. It take 20 milliseconds to transmit a signal across 2600 miles from Boston to Los Angeles Going to and from a geostationary satellite perched 22,400 miles above the equator: 244 milliseconds large enough for a human to notice! 7

8 Propagation delay There is no way to avoid it without moving the two cities closer together! But how about two computers in the same room? 10 nanoseconds 8

9 Network systems need to accommodate delays that span a few orders of magnitude.

10 A trio of fundamental physical properties Communication environments are hostile. Radio signals, wires, and glass fibers must traverse far more hostile environments under the floor, deep in the ocean Unlike computers, which are usually using reliable components, and operated in benign environments Much easier to break: wiping out individual bits, severing cables 10

11 A trio of fundamental physical properties Communication media have limited bandwidth Every transmission medium has a maximum rate at which one can transmit distinct signals This maximum rate is determined by its physical properties, such as the distance between transmitter and receiver and the attenuation characteristics of the medium Signals can be multilevel, not just binary, so the data rate can be greater than the signaling rate However, noise limits the ability of a receiver to distinguish one signal level from another The combination of limited signaling rate, finite signal power, and the existence of noise limits the rate at which data can be sent over a communication link 11

12 Fundamental physical properties: a summary A network design must deal with: Propagation delay: range over a few orders of magnitude Bandwidth: also range over a few orders of magnitude Lack of reliability: errors may occur 12

13 Communication links are always shared Sharing arises for two distinct reasons Any-to-any connection: when you wish to communicate between any pair of computers, dedicated links connecting all pairs are no longer feasible The number of computers a network should connect also spans a wide range of a few orders of magnitude Sharing of communication costs: Some parts of a communication system follow Moore s law as they are silicon Other parts, such as building cables deep in the ocean or launching a satellite, are not getting cheaper 13

14 Wide range of parameter values Propagation delays, data rates, the number of communicating computers: all spanning a range of several orders of magnitude Another wide-ranging parameter Load: a single computer may at different times present a network with widely differing loads, ranging from transmitting a file at 30 megabytes per second to interactive typing at a rate of one byte per second! 14

15 Three dominating considerations: summary Designing a network as a system is hard due to these considerations: unyielding physical limits sharing of facilities existence of four different parameters that can each range over seven or more orders of magnitude These considerations intrude on every level of network design we need to use a number of principles in our design 15

16 The significant consequences of sharing Consider a multiplexed communication link in a telephone network between Boston and Los Angeles If there is an earthquake in Los Angeles and a flash crowd of incoming phone calls from Boston The multiplexed link has a limited capacity At some point the next caller will get a network is busy signal B1 multiplexed link L1 B2 Boston Switch Los Angeles Switch L2 B3 shared switches L4 L3 16

17 Telephone: isochronous multiplexing Assume each call is 64 kilobits/sec, and the multiplexed link runs at 45 megabits/sec A call runs at 8000 frames/sec, each frame is a 8-bit block In between each pair of frames belonging to the call there is room for 702 other frames, carrying bits belonging to other phone calls The entire link can carry up to 703 simultaneous calls The 704th person will receive the network busy signal Hard-edged: no resistance to the first 703 calls, but absolutely refuses the 704th call! 5,624 bit times Time 8-bit frame 8-bit frame 8-bit frame FIGURE

18 Time-division multiplexing Time-division multiplexing (TDM), used in telephony, is very suitable for voice calls Provides a constant rate of data flow, and the delay from one end to the other is the same for every frame But there is one prerequisite there must be some prior arrangement between the sending switch and the receiving switch A connection requires some previous communication between the two switches to set it up storage for remembered state at both ends of the link some method to discard (tear down) that remembered state at the end 18

19 Why do data networks use a different strategy? Data is being sent in bursts on an irregular basis we can call these bursts messages as compared with the continuous stream of bits that flows out of a simple digital telephone Bursty traffic: ill-suited to fixed size and spacing of isochronous frames A system designer will be happy to give up the guarantee of uniform data rate and uniform latency if in return an entire message can get through more quickly This trade-off is achieved using asynchronous multiplexing 19

20 Asynchronous multiplexing D Personal Computer service A data crosses this link in bursts and can tolerate variable delay B C D multiplexed link frame Time B Guidance 4000 bits 750 bits information 20

21 A Packet The receiver is no longer able to figure out where the message in the frame is destined by simply counting bits Each frame must include a few extra bits that provide guidance about where to deliver it A variable-length frame together with its guidance information is called a packet Guidance information can include the destination address of the message Also need some way of figuring out where each frame starts and ends, a process known as framing in isochronous multiplexing, we just watch the clock 21

22 Connectionless transmission Asynchronous communication offers the possibility of connectionless transmission No state need to be maintained on the switches about particular end-user communications (packets are usually called datagrams ) An additional (but minor) complication: most links place a limit on the maximum size of a frame When a message is larger than this maximum size, it is necessary for the sender to break it up into segments Each of which the network carries in a separate packet Include enough information with each segment to allow the original message to be reassembled at the other end 22

23 Packet Forwarding A Workstation at network attachment point A Packet Switch Packet Switch packet B Packet Switch Packet Switch Service at network attachment point B B A packet going from A to B may follow several different paths, or routes Choosing a particular path for a packet: routing Choosing an outgoing link on a packet switch: forwarding (using table lookup) 23

24 Four contributors to transit times Propagation delay The time required for the signal to travel across a link is determined by the speed of light in the transmission medium connecting the packet switches, and the physical distance the signals travel 24

25 Four contributors to transit times Transmission delay Since the frame that carries the packet may be long or short, the time required to send the frame at one switch and receive it at the next switch depends on the data rate of the link and the length of the frame 25

26 Four contributors to transit times Processing delay Time for a switch to decide which outgoing link to forward a packet to, and to place the packet in the outgoing link s buffer 26

27 Four contributors to transit times But most importantly Queuing delay When the packet from A to B arrives at the upper right packet switch, link #3 may already be transmitting another packet, perhaps one that arrived from link #2, and there may also be other packets queued up waiting to use link #3 If so, the packet switch will hold the arriving packet in a queue in memory until it has finished transmitting the earlier packets The duration of this delay depends on the amount of other traffic passing through that packet switch, so it can be quite variable A Workstation at network attachment point A Packet Switch Packet Switch packet B Packet Switch Packet Switch Service at network attachment point B B 27

28 Queuing delay as a function of utilization Asynchronous systems introduced a fundamental trade-off: if we limit the average queuing delay, it will be necessary to leave unused, on average, some of the capacity of each link! if we allow the utilization to approach 100%, delays will grow without bound The asynchronous design have replaced the abrupt appearance of the busy signal of the isochronous network with a gradual trade-off: as the system becomes busier, the delays increase average queuing delay ρ ---- ρ ying g rmax ρ, thres 0 Utilization, r 100% maximum tolerable delay 28

29 Maximum queuing delays The figure is just about average queueing delays under ideal conditions If we are serious about keeping the maximum delay almost always below a given value, we must prepare for occasional worse peaks by holding utilization well below the level of ρ max suggested by the previous figure Queueing theory is not useful in predicting the behaviour of a network In practice, network systems put a bound on link queuing delays by limiting the size of queues and by exerting control on arrivals Effectively shifting delays to other places in the network! 29

30 Designing the buffer size: strategies Three strategies to design the buffer size: Plan for the worst case: Examine the network traffic carefully, figure out what the worst-case traffic situation will be, and allocate enough buffers to handle it Plan for the usual case and fight back: Based on a similar calculation, choose a buffer size that will work most of the time, and if the buffers fill up send messages back through the network asking someone to stop sending Plan for the usual case and discard overflow: Choose a buffer size that will work most of the time, and ruthlessly discard packets when the buffers are full Which one do you prefer? 30

31 Planning for the worst case Buffer memory is usually inexpensive, so planning for the worst case seems like an attractive idea? But it is actually much harder than it sounds! Impossible to figure out what the worse case is in a large network Packets will queue up for too long in the large buffer: the sender may abort Go for the average (usual) case, then? What do we do when traffic will exceed the average for long enough to run out of buffer space a congestion? 31

32 First idea: fight back If buffer space begins to run low, send a message back along an incoming link saying please don t send any more until you hear from me Such a quench request may go to the upstream packet switch, or all the way back to the original source Harder than it sounds, too If a packet switch is experiencing congestion, there is a good chance that the adjacent switch is also congested if it is not already congested, it soon will be if it is told to stop sending data over the link to this switch sending an extra message is adding to the congestion Worse, a set of packet switches configured in a cycle can easily end up in a form of deadlock: all buffers filled and waiting for the OK signal 32

33 Pushing back all the way to the source? Problematic, too It may not be clear to which source to send the quench Such a request may not have any effect because the source you choose to quench is no longer sending anyway, by the time the quench request reaches there Assuming that the quench message is itself forwarded back through the packet-switched network, it may run into congestion and be subject to queuing delays The busier the network, the longer it will take to exert control! Even if all the data is coming from one source, by the time the quench gets back and the source acts on it, the packets already in the pipeline may exceed the buffer capacity 33

34 So what should we do, then?

35 The only solution left: discarding packets When the buffers fill up, the switches start throwing packets away Sounds like an awful choice! eventually each discarded packet will have to be sent again so the effort to send the packet this far will have been wasted But unfortunately, this is the only choice left It leads to a remarkable consequence Automatic rate adaptation: the sender of a packet can interpret the lack of its acknowledgment as a sign that the network is congested, and can in turn reduce the rate at which it sends new packets into the network 35

36 Two kinds of packet forwarding networks The possibility that a network may actually discard packets to cope with congestion leads to a useful distinction between two kinds of forwarding networks Best-effort network: If a network switch cannot dispatch a packet soon after receipt, it may discard it (therefore providing a best-effort contract to its users) Usually in a lower network layer Guaranteed-delivery network: It takes heroic measures to avoid ever discarding payload data Usually in a higher network layer Well-known examples The Internet: best-effort network The Internet delivery system: Guaranteed-delivery network 36

37 Lost Packet Recovery send request, set timer A request 1 B time receive response, reset timer X response 1 send request, set timer timer expires, resend request, set new timer request 2 request 2 X overloaded forwarder discards request packet. receive response, reset timer X response 2 37

38 Problem 1: Duplicate Requests send request, set timer A request 3 B timer expires, resend request, set new timer receive response, reset timer X request 3 X response 3 overloaded forwarder discards response 3 duplicate arrives at B B sends response 3 38

39 Problem 2: Duplicate Responses A B send request, set timer request 4 timer expires, resend receive response, reset timer receive duplicate response X response 4 request 4 response 4 packet containing response gets delayed duplicate arrives at B B sends response 4 39

40 Duplicate Suppression The general procedure to suppress duplicates has two components Nonces each request includes a nonce, which is a unique identifier that will never be reused by A when sending requests to B Example in previous figures: use monotonically increasing serial numbers as nonces Receiver must keep a list of nonces If a duplicate is received, do not take action, but resend the previous response 40

41 Damaged packets, broken links, and reordering Damaged packets: detected by error detection algorithms (such as using a checksum) Once detected, simply discarded by intermediate packet switches Broken links: needs more flexibility in routing Reordered delivery: may be caused by following different paths needs additional information to reconstruct packet order at the receiver It is not wise for the network system to maintain order 41

42 Isochronous vs. asynchronous multiplexing Application characteristics Continuous stream (e.g., interactive voice) Bursts of data (most computer-tocomputer data) Response to load variations isochronous (e.g., telephone network) good match wastes capacity (hard-edged) either accepts or blocks call Network Type asynchronous (e.g., Internet) variable latency upsets application good match (gradual) 1 variable delay 2 discards data 3 rate adaptation 42

43 What we discussed so far were just examples of system design

44 But what are the principles we should follow?

45 Adopt Sweeping Simplifications Fundamental design principle: Adopt sweeping simplifications so you can see what you are doing. All networks use the divide-andconquer technique known as layering of protocols. 45

46 The Protocol Layering Principle (Keshav Ch )

47 Analogy: post office Consider a customer who walks into a post office to send a letter to a friend Postal delivery involves an exchange of a message between two sets of parties called peer entities The customers, who view the postal network as a black box that accepts letters at one end and delivers them to another The postal workers, who handle the letters on behalf of their customers 47

48 A three-layer reference model Module A may call any of the modules J, K, or L, but A doesn t even know of the existence of X, Y, and Z The figure here shows A using module K. Module K, in turn, may call any of X, Y, or Z Layer One A B C D Layer Two J K L Layer Three X Y Z 48

49 Advantages of Protocol Layering The set of rules that peer entities need to follow when they communicate with each other is called a protocol Three advantages of protocol layering It allows a complex problem to be broken into smaller, more manageable pieces The implementation detail can be hidden (abstracted) from other layers we can change it without disturbing the rest of the protocol stack Many upper layer protocols can share the services provided by the same lower layer protocol 49

50 Problems of Protocol Layering Should we design upper layer protocols with the knowledge of implementation detail of a lower layer protocol? Of course not, it violates the layering principle and defeats information hiding But sometimes information hiding leads to poor performance An upper layer protocol can throttle the source sending rate when detecting a packet loss, with the knowledge that a lower layer protocol will drop packets when congestion occurs 50

51 The art is to leak enough information between layers to allow efficient performance, but not so much that it is hard to change the implementation of a layer!

52 How many layers do we need? At the minimum, three The link layer: moving data directly from one point to another The network layer: forwarding data through intermediate points to move it to the place it is wanted The end-to-end layer: everything else required to provide a comfortable application interface Perhaps we can also divide the link layer into the physical layer and the data link layer Or divide the end-to-end layer into the transport layer and the application layer It will then become a total of 5 layers 52

53 The ISO/OSI Reference Model The ISO/OSI Reference Model adds two more layers with weak justifications Session layer and presentation layer The perils of designing protocols by a committee By the time it was standardized, the Internet has already matured It then becomes a historical note you find in textbooks 53

54 One end-to-end layer or four layers? Different applications have radically different requirements for transport, session, and presentation services! Even to the extent that the order in which they should be applied may be different This situation makes it difficult to propose any single layering, since a layering implies an ordering Any implementation decisions that a lower layer makes may be counterproductive for at least some applications! Instead, it is likely to be more effective to provide a library of service modules that can be selected and organized by the developer of a specific application 54

55 Sending and receiving data using layers An application starts by asking the end-to-end layer to transmit a message or a stream of data to a correspondent The end-to-end layer: splits long messages and streams into segments copes with lost or duplicated segments places arriving segments in proper order enforces specific communication semantics performs presentation transformations Finally, calls on the network layer to transmit each segment 55

56 Typical services in the end-to-end layer Presentation services: Translating data formats and emulating the semantics of a procedure call e.g., Remote Procedure Call (RPC) Transport services: Dividing streams and messages into segments and dealing with lost, duplicated, and out-oforder segments e.g., using serial numbers of the segments Session services: Negotiating a search, handshake, and binding sequence to locate and prepare to use a service that knows how to perform the requested procedure e.g., Session Initiation Protocol (SIP) 56

57 Sending and receiving data using layers The network layer: accepts segments from the end-to-end layer constructs packets, and transmits those packets across the network choosing which links to follow to move a given packet from its origin to its destination The link layer: accepts packets from the network layer constructs and transmits frames across a single link between two forwarders or between a forwarder and a customer of the network 57

58 Relation between the network and link layers DATA NETWORK_SEND ( segment, IP, nap_1197) Network Layer network protocol Network Layer NT DATA NH LINK_SEND ( packet, link5) link_send ( packet, link2) NETWORK_HANDLE Link Layer LT link 2 NT DATA link protocol NH LH Link Layer Link Layer link5 58

59 The end-to-end layer FIRE (7, Lucifer, evade) DATA FIRE (7, Lucifer, evade) End-to-End Layer (RPC) end-to-end protocol End-to-End Layer (RPC) ET DATA EH Network Layer Network Layer Network Layer NT ET DATA EH NH Link Layer Link Layer Link Layer Link Layer LT NT ET DATA EH NH LH 59

60 The end-to-end argument The argument against additional layers constitutes part of a design principle Fundamental design principle: The end-to-end argument The application knows best. 60

61 The end-to-end argument The basic idea of the end-to-end argument is that the application knows best what its real communication requirements are, and for a lower network layer to try to implement any feature other than transporting the data risks implementing something that is not quite what the application needed. Moreover, if it is not exactly what is needed, the application will probably have to re-implement that function on its own. Don t bury it in a lower layer, let the end points deal with it because they know best what they need! 61

62 A simple example: careful file transfer To transfer a file carefully, the appropriate method is to calculate a checksum from the contents of the file as it is stored in the file system of the originating site After the file has been transferred and written to the new file system, the receiving site should read the file back out of its file system, recalculate the checksum anew, and compare it with the original checksum If the two checksums are the same, the file is correctly transferred An end-to-end approach of checking the accuracy of the file transfer Is there any value in having the link layer add a frame checksum? 62

63 The problem with link checksums Despite this protection, the data may still be damaged! while it is being passed through the network layer while it is buffered by the receiving part of the file transfer application while it is being written to the disk Therefore, the careful file transfer application cannot avoid calculating its end-to-end checksum, despite the protection provided by the link layer checksum! Is the link layer checksum worthless? With a checksum, the link layer will discover data transmission errors at a time when they can be easily corrected by resending just one frame Rather than redoing the entire file transfer 63

64 Conclusion on the end-to-end argument There may be a significant performance gain in having a feature in the lower-level layer This implies that a lower-layer checksum does not eliminate the need for the application layer to implement the function It is thus not required for application correctness It is just a performance enhancement! 64

65 Reading: Salzer 7.1, 7.2, Keshav Chapter 5.1, 5.2, 5.3