A live-streaming platform ingests video from broadcasters on consumer uplinks where a single lost packet can stall the stream. Why does TCP behave badly here, and what are the options?

Why TCP behaves badly

Head-of-line blocking. TCP guarantees in-order delivery, so a lost packet stalls everything behind it until the retransmission arrives. For a live stream that is exactly the wrong trade: the retransmitted frame arrives too late to be shown, and meanwhile the frames that did arrive were held back waiting for it.

Congestion control misreads wireless loss. Classic loss-based congestion control interprets packet loss as congestion and halves the sending rate. On a wireless uplink, loss is frequently caused by radio interference rather than by a full queue, so the algorithm reduces throughput in response to a condition more bandwidth would not have caused.

Bufferbloat. Oversized buffers in home routers and carrier equipment mean loss-based control keeps increasing the rate until buffers are full, adding seconds of latency before it ever detects congestion. The stream is delivered reliably and far too late.

Retransmission of stale data. TCP will faithfully retransmit a frame from four seconds ago that nothing can use, consuming uplink capacity that the current frame needs.

The options

1. Latency-sensitive congestion control. Algorithms that model bandwidth and round-trip time rather than treating loss as the only congestion signal behave far better on lossy wireless links, and avoid filling buffers. This is the cheapest meaningful improvement, since it is a server and client configuration change rather than a protocol change.

2. A UDP-based transport with application-level reliability. The important property is selective reliability: retransmit what still matters, drop what has expired. This is what protocols built on QUIC or SRT provide, and it directly addresses the two worst behaviours — head-of-line blocking and stale retransmission.

3. Forward error correction. Send redundant data so moderate loss is recoverable without any retransmission. Costs bandwidth continuously; buys latency-free recovery. The right trade when the uplink has headroom and the round trip is long.

4. Adaptive bitrate on the ingest side. The broadcaster's encoder reduces bitrate when the uplink degrades. This is the highest-leverage control, because it addresses the cause rather than the symptom — and it needs an accurate, fast signal of available bandwidth to act on.

5. Ingest points close to broadcasters. A shorter round trip makes every recovery mechanism faster and every congestion signal more timely.

The design principle worth stating

For real-time media, reliability and timeliness are in direct conflict, and timeliness usually wins. A frame delivered late is worse than a frame not delivered, because it consumed capacity and delayed everything behind it.

TCP is built on the opposite assumption — that every byte matters and delay is preferable to loss — which is correct for file transfer and wrong for live video. That is the whole reason real-time media protocols exist and why the industry moved toward UDP-based transports for this workload.