Audio Global Viewpoint – July 2021
QUIC Internet For Broadcasting
TCP has been the backbone of reliable IP delivery since the late 1970s but after years of research, we seem to have reached the limits of its abilities. QUIC is being hailed as a large-scale replacement for TCP. But why is QUIC so important and what can it do for broadcasters?
Packet loss is inevitable in any IP network and TCP goes a long way to maintaining reliable delivery, but it does so at the expense of time variant latency. When we dig into the detail of TCP, we see that it presents us with many challenges for video and audio streaming. One solution is to dispense with it entirely and distribute streamed video and audio using UDP. As there is no error correction, UDPs latency is limited to the transmission and switching delays in the network.
QUIC was designed by Google in 2012 as an experimental transport stream to fix some of the niggles with TCP. These include providing efficient connection establishment and reduced latency, flexible congestion control, forward error correction and authenticated and encrypted header and payload. Most interesting for broadcasters, QUIC uses UDP.
Thinking in internet terms, QUIC can be seen as a replacement for the TCP/TLS/HTTP2 stack. Although TCP/TLS/HTTP2 are the protocols used by internet web clients and servers, they are also the building blocks of video and audio streaming over the internet. This includes OTT but is not limited to it.
In 2016, the Internet Engineering Task Force (IETF) formed a working group to further develop QUIC and in May 2021 released RFC 9000 – A UDP-Based Multiplexed and Secure Transport.
Google have already implemented QUIC into their Chrome browser and Akamai introduced it in 2016. Many applications including YouTube, Uber and Facebook have either already adopted or are migrating to it.
Security becomes an intrinsic component within the QUIC protocol through the adoption of TLS. Providing encryption and authentication, TLS guarantees that the data in transit has not been tampered with and if copied cannot be decoded without the necessary keys.
Connection speeds are greatly improved by replacement of TCPs three-way handshake and a flexible approach to packet resend has been adopted to reduce needless packet duplication.
Although HTTP/2 succeeded in solving the head-of-line blocking for web pages, it only moved the problem further down the stack to the TCP transport layer. QUIC, along with HTTP/3 has now solved this through transport stream aware binary stream multiplexing. Unlike TCP, QUIC resends only lost packets within the context of the binary stream, thus removing head-of-line blocking from the transport layer. This could be a major bonus for streaming live video and audio.
QUIC sounds like a significant win for broadcasters. An open standard backed by the IETF is becoming available that is natively supported by web browsers, servers, and the internet infrastructure. QUIC promises low latency, security and throughput optimization with forward error correction and multiplexing.
Using QUIC, streaming live video and audio between cameras and production switchers, or OBs and broadcast centers, with the right applications, could become as simple as opening an internet browser.