TCP - Part II Relates to Lab 5. This is an extended module that covers TCP flow control, congestion control, and error control in TCP.

Flow Control Congestion Control Error Control TCP:

What is Flow/Congestion/Error Control ? Flow Control: Algorithms to prevent that the sender overruns the receiver with information? Congestion Control: Algorithms to prevent that the sender overloads the network Error Control: Algorithms to recover or conceal the effects from packet losses  The goal of each control mechanism is different.  But the implementation is combined

TCP -> Reliable Traditional technique: Positive Acknowledgement with Retransmission (PAR) Receiver sends acknowledgement when data arrives Sender starts timer whenever transmitting Sender retransmits if timer expires before acknowledgement arrives

ACKs and Retransmission – Simple Method

Packet Loss and Error Recovery

Multiple Packet Transmission Allow multiple packets to be outstanding at any time Still require acknowledgements and retransmission Known as sliding window Window size is fixed When acknowledgement arrives, window moves forward

Illustration of Sliding Window Because a well-tuned sliding window protocol keeps the network completely saturated with packets, it obtains substantially higher throughput than a simple positive acknowledgement protocol.

TCP’s Sliding Window Measured in byte positions Bytes through 2 are acknowledged Bytes 3 through 6 sent but not yet acknowledged Bytes 7 though 9 can be sent Bytes above 9 lie outside the window and cannot be sent

TCP’s Retransmission Designed for Internet environment Delays on one connection vary over time Delays vary widely between connections Fixed value for timeout will fail Waiting too long introduces unnecessary delay Not waiting long enough wastes network bandwidth with unnecessary retransmission Retransmission strategy must be adaptive

Difficulties with Adaptive Retransmission Estimating the retransmit timer is very complex Traffic is bursty, so round-trip times fluctuate wildly on a single connection Only one timer, so not all transmissions are timed Segments and/or ACKs can be lost or delayed, making roundtrip estimation difficult or inaccurate An ACK can sometimes include several segments

Round-Trip Time (RTT) Measurements Round-trip estimate derived from observed delay between sending segment and receiving acknowledgement The RTT is based on time difference between segment transmission and ACK But: TCP does not ACK each segment (ACK 2 > ACK 3) Each connection has only one timer And what about RTT for retransmitted packets?

Karn’s Algorithm Solves the problem of ACKs of retransmitted packets and RTT calculation Ignores round-trip times that correspond to retransmissions Starts with retransmission timer as a function of round-trip time (RTT) estimate Doubles retransmission timer value for each retransmission without changing round-trip time (RTT) estimate Resets retransmission timer to be function of round-trip time estimate when ACK arrives for a non-retransmitted segment

Calculating the Round Trip Time (RTT) Smoothing Adaptive retransmission schemes keep a statistically smoothed round-trip estimate Smoothing keeps running average from fluctuating wildly, and keeps TCP from overreacting to change Difficulty: choice of smoothing scheme Complex formula is used to calculate RTT

TCP Flow Control

TCP Flow Control TCP implements a form of sliding window flow control Sending acknowledgements is separated from setting the window size at sender Acknowledgements do not automatically increase the window size Acknowledgements are cumulative

Window Management in TCP The receiver is returning two parameters to the sender The interpretation is: I am ready to receive new data with SeqNo= AckNo, AckNo+1, …., AckNo+Win-1 Receiver can acknowledge data without opening the window Receiver can change the window size without acknowledging data Up to Window size (win)

Sliding Window: Example Sender Acks data Closes window Sender Opens window

Summary Flow Control and TCP Window Receiver controls flow by telling sender size of currently available buffer measured in bytes Called window advertisement Each segment specifies size of window beyond acknowledged byte Window size may be zero (receiver cannot accept additional data at present) Receiver can send additional acknowledgement later when buffer space becomes available

TCP Congestion Control

TCP Congestion Control – at Sender Assumes long delays –e.g., timeout, is due to congestion Bit errors rarely occur in current wired networks, so when a packet is not acknowledged, a sender assumes a loss due to buffer overflow Uses retransmissions as measure of congestion Reduces a parameter called the congestion window as retransmissions increase Send window is minimum of receiver’s advertisement and a computed quantity known as the congestion window flow control window is advertised by the receiver congestion window is set at sender and adjusted based upon feedback from the network Send Window = MIN (flow control window, congestion window)

TCP Congestion Control The sender uses two parameters: Congestion Window (cwnd) Initial value is 1 MSS (=maximum segment size) counted in bytes Slow-start threshhold Value (ssthresh) Initial value of ssthresh is the advertised window size (senders flow control window) Congestion control works in two modes: slow start (cwnd < ssthresh) congestion avoidance (cwnd >= ssthresh)

Slow Start Initial value: cwnd = 1 segment cwnd is measured in bytes 1 segment = MSS bytes Each time an ACK is received, the congestion window is increased by MSS bytes. cwnd = cwnd + 1segment If an ACK acknowledges two or more segments (cumulative ACK), cwnd is still increased by only 1 segment. Even if ACK acknowledges a segment that is smaller than MSS bytes long, cwnd is still increased by 1 segment. Does Slow Start increment slowly? Not really. In fact, the increase of cwnd can be exponential

Slow Start Example The congestion window size grows very rapidly For every ACK, we increase cwnd by 1 irrespective of the number of segments ACK’ed TCP slows down the increase of cwnd and goes into congestion avoidance mode when cwnd >= ssthresh

Congestion Avoidance Congestion avoidance phase is started if cwnd has reached the slow-start threshold value If cwnd >= ssthresh then each time an ACK is received, increment cwnd as follows: cwnd = cwnd + 1/ [cwnd] Where [cwnd] is the largest integer smaller than cwnd So cwnd is increased by one segment (=MSS bytes) only if all segments have been acknowledged in the previous congestion window size.

Slow Start / Congestion Avoidance If cwnd <= ssthresh then Each time an Ack is received: cwnd = cwnd + 1 else /* cwnd > ssthresh */ Each time an Ack is received : cwnd = cwnd + 1 / [ cwnd ] endif

Example of Slow Start/Congestion Avoidance Assume that ssthresh = 8 ssthresh Cwnd (in segments) Roundtrip times

Detecting Congestion Most often, a packet loss in a network is due to an overflow at a congested router (rather than due to a transmission error) TCP assumes there is congestion if it detects a packet loss A TCP sender can detect a packet loss via: Timeout of a retransmission timer Receipt of a duplicate ACK (receiver resends last ACK when it receives an out of order packet – i.e. rcvd Seq No. = Ack No. )

TCP Tahoe – Classic TCP Congestion is assumed if sender has timed-out or received a duplicate ACK Each time when congestion occurs, cwnd is reset to one: cwnd = 1 ssthresh is set to half the current size of the congestion window: ssthressh = [cwnd / 2] and slow-start is entered

Slow Start / Congestion Avoidance A typical plot of cwnd for a TCP connection (MSS = 1500 bytes) with TCP Tahoe:

TCP Error Control TCP Error Control

Go Back N Error Control It is a special case of the general sliding window protocol with a transmit (send) window size of N The sender transmits packets in its buffer up to the allowed value - Send window size = N Sender can transmit N frames to the receiver before receiving an ACK The receiver keeps track of the Seq. No. of the next packet it expects to receive, and sends that number (ACK No.) with every ACK packet it sends The receiver will discard any frame it receives that does not have the Seq. No it expects Receiver will resend the last ACK A 3 duplicate ACKs or a timeout will indicate to sender to go back and send all packets again starting from Seq. No = Ack No. of the last ACK it received from the receiver

Error Control in TCP TCP implements a variation of the Go-back-N retransmission scheme That means that if a packet is lost, all subsequent packets are dropped by the receiver -> sender has to retransmit all packets starting from “lost” packet The reception of each subsequent packet from the sender triggers the transmission of an ACK packet, with the ACKNo repeating the SeqNo. of the missing packet –> Duplicate ACKs (DUPAck) TCP Tahoe reacts after receiving the 3rd DUPAck by retransmitting that packet and all subsequent packets. TCP uses cumulative ACKs. Several received packets can be ACKed by one ACK by sending an ACKNo that corresponds to the last correctly received consecutive packet SACKS can be used to avoid transmitting correctly received data within a window.

Go-Back-N Illustrated Highest unACKed packet Start Timer for Packet 1 3 Duplicate ACKs ReStart Timer for Packet 4 Start Timer for Packet 4 A Packet 0 Packet 1 Packet 2 Packet 3 ACK 4 Packet 4 Packet 5 ACK 4 Packet 6 ACK 4 Packet 4 Packet 5 Packet 6 B Packets 5 and 6 are discarded (out of order packets not desired in buffer)

TCP Tahoe TCP couples error control and congestion control (i.e., it assumes that errors (losses) are caused by congestion) Two conditions will cause TCP to go into Slow Start Mode (from any state): A timeout occurs for a transmitted packet - causes a retransmission and go back to SLOW START mode When 3 DUPAcks are received TCP will assume packet is lost, retransmit and go back into SLOW START mode Note that when a packet is received by TCP and an error is detected the receiver will discard the packet and send a DUPAck repeating the last ACK No. it sent out. DUPAcks are also sent when packets are received out of order.

TCP Reno TCP allows accelerated retransmissions when you are in Congestion Avoidance Mode - Fast Retransmit If the sender receives 3 Duplicate ACKs it retransmits the assumed lost packet immediately. And accelerated recovery - Fast Recovery After a fast retransmit is sent, it goes into Fast Recovery Mode using (current CWND)/2 as new SSThresh and the new CWND = new SSThresh + 3 When in Fast Recovery mode: if a timeout occurs for retransmitted packet, you go into SLOW START mode with SSThresh = CWND/2, and CWND = 1. if you receive an ACK for retransmitted packet you go back into Congestion Avoidance mode with CWND = SSThresh

Retransmission Timer when Errors Occur First timeout timer for a packet is set to Estimated RTT The interval between retransmission attempts (subsequent timeout timers) increases with every failed retransmission (note these values are not used for RTT calculation. Time between retrans-missions is doubled each time (Exponential Backoff Algorithm) Timer is not increased beyond 64 TCP gives up after 13th attempt 1, 2, 4, 8, 16, 32, 64, 64, 64, 64, 64, 64, 64