gen-briefly-explain-tcp-congestion-control-and-one-common-miscon-6eb2

Briefly explain TCP congestion control and one common misconception about it.

# TCP Congestion Control **Brief Explanation:** TCP congestion control prevents network overload by dynamically adjusting the sending rate based on network conditions. It uses several mechanisms: - **Slow Start**: Begins with a small congestion window and doubles it each round-trip time until a threshold is reached - **Congestion Avoidance**: Increases the window linearly after the threshold - **Fast Retransmit/Recovery**: Detects and responds to packet loss through duplicate ACKs - **Multiplicative Decrease**: Cuts the window size (typically in half) when congestion is detected The sender infers congestion primarily through **packet loss** (timeout or duplicate ACKs) and adjusts its transmission rate accordingly. ## Common Misconception **"TCP congestion control detects network congestion directly"** In reality, TCP doesn't directly measure network congestion. It **infers** congestion indirectly through packet loss or (in modern variants like BBR) increased delay. This is a crucial distinction because: - Packet loss can occur for reasons other than congestion (wireless interference, bit errors) - By the time loss is detected, congestion has already occurred - This reactive approach means TCP is always "probing" for available bandwidth rather than knowing it precisely This limitation has led to the development of newer algorithms that use additional signals like latency to better estimate congestion before loss occurs.