1. CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2
Prof. Athirai Irissappane
CSS432: End-to-End Protocols

2. Protection Against Wrap Around
32-bit SequenceNum
2^32 numbers: 0 to 2^32-1
After 2^31-1? Start from 0 (wrap around)
MSL (Maximum Segment Lifetime) = 120sec < wrap around time (time taken to exhaust all sequence numbers)
Bandwidth Time Until Wrap Around
T1 (1.5 Mbps) 6.4 hours
Ethernet (10 Mbps) 57 minutes
T3 (45 Mbps) 13 minutes
FDDI (100 Mbps) 6 minutes
STS-3 (155 Mbps) 4 minutes
STS-12 (622 Mbps) 55 seconds
STS-24 (1.2 Gbps) 28 seconds
CSS432: End-to-End Protocols

3. CSS432: End-to-End Protocols
Keeping the Pipe Full
Utilize full bandwidth: sender transmit RTT*Bandwidth data
Sender transmission restricted by Receiver Advertised Window
Receiver Advertised Window should be enough to accommodate RTT*Bandwidth data
But 16-bit AdvertisedWindow = 64KB (2^16 bytes)
Bandwidth RTT(100msec) x Bandwidth Product
T1 (1.5 Mbps) 18KB
Ethernet (10 Mbps) 122KB
T3 (45 Mbps) 549KB
FDDI (100 Mbps) 1.2MB
STS-3 (155 Mbps) 1.8MB
STS-12 (622 Mbps) 7.4MB
STS-24 (1.2 Gbps) 14.8MB
Every byte is given a sequence number
CSS432: End-to-End Protocols

4. CSS432: End-to-End Protocols
Segment Transmission
A segment is transmitted out:
When a segment to send reaches Maximum segment size (MMS) = Maximum Transfer Unit (MTU)
When a TCP receives a push operation that flushes the unsent data, data is pushed as and when written instead of waiting for segment to be filled (Peek with tcpdump in programming assignment 3)
When a timer fires
CSS432: End-to-End Protocols

5. Silly Window Syndrome
If you think of a TCP stream as a conveyer belt with “full” containers (data segments) going in one direction and empty containers (ACKs) going in the reverse direction, then MSS-sized segments correspond to large containers and 1-byte segments correspond to very small containers.
If the sender aggressively fills an empty container as soon as it arrives, then any small container introduced into the system remains in the system indefinitely.
That is, it is immediately filled and emptied at each end, and never coalesced with adjacent containers to create larger containers.

6. Silly Window Syndrome
Silly Window Syndrome

7. CSS432: End-to-End Protocols
Silly Window Syndrome
small
MMS 2
Sender
MMS 1
Receiver
Ad Window
Ad Window
If a sender aggressively takes advantage of any available window,
The receiver empties every window regardless of its size and thus small windows will never disappear.
The problem occurs only when either the sender transmits a small segment or the receiver opens the window a small amount
The receiver can delay ACKs to make a larger window
How long does it wait?
The sender should make a decision
Nagle’s Algorithm (Programming assignment 3)
CSS432: End-to-End Protocols

8. 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
But how long?
If we wait too long, then we hurt interactive applications like Telnet
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

9. 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

10. Nagle’s Algorithm When the application produces data to send
if both the available data and the window ≥ MSS
send a full segment
else
if there is unACKed data at the sender // if ACK not received for buffer the new data until an ACK arrives previous data sent
else // if no unACKed data
send all the new data now

11. CSS432: End-to-End Protocols
Nagle’s Algorithm
Ack works as a timer to fire a new segment transmission.
intentionally delays packets.
Time sensitive applications or real-time applications cannot afford such a delay
TCP_NODELAY option in Socket Interface: Transmit data as soon as possible
setsockopt(sockfd, SOL_TCP, TCP_NODELAY, &intFlag, sizeof(intFlag))
Default- enabled
CSS432: End-to-End Protocols

12. Adaptive Retransmission
TCP retransmits segment if ACK not received within timeout
Timeout determined based on RTT
RTT between different pair of hosts in internet different
How to choose timeout?
Adaptive Retransmission

13. Adaptive Retransmission Original Algorithm
(keep running average of RTT)
Measure SampleRTT for each segment/ ACK pair
Record time when you start sending
Record time when you receive ACK
Take difference
Compute weighted average of RTT
EstRTT = a x EstRTT + b x SampleRTT
where a + b = 1
a between 0.8 and 0.9
b between 0.1 and 0.2
Set timeout based on EstRTT
TimeOut = 2 x EstRTT
Why double? EstRTT cannot respond to deviated SampleRTT quickly.
CSS432: End-to-End Protocols

14. Original Algorithm 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

15. Karn/Partridge Algorithm
Sender
Receiver
Sender
Receiver
Original transmission
Original transmission TT TT
ACK
Retransmission
SampleR
SampleR
Retransmission
ACK
Assume ACK for original transmission and actually it is for retransmission
SampleRTT is too large
Assume ACK for ret ransmission and actually it is for original transmission
SampleRTT is too smal
CSS432: End-to-End Protocols

16. Karn/Partridge Algorithm
Do not sample RTT when retransmitting
Can’t figure out which transmission the latest ACK corresponds to.
Whenever TCP retransmits
Set the last timeout to be double the previous value (similar to exponential backoff)
Congestion causes this retransmission.
Do not react aggressively and be more cautious when more time outs happen
Modestly retransmit segments.
CSS432: End-to-End Protocols

17. 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

18. 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
There is no need to multiply this by 2 to compute the timeout

19. Karn/Partridge Algorithm
On the other hand, a large variance in the samples suggest that timeout value should not be tightly coupled to the Estimated RTT
Jacobson/Karels proposed a new scheme for TCP retransmission

20. Jacobson/ Karels Algorithm
Original Algorithm
EstRTT = a x EstRTT + b x SampleRTT
0.8 and and 0.2
TimeOut = EstRTT * 2
New Algorithm that takes into a consideration if the variation among smapleRTTs are large.
EstRTT = EstRTT + d(SampleRTT – EstRTT)
Diff
Dev = Dev + d(|SampleRTT – EstRTT| – Dev)
Diff
TimeOut = m x EstRTT + f x Dev
CSS432: End-to-End Protocols

21. CSS432: End-to-End Protocols
TCP Extensions
RTT Measurement
Store a 32-bit timestamp in outgoing segments’ header option
Receive an ack with the original timestamp
Sample RTT by subtracting the timestamp from the current timer
Resolving the quick wrap-around of sequence number
The 32-bit timestamp and the 32-bit sequence number gives a 64-bit sequence space
TimeStamp differentiate 2 different incarnations of the same sequence number
Extending an advertised window
Scale up the advertised window
How many bytes to send → How many 16-byte units to send
CSS432: End-to-End Protocols

22. CSS432: End-to-End Protocols
Reviews
UDP
TCP: three-way handshake and state transition
Sliding window and flow control
Segment transmission: silly window syndrome and Nagle’s algorithm
Adaptive retransmission: original, Karn/Partridge, and Jacobson/Karels
CSS432: End-to-End Protocols