Transport

1. Transport

2. Transport in Context Application Presentation Session Transport Network Data Link Physical

3. Services • Connection Oriented: • Connection Establishment • Data Transfer • Status and Error Reporting • Connection Release • Connectionless: • Data Transfer Text describes the service invocations in both OSI and TCP/IP environments

4. Variations on Transport Service • ISO defines five connection-oriented and one connectionless transport protocol • TP4 is similar to TCP • TP0 - TP3 allow for different levels of underlying network service and reliability • TCP/IP defines one connection-oriented and one connectionless transport protocol. • TCP is connection-oriented • Transmission Control Protocol • UDP is connectionless • User Datagram Protocol

5. Transport Protocol • Protocol defines how the services are provided • Connection establishment • Simple connection request/connection confirm is not satisfactory • Establish the context for further communication • Determine the order of the packets • Recognize if a packet is lost • Recognize if a packet is duplicated • Require an orderly release to prevent data loss

6. Problem of old duplicates Receiver Sender Data Repeat data Data arrives Some time later Another connection and another transfer of data New data Old data received in addition to, or instead of data of the current communication

7. Protocol design and testing • “Just because we’re paranoid doesn’t mean they are not out to get us” • When millions of connections are established everyday, an event with probability 0.0001 is expected to happen daily.

8. Protecting against old duplicates • Each entity generates a number such that it is not possible for that number originating at that host to be bouncing around the Internet • Old duplicates will not be valid • Response to a connection request carries both the number generated by the initiator and a number generated by the responder. Since old duplicates of those numbers cannot exist, bad connections will not happen

9. TP4 TCP SYN seq=X CR(ID) CR(ID) CC(ack ID, DST REF) SYN seq=X SYN seq=Y ack = X+1 SYN seq=Y ack = X+1 CC(ack ID, DST REF) DT(DST REF, data) ACK=Y+1 DT(DST REF, data) ACK=Y+1 Connection establishment

10. Error Detection • Happens at several layers in the network • different concerns • redundancy • Checksum is the process of adding bits to a transmission so that the original transmission modified by the extra bits has some predictable characteristic. The receiver checks for that characteristic and reports an error if it is not found

11. The checksum (UDP and TCP) • Check accuracy of the packet, including header and data • Process: • Prepend a pseudo header containing source and destination IP addresses, destination port number, length • append enough 0s to make the packet length a multiple of 16 bits • Insert 0s in the checksum field for now • Treat the packet as a sequence of 16-bit integers • Add them together using one’s complement arithmetic • Take the one’s complement of the result

12. Error checking • There is a more elaborate error checking routine for the data link layer that will check the data received by the IP layer. • IP does no checking of the data • Checking at the transport layer is really checking for errors in the IP and TCP (or UDP) headers

13. Reminders • One’s complement addition • Add the bits individually • Carry out of the high order side is added to the low order bit position 1010 0011 0001 1101 1000 1101 1001 1010 0011 0000 1011 0111 1 0011 0000 1011 1000

14. Error Correction • Once an error is detected, reliable transport requires that the error be corrected. • Error correction methods can be done with or without retransmission. • Without retransmission involves many more bits added to the transmission than are required for simple error detection. The overhead is too great for most applications • With retransmission minimizes the overhead carried by each packet, but requires that the packet be resent if an error occurs • possibility of another error, of course

15. Error detection and correction costs • The ability to detect an error is based on recognition of bit patterns that cannot legally appear. • Since binary files, such as executable code, compressed or encrypted text, image representations, etc. can contain any combination of bits, something extra must be added. • How many extra bits do we need to add?

16. Hamming distance • How many bit changes are required to convert one correct code to another legal code? • If a single bit change makes a new code that looks ok, it is impossible to detect that an error occurred. • Example: The ASCII code • Every possible bit pattern is meaningful • Thus, no error can be detected

17. Hamming distance • In general, if the Hamming distance of a code is n, the maximum number of bit errors that can be detected is n-1 • Knowing that an error occurred does not necessarily allow a correction. That requires that we know which bits contained the error.

18. Error Correction • The basic idea with error correction is to have a reason to believe that one way of correcting the error is more likely to be correct than any other way of correcting the data. • If there is a lot of distance between valid codewords, transform the erroneous codeword into the closest legal codeword.

19. Parity • Simple parity = a single bit change shows up as an impossible code • Hamming distance is 2 • Example: The original ASCII code • 7 bits of data • 1 bit of parity • Simple parity is adequate to detect an odd number of bit errors. • No error correction in general

20. Error correction • More separation between valid codewords • Basic assumption • if the bit pattern seen is closer to one valid codeword than to another, it is more likely to be a corrupted version of that nearby codeword. • The more separation you have between valid codewords, the more likely you are to match the erroneous bit pattern with the correct original codeword

21. Example • Four bit codes • Two valid codewords • 0000 • 1111 • What is the hamming distance for this code? • How many bit errors can we detect? Correct? • Suppose we see 1110 • We assume it is a corrupted representation of 1111, not 0000 • Suppose we see 1100?

22. More generally, • We need to show that the bit pattern seen is closer to one valid codeword than to any other valid code word. • Ties don’t help • If the distance between valid codewords is m • we can detect m-1 bit errors • we can correct (m-1)/2 (rounded down) bit errors

23. Checking • If the Hamming distance is • 5 • detect up to 4 bit errors • correct up to 2 bit errors • 13 • detect up to 12 bit errors • correct up to 6 bit errors • 9 • detect up to ____ bit errors • correct up to ____ bit errors

24. The Hamming Code • A way of assigning values to the extra bits to make it convenient to detect the correct code • Number bit positions left to right, starting with 1 • All positions that are a power of 2 are check bits • All other positions are “real” data bits

25. Hamming code continued • Each bit position is checked by the check bits reflected in the position number • Bit position 5 • What powers of 2 sum to 5? • 4 + 1 • Bit positions 4, 1 check bit position 5 • Bit position 14 • 14 = 8 + 4 + 2 • Bit positions 8, 4, 2 check bit position 14 • Bit position 11?

26. Hamming code note • Every bit position can be represented as a sum of powers of 2 • so all bit positions are covered by some combination of the check bits • None of the check positions involves any other check bits • each check bit is independent of the other check bits

27. Computing the Hamming check bits • Insert the data, leaving the check bits empty • Fill in check bit 1 • Count the number of 1s in positions 3, 5, 7, 9, 11, 13,… - all the odd number bit positions • Assign the value in position 1 to make the number of 1s even • Fill in check bit 2 • Parity check on positions 3, 6, 7, 10, 11, 14, etc. • Fill in check bit 4 • Parity check on positions 5, 6, 7, 12, 13, 14, etc.

28. Another view 1 = 0001 2 = 0010 3 = 0011 4 = 0100 5 = 0101 6 = 0110 7 = 0111 8 = 1000 9 = 1001 10=1010 11=1011 12=1100 13=1101 All the positions that are powers of 2 are check bits All the other positions are checked by the bits that make up their position number

29. Try it • Transmit the following message using the Hamming code: • 0100 1000 0100 1001 • Insert the extra check bits in the correct places • Show the final encoding organized in four bit blocks for ease in reading. (If the final number of bits is not divisible by 4, do not append any extra bits. Just show a group of fewer than 4 bits.)

30. Hamming Code Error Correction • When a codeword is received, recompute the check bits. • If the check bits matched what arrived, assume the transmission is ok. • If the check bits don’t match, note which ones are incorrect. • Add the position numbers of those bits to determine which bit is in error • Only one bit of correction available

31. Try it • Compose a short message. • Encode A as 00001, B 00010, etc. • Break your message into 15 bit segments (3 letters) • Use the Hamming code to insert check bits into each segment • CHANGE A BIT in at least one segment and give the modified message to someone to receive. • When you receive a message, use the Hamming code to determine if there is a bit error and to correct an error if it exists.

32. Error correction summary • Error correction is possible • overhead required can be a burden • limited ability to make corrections • Alternative • retransmit • avoid the overhead of extra bits in the case where no errors occur • incur the overhead of retransmission when there are errors

33. Retransmission strategies • Stop and Wait • send one packet. Wait for acknowledgement • If no acknowledgement arrives, sender retransmits. • Cannot tell if the packet failed to arrive or if the acknowledgement was sent but failed to arrive • Duplicate packets may appear at the receiver side, so some kind of packet numbering is necessary • 0,1 provide sufficient numbering to let the receiver recognize duplicates

34. Time Normal, successful operation Failed delivery. Sender times out and resends Ack is lost. Sender times out and resends Receiver now has two good copies

35. Packet numbers • Send and wait • At worst, two packets that might be confused • Only two different labels are needed • 0 and 1 does fine

36. What is wrong with this picture? • In what ways does this approach look undesirable? • What is the sender doing all the time? • What is the receiver doing all the time? • Is either underutilized?

37. Send and Wait problem • Sender is not used efficiently • must wait for an acknowledgement before starting to transmit another packet • if the packet or ack is lost, the sender must wait for a timer to expire • timer is set for a long enough interval that it won’t go off before an ack arrives • Question: What happens if the timer is set too short?

38. Go Back N • Continue transmitting • assume the packets are getting through ok • keep copies of packets in case retransmission is necessary • limited window of packets that can be outstanding (sent, not acknowledged) • as acks arrive, slide the window

39. Can send (0,4) (0,4) (0,4) (1,5) (2,6) (3,7) time 0 1 2 3 4 5 1 2 3 4 Correct operation, no packet loss, window slides Can send (0,4) (0,4) (0,4) (0,4) (0,4) (3,7) 0 1 2 3 4 5 3 Packets become reordered in transit. Ack says I have all before this one; send the next one.

40. Go Back N • Allow more efficient use of the sender • Transmit more packets while awaiting acknowledgement of earlier ones. • Makes the process more complex • When something is missing, it is harder to tell what needs to be resent • Remember that both original transmissions and acknowledgements are subject to loss

41. Timing • Round trip times are not consistent in an internet • vary by path taken • vary by congestion • How should the retransmission timer be set? • Adaptive retransmission timers • observe round trip time and adjust accordingly • harder than it sounds

42. Retransmission timing • Early approach RTT = (*Old_RTT) + ((1-)*New_Round_Trip_Sample) 0 <<1 Timeout = *RTT;  >1  close to 1 ignores changes that last only a short time.  close to 0 quickly responds to changes  close to 1 detects loss quickly;  = 1 responds too quickly. Any small variation in round trip time would cause timeout.

43. Dealing with variations and loss If a packet is retransmitted, how do you distinguish between a delayed ack for the original transmission and an ack for the retransmission? Ambiguous Acks problem Either assumption leads to problems becoming worse Sometimes the assumption will be wrong and the timer will be changed in the wrong direction

44. Karn’s algorithm • Only adjust for unambiguous acks • Simplest approach does not always work • transmission after a sharp increase in delay will cause a timeout and retransmission • don’t use the new times because the acks are ambiguous • will never get a correct estimate, unless the delay goes away • Timer backoff • use times and ignore ambiguous acks, but increase the timer each time there is a timeout

45. Flow Control • Buffer allocation is not simple. • Available buffer space may be shared among several transport clients • Receiver can tell the sender to slow down or stop transmitting for a time by using the “can-send” window. Upper bound of 0 means stop.

46. Congestion • Congestion happens in an internetwork when switching points (routers) are unable to handle the volume of packets passing through. • TCP assumes that the most likely cause of packet loss is congestion. • TCP reacts to indications of congestion by backing off on the rate at which new packets are sent

47. Congestion avoidance • When packet loss occurs, reduce the can-send window by half. Increase the retransmission timer exponentially. • Window is reduced by half for every packet loss. That is exponential decay while congestion continues. • The response is quick and dramatic • With every TCP source doing the same, the change is significant and fast.

48. Congestion avoidance • A rapid start up would flood the network and cause (or restore) congestion • Slow start • start the window at 1 • increase the window size by 1 with each packet acknowledgement arrival • When half the full window size is reached, the growth rate is slowed • increase the window size by 1 only when all packets in a window have been acknowledged.

49. Two ends of flow control • Receiver reacts to the availability of its own resources. Uses window size to slow down the sender • Sender must look for indications of congestion in the network and respond to them by adjusting its rate of transmission

50. Transport summary • End to end communication • Hide any network failures from the user • Congestion control • reduce the rate of transmission to respond to indications of congestion in the networks • increase rate gradually while watching the effect