William Stallings Data and Computer Communications

1. William StallingsData and Computer Communications Chapter 17 Transport Protocols

2. Transport Protocol - Summary • Provides end-to-end data transfer • Shields upper layer application protocols from the details of networks • TCP: complicated flow and error control since the underlying network service (IP) is unreliable • TCP is connection oriented • UDP is connectionless

3. Connection Oriented Transport Protocol Mechanisms • Logical connections between end users • Establishment • Maintenance • Termination • Reliable service • e.g. TCP

4. Connection Oriented Transport Protocol Mechanisms • TCP is complex because of IP, which is unreliable • Let’s assume the underlying network service is reliable (for simplicity) • frame relay (LAPF control protocol) • 802.3 LAN with connection oriented LLC

5. Flow Control • Transport level flow control is more difficult than link-level one • transmission delay is variable due to network. That makes difficult to use timeouts • Recall from link level flow control • Backpressure • clumsy and coarse grained • Sliding window protocols • Works well on reliable network • Failure to receive ACK is taken as flow control indication • Does not work well on unreliable network • Can not distinguish between lost segment and flow control • Credit scheme

6. Credit Scheme • Decouples flow control from ACK • May ACK without granting credit and vice versa • Each octet has a sequence number • Each transport segment has a header that contains • sequence number • ack number • window size

7. Use of Header Fields • When sending • seq. number (SN) of first octet in segment is included • ACK includes AN=i, W=j • All octets through SN=i-1 are acknowledged • Next expected octet is i • Permission to send additional window of W=j octets • i.e. octets through i+j-1

8. Credit Allocation (Example)

9. Connection Establishment and Termination • Necessary even with a reliable network services • Purposes • Allow each end to know the other exists • Negotiation of optional parameters • Triggers allocation of transport entity resources • Connection establishment is by mutual agreement • control messages are exchanged

10. Connection State Diagram

11. Connection Establishment

12. Not Listening • What happens if SYN comes when the receiver is in CLOSED state • 3 options • Reject with RST (Reset) command • Request is queued until matching OPEN is issued • Notify upper layer about the pending request

13. Termination • Either side may initiate termination • By mutual agreement • Graceful termination • FIN WAIT state must accept incoming data until FIN received

14. Side Initiating Termination • TS user issues Close request • Transport entity sends FIN, requesting termination • Connection placed in FIN WAIT state • Continue to accept data and deliver data to user • Do not send any more data • When FIN received, inform user and close connection

15. Side Not Initiating Termination • FIN received • Inform TS user and place connection in CLOSE WAIT state • Continue to transmit data • TS user issues CLOSE primitive • Transport entity sends FIN • Connection closed • This procedure ensures that • both sides received all outstanding data • both sides agree to terminate

16. Unreliable Network Service • E.g. • internet using IP, • frame relay using LAPF core protocol • IEEE 802.3 using unacknowledged connectionless LLC • Segments may get lost • Segments may arrive out of order • variable transit delays • Solutions will create other problems

17. Problems • Ordered Delivery • Retransmission strategy • Duplication detection • Flow control • Connection establishment • Connection termination

18. Ordered Delivery • Segments may arrive out of order • General solution: number data units sequentially • TCP numbers each octet sequentially • implicit numbering • Segments are numbered by the first octet number in the segment

19. Retransmission Strategy • Segment may be damaged while in transit • Segment may fail to arrive • Positive acknowledgment: receiver must acknowledge successful receipt • Cumulative acknowledgment can be used • several segments can be acknowledged in one ack message • Waiting ACK for a long period of time (timeout period) triggers re-transmission

20. Timer Value • Fixed timer • Based on typical network behavior • Can not adapt to changing network conditions • “Too small” leads to unnecessary re-transmissions • “Too large” causes slow response to lost segments • Should be a bit longer than round trip time (but this is not fixed) • Adaptive scheme: average round-trip delay • May not ACK immediately (cumulative ack) • Conditions may change suddenly • No complete solution

21. Duplication Detection • If ACK lost, segments are re-transmitted • Receiver must recognize duplicates • Duplicate may arrive before the original one • Duplicate received prior to closing connection • Receiver assumes that ACK is lost and send ACK for the duplicate • Sender must not get confused with multiple ACKs for the same segment • Sequence number space large enough to not cycle within maximum life of segment • Duplicate received after closing connection

22. Incorrect Duplicate Detection • Sequence space is 1600 • Sliding window with window size of 600

23. Flow Control • Credit allocation scheme is quite robust and flexible • it is possible to increase credit without ack • after (AN = i, W = j), (AN = i, W = k), k >j • it is possible to ack without extra credit • after (AN = i, W = j), (AN =i + m, W = j - m), m: acked segment length • Lost ACK/CREDIT is generally no problem • future acks resynchronize the protocol • lost ack causes timeout and retransmission • retransmission triggers ack • but deadlock is still possible

24. Flow Control • Possible deadlock case • receiver temporarily closes window with AN=i, W=0 • later reopens with AN=i, W=j, but this is lost • Sender thinks window is still closed, receiver thinks it is open • SOLUTION: use window timer • timer for ACK/CREDIT segments • timer expires if no ACK/CREDIT segments are received within the timeout period • if timer expires, retransmit the previous ACK/CREDIT segment

25. Connection Establishment • Two way handshake • A send SYN, B replies with SYN • Lost SYN handled by re-transmission (special timer) • Can lead to duplicate SYNs • Ignore duplicate SYNs once connected • Lost or delayed data segments can cause connection problems • Segment from old connections (see next figure)

26. Two Way Handshake:Obsolete Data Segment

27. Solution to Obsolete Data Segment Problem • First segment number of the new connection must be distant from the last segment number of the previous connection • Need to specify the expected sequence numbers of the connections • Use SYN i • i is the sequence number of the first segment on that connection • acknowledged by SYN j • New Problem: Obsolete SYN (see next figure)

28. Two Way Handshake:Obsolete SYN Segment

29. Solution to Obsolete SYN Problem • Acknowledgments should also include the request’s SYN number (AN=i) • Three Way Handshake • Second ack is actually a data segment

30. Three Way Handshake:State Diagram

31. Connection Termination • Entity in CLOSE WAIT state sends last data segment, followed by FIN • FIN arrives before last data segment • Receiver accepts FIN • Closes connection • Loses last data segment • Add sequence number (number just after the last transmitted octet) to FIN • Receiver waits for all segments before FIN sequence number

32. Connection Termination • Graceful close • Send FIN i and receive AN i • Receive FIN j and send AN j • Wait twice maximum expected segment lifetime FIN i FIN i AN i AN i, FIN j FIN j AN j AN j

33. TCP & UDP • Transmission Control Protocol • Connection oriented • RFC 793 • User Datagram Protocol (UDP) • Connectionless • RFC 768

34. TCP • Reliable communication between pairs of processes • Variety of primitives • Passive/Active open • Send / Deliver data • Close primitives • Connections are identified by a pair of sockets • a socket is (IP address, port number) • ports less than 1024 are fixed • e.g. 23 telnet, 80 www • others are at operating systems disposal for individual needs

35. TCP Header

36. TCP Header • Checksum includes IP addresses as well in a pseudo-header • check misdelivery • spoils protocol hierarchy • Question: What about segment length? It is not in the TCP header. How is the receiver TCP user be informed about the payload length?

37. TCP Mechanisms (1) • Connection establishment • Three way handshake • Between pairs of ports • One port can connect to multiple destinations

38. TCP Mechanisms (2) • Data transfer • Logical stream of octets • Octets numbered modulo 232 • Segments contain sequence number of the first octet • Flow control by credit allocation of number of octets • Data buffered at transmitter and receiver • TCP decides when to construct a segment • exception is PUSH • RST is sent when • obsolete and duplicate SYNs are received • TCP segment is misdelivered

39. TCP Mechanisms (3) • Connection termination • Graceful close • TCP users issues CLOSE primitive • Transport entity sets FIN flag on last segment sent • Abrupt termination by ABORT primitive • Entity abandons all attempts to send or receive data • RST segment transmitted

40. Implementation Policy Options • Send • Deliver • Accept • Retransmit • Acknowledge

41. Send • If no push or close TCP entity transmits at its own convenience • Data buffered at transmit buffer • May construct segment per data batch • May wait for certain amount of data • Trade-off • infrequent and large segments • low processing overhead, slow response • frequent and small segments • quick response, but high processing overhead

42. Deliver • In absence of push, TCP delivers data at its own convenience • May deliver as segments are received • May buffer several segments and then deliver • Performance trade-off • response time versus processing overhead/interrupts

43. Accept • Segments may arrive out of order • In order • Only accept in-order segments • Discard out-of-order segments • easy implementation, simple • lots of retransmissions • In windows • Accept all segments within receive window • complicated • large buffers • less retransmissions

44. Retransmit • TCP will retransmit if does not receive ACK in given time • First only • single timer for all segments waiting ack • if expires the oldest segment waiting ack is retransmitted • longer delays for the other segments • Batch • single timer for all segments waiting ack • if expires all segments waiting ack are retransmitted • smaller delays but unnecessary retransmissions • Individual • one timer per segment • complex implementation

45. Acknowledgment • Immediate • limits unnecessary retransmissions • increase the load by acks • Cumulative • typical method • problem in estimating timer values

46. Retransmission Timer Management • Estimate round trip time (RTT) by observing pattern of delay • Set time to value a bit greater than estimate • Simple average • average the RTTs over a number of segments • Exponential average • later segments have more weight • smaller  means greater weight to the last RTT

47. Use of Exponential Averaging

48. How to determine RTO (Retransmission Timeout) • Add fixed  to estimated RTT • Multiply estimated RTT with a fixed factor • Both not good if the observed RTT has variation • It is better if the RTO depends on the estimated RTT and standard deviation in RTT • Jacobson’s method

49. Jacobson’s RTO Calculation • Exp. Average is not good if variation is too much • RTT Variance Estimation (Jacobson’s algorithm) • Includes standard deviation in the calculations • f: the factor that effects RTO

50. Exponential RTO Backoff • What RTO will be used for a retransmitted segment? • Since timeout is probably due to congestion (dropped packet or long round trip), maintaining the same RTO is not good idea • RTO increased each time a segment is re-transmitted • RTO = 2*RTO • Binary exponential backoff