Quick UDP Internet Connections (QUIC) has been approved by the Internet Engineering Taskforce (IETF), graduating from an eight-year development process to a certified standard – RFC 9000. Promising more efficient networking, the new protocols sound like a boon for the video industry, which is grappling with how to reduce latency in streaming video applications.
Currently, new transport protocols SRT and RIST look like the best remedy to that problem. Essentially, they use the ‘fire and forget’ UDP protocol as the basis, and then add some improvements on top, rather than deal with the latency that gets added when using TCP – where individual connections have to be established and reconfirmed continuously.
Google began experimenting with QUIC in 2013, after developing it in-house, describing it as an early-stage network protocol that runs a stream multiplexing protocol over a new flavor of Transport Layer Security (TLS) on top of UDP instead of TCP.
Put simply, QUIC promises to reduce the overhead of TCP, which should reduce latency and the amount of data that needs to flow between devices to maintain the connection. As well as Google Cloud Platform, Cloudflare implemented QUIC recently, and says that around 12% of internet traffic is using QUIC with HTTP/3. In May 2020, W3Techs believed that between 3% to 4% of traffic was using it, so Cloudflare’s data suggests decent adoption.
In what looks like an annoying fragmentary move, Microsoft developed its own version, called MsQuic, and open-sourced it last year. Microsoft has been using MsQuic to carry its Server Message Block (SMB) traffic, arguing that SMB over QUIC is the future of distributed systems, and enables use cases in edge computing and mobile devices that are just not possible over TCP. That’s more enterprise-focused than Faultline typically covers, but of course, the rise of OTT has come hand-in-hand with the migration from on-prem to cloud.
Cloudflare is now offering QUIC to all customers, using its own open source implementation called quiche, graduating it from beta previews last week, and the protocol has been available in the Chrome browser since January 2021. Given Google’s control over the Android ecosystem, we would expect QUIC to shortly appear in smartphones and the plethora of Android TV set tops and smart TVs too.
This would quickly give video developers a viable footprint to test SRT and RIST over QUIC, but the industry might have to smooth over some privacy concerns that have appeared. A group of Chinese researchers published a paper outlining how QUIC has “extreme vulnerability” to web fingerprinting (WFP) attacks, which would betray user identities and enable data intercept and extraction. HTTPS performs better, but it sounds like these concerns could be addressed by future work on the QUIC protocol.
“The superior transmission performance of the QUIC protocol brings opportunities for speeding up the internet, but its security risks bring uncertainties. The vulnerability of QUIC on early traffic poses a significant challenge to the privacy and confidentiality guaranteed,” they noted.
At this point, it is worth dusting off the tinfoil hat, and noting that Google seems to have shot itself in the foot here. It has had plenty of time to work on privacy features, and has done itself no favors in releasing a protocol that its opponents are going to say cedes more data collection capabilities to the firm that seems to have abandoned its ‘Don’t Be Evil’ mantra, in recent years.
A pragmatic Googler would, however, probably note that it doesn’t have to rely on QUIC to do such things, if you were using a Google account or Chrome already. Also, QUIC requires that TLS is implemented from the get-go, while TCP will happily chug along without any additional security layers on top.
There has not been much movement on the SRT and RIST front when it comes to QUIC. By the looks of things, QUIC cannot be a direct replacement for either transport protocol, but there are also concerns about how well a UDP stream will share network resources with regular TCP traffic. Excellent live video quality is nice, but not if it comes at the expense of the apps you are second-screening.
The established RDP protocol can also be added to the mix, which would bring multicast capabilities to the QUIC streams too. For some video applications, predominantly VoD we suspect, QUIC will be plenty good enough to deliver streams to clients. For the live video, where low latency is the main priority, we suspect that SRT and RIST (or whatever they might merge into) are going to provide better KPIs than QUIC, as they have been crafted specifically for the live video use case.
Cloudflare’s announcement does describe QUIC in some more technical detail. Cloudflare servers monitor port 443 for UDP traffic, looking for the initial QUIC packets that the clients send – which kicks off the handshake process, and ensures that the process is a bit more sophisticated than UDP’s usual ‘screaming into the void unacknowledged’ approach.
The TLS Application Layer Negotiation Protocol (ALNP) provides the list of available application protocols that the client understands, as there are already a few different versions of QUIC in the wild. HTTP Alternative Services (RFC 7838) is the mechanism used to make sure that a client knows that the server supports QUIC, which is the same used in web browsers, where you would tell a TCP client that the server supports HTTP/3. Cloudflare summarizes by speculating on what will follow QUIC, saying that work is already underway on QUIC 2.