Slide Set 13: TCP

1. Slide Set 13: TCP

2. In this set.... • TCP Connection Termination • TCP State Transition Diagram • Flow Control • How does TCP control its sliding window ?

3. Connection Termination • Note that after the server receives the FIN_WAIT_1, it may still have messages -- thus, connection not yet closed. Active Close FIN_WAIT1 FIN, Seq Num = M DATA/ACK CLOSE_WAIT ACK= M+1 FIN_WAIT2 LAST_ACK FIN, Seq Num = N ACK N+1 CLOSED

4. TCP State Transitions • Note: Retransmissions and Data Packet /ACK exchanges are not represented in the state transition diagram. • Final Wait time needed to ensure that the ACK is not lost. • Simultaneous Connection Inceptions/ Terminations possible !

5. An Simpler View of the Client Side 120 secs SYN (Send) CLOSED TIME_WAIT SYN_SENT Rcv. FIN, Send ACK Rcv. SYN+ACK, Send ACK ESTABLISHED FIN_WAIT2 FIN_WAIT1 Rcv. ACK, Send Nothing Send FIN

6. Simpler Server Model Passive OPEN, Create Listen socket Rcv. ACK, Send nothing CLOSED LAST ACK LISTEN Send FIN Rcv. SYN, Send SYN+ACK SYN_RCVD CLOSE_WAIT ESTABLISHED RCV ACK Rcv. FIN, Send ACK

7. More about Termination • Applications on both sides have to “independently” close their half of the connection. • If one side does it, this means that this side has no data to send but it is willing to receive. • In the TIME_WAIT state, a client waits for 2 X MSL (typically). During this time the socket cannot be reused. • If ACK is lost, a new FIN may be forthcoming and this second FIN may be delayed. • Thus, if a new connection uses the same connection i.e., the same port numbers, this FIN would initiate termination of later connection !

8. Sequence Numbers and ACKs • How does one set Sequence numbers ? • Implicitly a number in every byte in the stream. • If we have 500000 bytes and each segment = MSS and = 1000 bytes, SN of 1st segment = 0, SN of second segment = 1000 and so on. • Note that ACK number is the number that the receiving host puts in -- indicates the “next” byte that it is expecting. • ACKs are cumulative -- ACK up to all the bytes that are received.

9. Flow Control • Flow control ensures that the sender does not send at a rate that causes the receiver buffer to overflow. • Note that flow control is “end-to-end”.

10. Buffers at End Hosts • Sending buffer • Maintains data sent but not ACKed • Data written by application but not sent. • Receive buffer • Data that arrives out of order • Data that is in correct order but not yet read by application.

11. Sender Side View • For now, let us forget SN wrap around. • Three pointers are maintained, LastByteAcked, LastByteSent, LastByteWritten. • LastByteAcked ≤ LastByteSent • LastByteSent ≤ LastByteWritten Sending application TCP LastByteWritten LastByteAcked LastByteSent (a)

12. Receiver Side View • Three pointers maintained again. • LastByteRead < NextByteExpected • NextByteExpected ≤ LastByteRcvd + 1 Receiving application TCP LastByteRead NextByteExpected LastByteRcvd

13. How is Flow Control done? • Receiver “advertises” a window size to the sender based on the buffer size allocated for the connection. • Remember the “Advertised Window” field in the TCP header ? • Sender cannot have more than “Advertised Window” bytes of unacknowledged data. • Remember -- buffers are of finite size - i.e., there is a MaxRcvBuffer and MaxSendBuffer.

14. Setting the Advertised Window • On the TCP receive side, clearly, LastByteRcvd -LastByteRead ≤ MaxRcvBuffer • Thus, it advertises the space left in the buffer i.e., Advertised Window = MaxRcvBuffer - (LastByteRcvd -LastByteRead) • As more data arrives i.e., more received bytes than read bytes, LastByteRcvd increases and hence, Advertised Window reduces.

15. Sender Side Response • At the sender side, the TCP sender should ensure that: LastByteSent - LastByteAcked ≤ Advertised Window. Thus, we define what is called the “Effective Window” which limits the amount of data that TCP can send :Effective Window = Advertised Window - (LastByteSent - LastByteAcked) • Note here that ACKing does not imply that the process has read the data! • In order to prevent the overflow of the Send Side buffer: LastByteWritten - LastByteAcked ≤ MaxSendBuffer • If application tries to write more, TCP blocks.

16. Persistency • What does one do when Advertised Window = 0 ? • The sender will persist by sending 1 segment. • Note that this segment may not be accepted by the receiver initially. • But at some point, it would trigger a response that may contain a new Advertised window.

17. Sequence Number Wraparound • TCP Sequence Number is 32 bits long. • Advertised Window is 16 bits. Since 232 >> 2 X 216, it is almost impossible for the same sequence number to exist twice -- wrap around unlikely. • In addition, MSL = 120 seconds to make sure that there is no wrap-around. • Time-stamps may also be used.

18. How long should the time-out be ? • Remember, TCP has to ensure reliability. • So bytes need to be resent if there is no “timely” acknowledgement. • How long should the sender wait ? • It should be adaptive -- fluctuation in load on the network. • If too short, false time-outs • If too long, then poor rate of sending. • Depends on round trip time estimation

19. RTT Estimation • Simple mechanism could be: • Send packet, record time T1 • When ACK is returned, record time = T2. • T2 -T1 = Estimated RTT. • To avoid fluctuations, estimated RTT is a weighted average of previous time and current sample Estimated RTT = (1-a) Estimated RTT + a SampleRTT • In the original specification a = 0.125 • The Time out is set to 2 * RTT.

20. A problem • When there are retransmissions, it is unclear if the ACK is for the original transmission or for a retransmission. • How do we overcome this ?

21. The Karn Patridge Algorithm • Take SampleRTT measurements only for segments that have been sent once ! • This eliminates the possibility that wrong RTT estimates are factored into the estimation. • Another change -- Each time TCP retransmits, it sets the next timeout to 2 X Last timeout --> This is called the Exponential Back-off (primarily for avoiding congestion).

22. Jacobson Karels Algorithm • The main problem with the Karn/Patridge scheme is that it does not take into account the variation between RTT samples. • New method proposed -- the Jacobson Karels Algorithm. • Estimated RTT = Estimated RTT + d X Difference • Difference = Sample RTT - Estimated RTT • Deviation = Deviation + d (|Difference| - deviation) • Timeout = m Estimated RTT + f deviation. • The values of m and f are computed based on experience -- Typically m = 1 and f = 4.

23. Silly Window Syndrome • Suppose a MSS worth of data is collected and advertised window is MSS/2. • What should the sender do ? -- transmit half full segments or wait to send a full MSS when window opens ? • Early implementations were aggressive -- transmit MSS/2. • Aggressively doing this, would consistently result in small segment sizes -- called the Silly Window Syndrome.

24. Issues .. • We cannot eliminate the possibility of small segments being sent. • However, we can introduce methods to coalesce small chunks. • Delaying ACKs -- receiver does not send ACKs as soon as it receives segments. • How long to delay ? Not very clear. • Ultimate solution falls to the sender -- when should I transmit ?

25. Nagle’s Algorithm • If sender waits too long --> bad for interactive connections. • If it does not wait long enough -- silly window syndrome. • How to solve ? • Timer -- clock based • If both available data and Window ≥ MSS, send full segment. • Else, if there is unACKed data in flight, buffer new data until ACK returns. • Else, send new data now. • Note -- Socket interface allows some applications to turn off Nagle’s algorithm by setting the TCP-NODELAY option.

26. TCP Throughput • If a connection sends W segments of MSS size (in bytes) in RTT seconds, then, the throughput is defined as : W *MSS / RTT bytes/second. • If there is a link of capacity R, if there are K connections, what we want is for each TCP connection to have a throughput = R/K.

27. Throughput (cont) • If a TCP session goes through n links and if link j has a rate Rj and is shared by Kj connections, ideally the throughput = Rj/Kj. • Thus, a connection’s end-to-end rate is r = min (R1/K1, R2/K2, .. Rj/Kj... Rn/Kn). • In reality not so simple, some connections may be unable to use their share -- so the share may be higher.

28. Where are we ? • We have covered Chapter 5 -- Sections 5.1 and 5.2. • Whatever I left out from Section 5.2 is for self-study.

29. Where are we headed ? • We will look at Congestion Control with TCP next time. • Chapter 6 -- Sections 6.3 and 6.4.