CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2

1. CSS432 End-to-End ProtocolsTextbook Ch5.1 – 5.2 Prof. Athirai Irissappane http://courses.washington.edu/css432/athirai/ athirai@uw.edu 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. 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 CSS432: End-to-End Protocols

4. 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. Silly Window Syndrome small MMS 2 Sender MMS 1 Receiver • 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) Ad Window Ad Window 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. 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 = ax 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 • 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 Original transmission Original transmission TT TT ACK Retransmission SampleR SampleR Retransmission ACK 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 = ax EstRTT + b x SampleRTT 0.8 and 0.9 0.1 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) 0.125Diff • Dev = Dev + d(|SampleRTT – EstRTT| – Dev) Diff • TimeOut = m x EstRTT + f x Dev 14 CSS432: End-to-End Protocols

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