Chapter 5 TCP Sequence Numbers TCP Transmission Control

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

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

Sequence Number Sequence. Num 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 3

TCP seq. #’s and ACKs 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 Host B Host A User types ‘C’ Seq=4 2, AC K=79, data = ata 43, d = K 9, AC 7 = q e S host ACKs receipt of echoed ‘C’ Seq=4 3 ‘C’ = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ , ACK= 80 simple telnet scenario time

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

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 6

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

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! 8

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

Figuring out Wraparound Time 232 B / bandwidth (in Bytes) How long for wraparound on 2. 5 Gbps 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) 10

Keeping the Pipe Full 16 -bit Advertised. Window 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)

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

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

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)

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 15

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

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 17

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

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

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 un. ACKed data in flight buffer the new data until an ACK arrives else send all the new data now

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

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 Q: how to estimate RTT? Sample. RTT: measured time from segment transmission until ACK receipt ignore retransmissions Sample. RTT will vary, want estimated RTT “smoother” average several recent measurements, not just current Sample. RTT

Adaptive Retransmission Original Algorithm Measure Sample. RTT for each segment/ ACK pair Compute weighted average of RTT Est. RTT = α x Est. RTT + (1 - α )x Sample. RTT α between 0. 8 and 0. 9 (typically 0. 875) Set timeout based on Est. RTT Time. Out = 2 x Est. RTT

Adaptive Retransmission 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

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

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

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

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 Estimated. RTT may be very wrong

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

Jacobson/Karels Algorithm Difference = Sample. RTT − Estimated. RTT = Estimated. RTT + ( × Difference) Deviation = Deviation + (|Difference| − Deviation) Time. Out = Estimated. RTT + 4 × Deviation When Time. Out is close to Estimated. RTT When the variance is small the variance is large Deviation term dominates the Time. Out calculation is between 0 and 1

TCP: retransmission scenarios Host A ytes d ata 100 X = ACK loss Seq=9 2, 8 b y Seq=92 timeout 2, 8 b Host B Seq=9 2, 8 b ytes d ata Seq= 100, 2 0 byte s data 0 10 = K 120 = C K A AC Seq=9 tes da ta 100 = ACK lost ACK scenario 2, 8 b Seq=92 timeout Seq=9 time Host A Host B time ytes d ata 20 K=1 AC premature timeout

TCP retransmission scenarios (more) Host A Host B Seq=9 timeout 2, 8 b ytes d ata =100 K C A 00, 20 bytes data Seq=1 X loss 120 = ACK time Cumulative ACK scenario

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 33

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

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

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