TCP fairness

When several people share one buffet table, we have a rough sense of fairness: nobody should hog the whole spread while others go hungry. On a shared network link, TCP fairness is the same idea applied to bandwidth: if several TCP connections compete for one bottleneck link, each should end up with roughly an equal share of it, without any central referee handing out portions.

Where does this fairness come from? It falls out of AIMD. Suppose two flows share a link. Each grows its window additively, the link fills, both lose a packet, and each halves its window. The flow that was using MORE bandwidth loses more in absolute terms on the cut, while both gain the same small amount on each increase — so over many sawtooth cycles the two windows drift toward equality. A standard way to picture this is a graph of flow-1's rate against flow-2's rate: AIMD pushes any starting point toward the fair, equal-split line. The result is approximate, not perfect, equality. There is even a rough TCP throughput equation showing that a flow's average rate is proportional to 1 divided by (RTT times the square root of the loss rate), which captures how throughput depends on round-trip time and packet loss.

Three honest caveats make this real rather than idealised. First, fairness depends on RTT: that throughput equation has RTT in the denominator, so a flow with a shorter round trip grabs MORE than its 'fair' share — flows are equal only if their RTTs are equal. Second, an application can simply open many parallel TCP connections (browsers and download managers do) and collectively claim several shares. Third, fairness is only enforced by everyone choosing to run a well-behaved, AIMD-style controller; a flow using a more aggressive algorithm, or none at all, can starve the polite ones. 'TCP-friendly' is the term for a non-TCP flow (say, a video app over UDP) that voluntarily limits itself to roughly what a TCP flow would take, so as not to be a bully.