Chapter 6 TCP Congestion Control Networking CS 3470, Section 1

TCP Congestion Control TCP congestion control introduced into the Internet in the late 1980s Roughly eight years after the TCP/IP protocol stack had become operational

TCP Congestion Control Immediately preceding late 1980s, the Internet was suffering from congestion collapse— hosts would send their packets into the Internet as fast as the advertised window would allow congestion would occur at some router (causing drops) and the hosts would time out and retransmit their packets, resulting in even more congestion

TCP Congestion Control Informally: “too many sources sending too much data too fast for network to handle” Different from flow control! Manifestations: Lost packets (buffer overflow at routers) Long delays (queueing in router buffers) a top-10 problem!

TCP Congestion Control A Congestion Window called CongWin is used by the source to limit how much data it is allowed to have in transit at a given time. The congestion window is congestion control’s counterpart to flow control’s advertised window.

TCP Congestion Control Once a given source has CongWin packets in transit, an ACK arrival signals that one of its packets has left the network Then it is safe to insert a new packet into the network without adding to the level of congestion By using ACKs to pace the transmission of packets, TCP is said to be self-clocking.

TCP Congestion Control We now modify TCP’s effective window MaxWindow = MIN(CongestionWindow, AdvertisedWindow) EffectiveWindow = MaxWindow − (LastByteSent − LastByteAcked) That is, MaxWindow replaces AdvertisedWindow in the calculation of EffectiveWindow.

TCP Congestion Control If CongWin < AdvertisedWindow, then the rate of the connection is CongWin is dynamic, function of perceived network congestion rate = CongWin RTT Bytes/sec

TCP Congestion Control Great, so how does the sender perceive congestion? Loss event = timeout or 3 duplicate ACKs TCP sender reduces rate (CongWin) after loss event

TCP Congestion Control Three mechanisms make up TCP congestion control: Additive Increase/Multiplicative Decrease (AIMD) Slow Start Fast Retransmit and Fast Recovery

TCP AIMD Multiplicative Decrease: Additive increase: Cut CongWin in half after loss event Additive increase: Increase CongWin by 1 MSS every RTT in the absence of loss events: probing Long-lived TCP connection

TCP AIMD Packets in transit during additive increase, with one packet being added each RTT.

Starting data transfer Should TCP just starting blasting away at the EffectiveWindow pace on each new connection? Probably not…we don’t know how congested the network is But we don’t want to take forever to get up to a good pace…

TCP Slow Start When connection begins, CongWin = 1MSS Example: MSS=500 bytes and RTT = 200 msec Initial rate = 20 Kbps Available bandwidth may be much greater than MSS/RTT Desirable to quickly ramp up to respectable rate When connection begins, increase rate exponentially fast until first loss event

TCP Slow Start (more) When connection begins, increase rate exponentially until first loss event: double CongWin every RTT done by incrementing CongWin for every ACK received Summary: initial rate is slow but ramps up exponentially fast Host A Host B one segment RTT two segments four segments time

Fast Recovery After 3 dup ACKs: But after timeout event: Philosophy: 3 dup ACKs indicates network capable of delivering some segments timeout before 3 dup ACKs is “more alarming” After 3 dup ACKs: CongWin is cut in half window then grows linearly But after timeout event: CongWin instead set to 1 MSS; window then grows exponentially to a threshold, then grows linearly

Fast Recovery Q: When should the exponential increase switch to linear? A: When CongWin gets to 1/2 of its value before timeout. Implementation: Variable Threshold At loss event, Threshold is set to 1/2 of CongWin just before loss event Congestion window

Summary: TCP Congestion Control When CongWin is below Threshold, sender in slow- start phase, window grows exponentially. When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly. When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold. When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

TCP sender congestion control CongWin and Threshold not changed Increment duplicate ACK count for segment being acked SS or CA Duplicate ACK Enter slow start Threshold = CongWin/2, CongWin = 1 MSS, Set state to “Slow Start” Timeout Fast recovery, implementing multiplicative decrease. CongWin will not drop below 1 MSS. CongWin = Threshold, Set state to “Congestion Avoidance” Loss event detected by triple duplicate ACK Additive increase, resulting in increase of CongWin by 1 MSS every RTT CongWin = CongWin+MSS * (MSS/CongWin) Congestion Avoidance (CA) ACK receipt for previously unacked data Resulting in a doubling of CongWin every RTT CongWin = CongWin + MSS, If (CongWin > Threshold) set state to “Congestion Avoidance” Slow Start (SS) Commentary TCP Sender Action State Event

TCP throughput What’s the average throughput of TCP as a function of window size and RTT? Ignore slow start – these phases are typically short Let W be the window size right before loss occurs. When window is W, throughput is W/RTT So fast, but cannot last Just after loss, window drops to W/2, throughput to W/2RTT. Average throughput: .75 W/RTT

TCP Fairness Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K TCP connection 1 bottleneck router capacity R TCP connection 2

Why is TCP fair? Two competing sessions: Additive increase gives slope of 1, as throughput increases multiplicative decrease decreases throughput proportionally Connection 2 throughput R equal bandwidth share loss: decrease window by factor of 2 congestion avoidance: additive increase loss: decrease window by factor of 2 congestion avoidance: additive increase Connection 1 throughput R Assumptions: same MSS and RTT, nothing else using link

Fairness (more) Fairness and UDP Multimedia apps often do not use TCP do not want rate throttled by congestion control Instead use UDP: pump audio/video at constant rate, tolerate packet loss Research area: congestion control for UDP Fairness and parallel TCP connections nothing prevents app from opening parallel connections between 2 hosts. Web browsers do this Example: link of rate R supporting 9 connections; new app asks for 1 TCP, gets rate R/10 new app asks for 11 TCPs, gets R/2 !