congestion avoidance
Once you have found roughly where the wall is in that dark room, you stop doubling your stride and start inching forward instead — one careful small step at a time, because now a wrong move means a bruised shin. Congestion avoidance is TCP's careful-stepping phase: after slow start has rapidly found the neighbourhood of the network's capacity, TCP switches to growing its window slowly and linearly, gently probing for just a little more bandwidth without rushing into a jam.
The switch happens when the congestion window reaches the slow-start threshold (ssthresh). From then on, instead of doubling the window every round trip, TCP adds only about one packet's worth per round trip — this is the additive-increase half of AIMD. It is a slow, linear climb. When a loss eventually signals congestion, TCP performs the multiplicative decrease (classic TCP halves the window) and sets ssthresh to the new, lower window, so it knows roughly where the ceiling is for next time. The result, repeated, is the TCP sawtooth: a sharp slow-start ramp once, then endless gentle climbs and halvings around the true capacity.
The two phases divide labour neatly. Slow start exists to find the right ballpark fast, from a standing start; congestion avoidance exists to live there sustainably, tracking the capacity as it slowly drifts (other flows come and go) without provoking the heavy losses that aggressive probing would cause. Most of a long-lived connection's life — a big file transfer, a long video stream — is spent in congestion avoidance, sawtoothing quietly just below the link's limit.
After slow start ends at ssthresh = 64 packets, congestion avoidance takes over: the window grows 64, 65, 66, 67 ... one packet per round trip. At 80 a loss occurs; TCP halves to 40 and sets ssthresh = 40, then linearly climbs 40, 41, 42 ... again. Compare with slow start, which would have doubled to 128 in a single step.
Above ssthresh, TCP adds one packet per RTT — the slow linear probing that keeps a steady connection near capacity.
Linear additive increase is painfully slow on very fast, long-distance links: a single +1-packet-per-RTT climb can take minutes to refill a high bandwidth-delay-product path after one loss. That sluggishness is precisely why CUBIC (whose window grows as a cubic curve) replaced plain linear growth as Linux's default.