A constraint on a shared path

Links and routers have finite capacity shared by multiple flows. Sustained excess load increases queues and loss, while retransmissions can consume still more capacity.

Congestion control limits network load; receiver windows constrain endpoint capacity. Spare receive-buffer space does not prove that the intervening path is uncongested, and both limits can apply together.

References: [1] [2]

Feedback and data in flight

TCP’s congestion window bounds outstanding data, with classical mechanisms including slow start, avoidance and recovery. The sender reacts to acknowledgments, loss and timeouts rather than knowing every router’s spare capacity.

QUIC also defines loss detection and congestion control, with different packet numbering and acknowledgment organization. Carrying traffic over UDP does not remove congestion-control responsibilities.

Loss is not the only congestion signal. In classic negotiated ECN, a router can mark an ECN-capable packet CE and forward it; the TCP receiver echoes the indication with ECE, the sender reacts to congestion and signals that reaction with CWR. This can report congestion without dropping that packet, not guarantee a loss-free path or authorize unchanged sending. It is RFC 3168’s classic TCP mechanism rather than a description of every later ECN feedback extension.

References: [2] [4] [5]

Several algorithm families

CUBIC uses cubic window growth; RFC 9438 standardizes the algorithm with implementation and research experience and updates relevant RFC 5681 behavior. Classical linear growth does not describe every current TCP controller.

Peak speed on an otherwise idle link is not the only criterion. Stability and sharing under changing delay, competing traffic or loss also matter; congestion control does not promise each application fixed bandwidth or deadlines.

References: [1] [3]