CSS432 End-to-End Protocols Textbook Ch5.1 – 5.2 Prof. Athirai Irissappane http://courses.washington.edu/css432/athirai/ athirai@uw.edu CSS432: End-to-End Protocols

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

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

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

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.

Silly Window Syndrome Silly Window Syndrome

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

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

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

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

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

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

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

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

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

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

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

Jacobson/ Karels Algorithm Original Algorithm EstRTT = a x 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.125 Diff Dev = Dev + d(|SampleRTT – EstRTT| – Dev) Diff TimeOut = m x EstRTT + f x Dev 1 4 CSS432: End-to-End Protocols

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

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