Chapter 5 TCP Sequence Numbers & TCP Transmission Control

1. Chapter 5 TCP Sequence Numbers & TCP Transmission Control Networking CS 3470, Section 1

2. Sequence Number • SequenceNum field contains the sequence number for the first byte of data carried in segment • Important for ??

3. Sequence Number • SequenceNum field contains the sequence number for the first byte of data carried in segment • Important for • Detecting dropped packets • Detecting out of order packets • Flow control

4. time TCP seq. #’s and ACKs Host B Host A Seq. #’s: • byte stream “number” of first byte in segment’s data ACKs: • seq # of next byte expected from other side • cumulative ACK Q: how receiver handles out-of-order segments • A: TCP spec doesn’t say, - up to implementer User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 simple telnet scenario

5. Protecting against Wraparound • Relevance of the 32-bit sequence number space • The sequence number used on a given connection might wraparound • A byte with sequence number x could be sent at one time, and then at a later time another byte with the same sequence number x could be sent

6. Protecting against Wraparound • Packets cannot survive in the Internet for longer than the TCP Maximum Segment Lifetime (MSL), which is 120 sec • We need to make sure that the sequence number does not wrap around within a 120-second period of time • Depends on how fast data can be transmitted over the Internet

7. Protecting against Wraparound • How many bytes of transferred data does the 32-bit sequence number represent?

8. Protecting against Wraparound • How many bytes of transferred data does the 32-bit sequence number represent? • 232 bytes are represented • 4 GB of data can be sent!

9. Protecting against Wraparound Time until 32-bit sequence number space wraps around. • TCP extension is used to extend sequence number space

10. Figuring out Wraparound Time • 232 B / bandwidth (in Bytes) • How long for wraparound on 2.5Gbps network (OC-48)? • Convert bandwidth to Bytes • 2.5 Gbps / 8 = 0.3125 GBps * 109 = 312,500,000 Bps • 232 B / 312,500,000 Bps = 14 sec • (Can also use 230 instead of 109)

11. Keeping the Pipe Full • 16-bit AdvertisedWindow field must be big enough to allow the sender to keep the pipe full • If the receiver has enough buffer space • The window needs to be opened far enough to allow a full delay × bandwidth product’s worth of data • Assuming an RTT of 100 ms (typical cross-country connection in US)

12. Keeping the Pipe Full Required window size for 100-ms RTT. • Uh oh – 16 bit field only allows us to advertise a window of 64KB (216 = 65536 B = 64KB) • TCP extension is used to extend AdvertisedWindow

13. Triggering Transmission • How does TCP decide to transmit a segment? • TCP supports a byte stream abstraction • Application programs write bytes into streams • It is up to TCP to decide that it has enough bytes to send a segment

14. Triggering Transmission • TCP has three mechanism to trigger the transmission of a segment • 1) TCP maintains a variable MSS (maximum segment size) and sends a segment as soon as it has collected MSS bytes from the sending process • MSS is usually set to the size of the largest segment TCP can send without causing local IP to fragment. • MSS: MTU of directly connected network – (TCP header + and IP header)

15. Triggering Transmission • 2) Sending process has explicitly asked TCP to send it • TCP supports push operation • 3) When a timer fires • Resulting segment contains as many bytes as are currently buffered for transmission

16. Silly Window Syndrome • Of course, we can’t ignore flow control. • Suppose the TCP sender is stopped for awhile (AdvertisedWindow = 0) • Now suppose TCP sender receives an ACK that opens the window up to half of MSS • Should the sender transmit?

17. Silly Window Syndrome • The strategy of aggressively taking advantage of any available window leads to silly window syndrome • Once smaller segment size is introduced into TCP segment system, it will stay around indefinitely

18. Nagle’s Algorithm • If there is data to send but the window is open less than MSS, then we may want to wait some amount of time before sending the available data • If we wait too long, then we hurt interactive applications • If we don’t wait long enough, then we risk sending a bunch of tiny packets and falling into the silly window syndrome • The solution is to introduce a timer and to transmit when the timer expires

19. Nagle’s Algorithm • We could use a clock-based timer, for example one that fires every 100 ms • Nagle introduced an elegant self-clocking solution • Key Idea • As long as TCP has any data in flight, the sender will eventually receive an ACK • This ACK can be treated like a timer firing, triggering the transmission of more data

20. Nagle’s Algorithm When the application produces data to send if both the available data and the window ≥ MSS send a full segment else /* window < MSS */ if there is unACKed data in flight buffer the new data until an ACK arrives else send all the new data now

21. TCP Retransmission (Timeouts) • How should TCP set its timeout value? • Too short will unnecessarily retransmit segments • Too long will introduce unnecessary delay

22. Q: how to estimate RTT? SampleRTT: measured time from segment transmission until ACK receipt ignore retransmissions SampleRTT will vary, want estimated RTT “smoother” average several recent measurements, not just current SampleRTT Adaptive Retransmission Q: how to set TCP timeout value? • longer than RTT • but RTT varies • too short: premature timeout • unnecessary retransmissions • too long: slow reaction to segment loss

23. Adaptive Retransmission • Original Algorithm • Measure SampleRTT for each segment/ ACK pair • Compute weighted average of RTT • EstRTT = α x EstRTT + (1 - α )x SampleRTT • α between 0.8 and 0.9 (typically 0.875) • Set timeout based on EstRTT • TimeOut = 2 x EstRTT

24. Adaptive Retransmission Problem • Problem • ACK does not really acknowledge a transmission • It actually acknowledges the receipt of data • When a segment is retransmitted and then an ACK arrives at the sender • It is impossible to decide if this ACK should be associated with the first or the second transmission for calculating RTTs

25. Adaptive Retransmission Problem • Associating the ACK with (a) original transmission versus (b) retransmission To which transmission does the ACK belong?

26. Karn/Partridge Algorithm • Whenever TCP retransmits a segment, it does not take sample of RTT • Double timeout after each retransmission • Exponential backoff

27. Karn/Partridge Algorithm • Karn-Partridge algorithm was an improvement over the original approach, but it does not eliminate congestion • We need to understand how timeout is related to congestion • If you timeout too soon, you may unnecessarily retransmit a segment which adds load to the network

28. Karn/Partridge Algorithm • Main problem with the original computation is that it does not take variance of Sample RTTs into consideration. • If the variance among Sample RTTs is small • Then the Estimated RTT can be better trusted • Otherwise • The EstimatedRTT may be very wrong

29. Karn/Partridge Algorithm • Jacobson/Karels proposed a new scheme for TCP retransmission • Takes variance (deviation term) into account

30. Jacobson/Karels Algorithm Difference = SampleRTT − EstimatedRTT EstimatedRTT = EstimatedRTT + ( × Difference) Deviation = Deviation + (|Difference| − Deviation) TimeOut = EstimatedRTT + 4 × Deviation • When the variance is small • TimeOut is close to EstimatedRTT • When the variance is large • Deviation term dominates the TimeOut calculation •  is between 0 and 1

31. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=92 timeout timeout X loss Seq=92, 8 bytes data ACK=100 time time lost ACK scenario TCP: retransmission scenarios Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data ACK=100 ACK=120 Seq=92, 8 bytes data ACK=120 Seq=92 timeout premature timeout

32. Host A Host B Seq=92, 8 bytes data ACK=100 Seq=100, 20 bytes data timeout X loss ACK=120 time Cumulative ACK scenario TCP retransmission scenarios (more)

33. TCP ACK generation • How quickly should the receiver send an ACK? • If ACKs are cumulative, it makes sense that the receiver would not send an ACK for every single packet received

34. TCP ACK generation[RFC 1122, RFC 2581] TCP Receiver action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK, ACKing both in-order segments Immediately send duplicate ACK, indicating seq. # of next expected byte Immediately send ACK, provided that segment starts at lower end of gap Event at Receiver Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed Arrival of in-order segment with expected seq #. One other segment has ACK pending Arrival of out-of-order segment higher-than-expect seq. # . Gap detected Arrival of segment that partially or completely fills gap

35. Fast Retransmit • Time-out period often relatively long: • long delay before resending lost packet • Detect lost segments via duplicate ACKs. • Sender often sends many segments back-to-back • If segment is lost, there will likely be many duplicate ACKs. • If sender receives 3 ACKs for the same data, it supposes that segment after ACKed data was lost: • fast retransmit: resend segment before timer expires

36. TCP Extensions • Timestamp inserted into the header • Help measure RTT • Detect which ACKs are for what transmissions • Timestamp used to help prevent sequence number wraparound • AdvertisedWindow can measure larger units than 1 byte • Left-shift scaling factor • Selective (SACKs) for out of order segments