In real-time broadcast systems, latency spikes matter more than average throughput. Head-of-line (HoL) blocking is one of the hidden mechanisms that turns a small packet loss into a visible glitch.

To understand HoL blocking, we first need to examine why it occurs in TCP and what that means in practice. TCP enforces reliable, in-order delivery, and it is this strict ordering that creates HoL behavior when packets are lost. In broadcast environments, TCP is typically used where latency constraints are less critical, such as OTT. However, within the studio where real-time media transport is latency sensitive, UDP is generally employed.

TCP guarantees reliable, in-order delivery of a continuous byte stream. If a data packet is lost, then all subsequent data, even if received correctly, must wait in the receive buffer until the missing IP packet is retransmitted. The result is not just a lost packet, but a stall in the data throughput as a single loss can momentarily freeze the entire data transfer. The TCP protocol occurs at the data layer, but the application itself pays a huge price for this disruption.

It’s worth remembering that TCP/IP was designed to provide reliable generic data transfer found in IT type applications, such as file transfer and web page access. In such use-cases, increased and even non-deterministic latency are a small price to pay for data integrity. But in real-time systems, such as video and audio streaming, data integrity and deterministic latency are not only needed, but are a fundamental requirement of the system.

Global Blocking

When a TCP connection carries multiplexed services, such as video, audio, and metadata, one lost packet can stall everything sharing that connection. The blocking is therefore global because the TCP layer presents the application with one ordered stream. It cannot send only part of the stream with the expectation that any lost packets will magically appear, the protocol literally stops sending the stream to the application layer until the lost packets have been resent.

This is one of the reasons that RIST and SRT have been developed, as they help reduce the effects of HoL, albeit with some caveats.

It’s not unreasonable to assume that UDP streams, such as SMPTE’s ST 2110, do not suffer from HoL. In principle, this is correct because at the transport layer, UDP does not enforce ordering and does not retransmit. A lost packet stays lost and the stream continues, but there will be some video or audio distortion and although there is no transport-level HoL blocking, the system-level effects can still manifest themselves in ways that look remarkably similar.

ST 2110 receivers use buffers to iron out packet jitter caused by network routing and effectively absorb the packet delivery time variation to reconstruct time-aligned streaming from the RTP sequence numbers and PTP timestamps. When packets arrive out of sequence or late due to congestion or switch buffering, the receiver must decide whether to wait, conceal, or drop the packet. Excessive delay can cause buffer under-run resulting in the decoder receiver being starved of packets and manifesting as video and audio distortion. Although this is not TCP-type HoL blocking, the result is comparable: a small disturbance upstream can have a devastating impact downstream.

A Crucial Distinction

The important difference is that TCP creates blocking through enforced ordering, whereas ST 2110 infrastructures can experience disturbances through buffer coupling and timing recovery mechanisms. In both cases, a minor packet loss can propagate through the whole system, and in real-time video and audio infrastructures this can have a significant and detrimental impact on the viewing experience.

Quick UDP Internet Connections (QUIC) were first developed by Google in 2012 to reduce web latency by reducing transport HoL blocking along with slow connection setup. It was later standardized by the IETF who adopted the name QUIC, and it is now a fully standardized transport protocol that forms the basis of HTTP/3.

Instead of modifying TCP, QUIC moves the data integrity, congestion control and encryption into the user space (application layer) and operates over UDP. The underlying network still sees UDP datagrams, but protocols associated with TCP, such as guaranteed packet delivery, are implemented inside the application.

TCP lives in the operating system kernel meaning that changes to the protocol are slow to implement and behavior is largely fixed as the OS needs updating each time the TCP protocol is modified. 

As QUIC runs in user space, and hence the application layer, browsers, media services, or streaming platforms can update the transport stack independently of the OS. New congestion control algorithms can be implemented more quickly, and bug fixes and performance improvements don’t need major OS upgrades and kernel changes.

Fine-grained control over the protocol can be implemented by the application which provides major benefits over TCP. From an application perspective, TCP does not know or care what type of data it is transferring; it could be a file, web page or media segment. QUIC allows and encourages the application to tweak the protocol parameters to work more efficiently with the needs of the specific data it is transferring. The deterministic latency requirements of real-time streamed media are completely different to those of file transfer.

Multiplexing

Core to the operation of QUIC is that instead of presenting the application with one ordered by stream, as found with TCP, QUIC allows multiple and independent streams to coexist within the same connection. Each stream has its own sequencing and flow control so that if a packet is lost from Stream A, then only Stream A is affected. Stream B and Stream C continue delivering data without waiting for the retransmission of Stream A’s missing packet. This eliminates cross-stream HoL blocking. 

QUIC further improves the establishment of connections as it requires only a single handshake to establish both the connection and encrypted TLS layer. This is much faster than the TCP protocol as it requires a three-way handshake to determine the original connection, and then another three-way handshake to establish the encrypted layer.

It’s important to note that QUIC is not a replacement for RTP-based live transport protocols such as ST2110 as the UDP infrastructure already avoids HoL blocking (with the caveat that application-level blocking can still occur). Where QUIC excels for broadcasters is in OTT, segment-based streaming and microservice control.

Originally, browsers and web players used HTTP/2 over TCP to deliver streamed media to viewers. However, these suffered from cross-stream HoL blocking, where a lost packet could stall multiple multiplexed streams when played. QUIC underpins HTTP/3 and reduces these stalls as well as providing much faster recovery from lost packets, thus providing the viewer with a much improved viewing experience.

Another area where broadcasters can benefit from using QUIC is in cloud and distributed workflows. These services often use shared WANs and rely on TCP, and a single packet loss can cause HoL blocking for multiple concurrent transactions. The stream isolation method that QUIC has adopted reduces the possibility of traffic being delayed due to unrelated disturbances in other traffic flows. In hybrid on-prem/cloud architectures, where round-trip times are higher and packet loss is less predictable, QUIC can significantly improve responsiveness and failure containment.

Although SRT and RIST provide reliable and latency-determinate delivery over UDP, they are optimized for continuous media streams. QUIC addresses a slightly different class of problems; multiplexed service traffic, file transfer, API-heavy workflows, and secure media services being delivered to viewers.

A Realistic Alternative

As broadcasters are increasingly deploying microservices and cloud native infrastructures, QUIC provides more reliable and lower latency control than its TCP predecessor.

Broadcasters need to think more about QUIC as media systems increasingly operate outside the strict controlled environment of a broadcast studio facility. Workflows are continuing to extend to both public and private clouds, public internet contribution, OTT delivery and API-driven control systems. TCP’s inherent HoL blocking and handshake latency is becoming increasingly visible, and QUIC reduces cross-stream blocking, improves the establishment of connection setup times, and contains losses within sub-streams of a connection. It’s not a replacement for ST 2110 flows but is highly relevant for OTT over HTTP/3, cloud-native broadcast services, control-plane traffic, microservices and internet-facing media platforms.