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. simple telnet scenario
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 A
Host B
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
time
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 = 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. Required window size for 100-ms RTT.
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 = 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. 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?
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

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
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. TCP: retransmission scenarios
Host A
Seq=92, 8 bytes data
ACK=100
loss
timeout
lost ACK scenario
Host B X
time
Host A
Host B
Seq=92 timeout
Seq=92, 8 bytes data
Seq=100, 20 bytes data
ACK=100
ACK=120
Seq=92, 8 bytes data
Seq=92 timeout
ACK=120
time
premature timeout

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

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]
Event at Receiver
Arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
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
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

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