Data Centre


Google's 'QUIC' TCP alternative slow to excite anyone outside Google

Multiplexing-over-UDP idea has hit the standards track, but is mostly ignored

By Richard Chirgwin


Google's contribution to Internet standards, the fast-than-TCP thanks to multiplexing QUIC protocol, has yet to extend much beyond the Chocolate Factory, according to a German report into its adoption.

An experiment from 2012, Google's Quick UDP Internet Connections hit the internet standards track with this draft, and an IETF working group was established in 2016. It has yet to progress to an official standard, and remains proposed at this time.

Jan Rüth and Oliver Hohlfeld (RWTH Aachen University), Ingmar Poese (German analytics company Benocs), and Christoph Dietzel (Technical University, Berlin) probed the internet to count QUIC-enabled servers, and analysed traffic to work out just how much QUIC traffic exists.

While there are more than 600,000 QUIC-capable IP addresses found, it seems sysadmins are still learning how it works, since there are only 161,000 domains hosted on QUIC-capable infrastructure, and of those, only 15,000 presented valid certificates over QUIC. Not bad for something that is yet to become an official internet standard, but also not a great show of enthusiasm.

“Overall QUIC support is very low,” they wrote in their paper, dated Tuesday. “Depending on the zone, 0.06 per cent – 0.1 per cent [of] domains are hosted on QUIC-enabled hosts. Only 1.6 per cent – 2.44 per cent of these domains present a valid X509 certificate”.

Hosts were scanned using Zmap to send queries to servers, which answered with their QUIC version identifiers (if it was enabled). As well as enumerating infrastructure that supports the protocol, the researchers also saw just how much development is going on – indicated by a huge diversity of responses from servers.

That also explained one reason adoption is spotty in the wild: “QUIC is currently subject to rapid development reflected in frequent version updates”, the boffins wrote, and in some cases, “some versions introduce radical protocol changes without backward compatibility”, which doesn't help the long-term stability of the protocol.

QUIC accounted for between 2.6 per cent and 9.1 per cent of traffic, the paper said, and even that rather small proportion is boosted by Google: “This share is dominated by Google pushing up to 42.1 per cent of its traffic via QUIC”, the report said.

To reach this conclusion, the researchers took traffic statistics from three sources: a year of traffic from the Japanese-led MAWI (Measurement and Analysis of the Wide-area Internet) project, one ISP's one-day traffic stats, and one Internet exchange point's one-day stats.

The researchers noted that where measurements are made matters: “We observe different QUIC traffic shares at the ISP/IXP and particularly different shares of the QUIC traffic by Google / Akamai (relative to the overall traffic of each vantage point). These vantage point dependent differences are likely caused by different traffic engineering strategies since both providers peer at both vantage points … Understanding the incentives for these different traffic engineering strategies is an interesting starting point for future research.” ®

Sign up to our NewsletterGet IT in your inbox daily


More from The Register

Net's druids thrash out specs for an independent IETF

This matters because right now there's no formal structure, which makes things tenuous

Cisco and AWS hop into bed for steamy hybrid Kubernetes action

Mixing up on-premises and cloudy containers

Cisco and Pure shove mini AI in FlashStack converged systems

Entry-level AIRI equivalent

Penguins in a sandbox: Google nudges Linux apps toward Chrome OS

While keeping things safe

IETF wants packets to prove where they've been, to improve trust

Virtualisation is creating traffic handoffs that don't depend on physical ports

Oi! Not encrypting RPC traffic? IETF bods would like to change that

RPC over TLS: You know it makes sense

IETF mulls adding geoblock info to 'Bradbury's code'

Proposal to extend Error 451

Tasty news bytes from networking land: Route security, Cisco cert death, ETSI and more

Roundup Oh, and IETF standards got sloshed this week

Oops: Cisco accidentally leaked in-house Dirty COW exploit code with biz conf call software

Critical bugs patched in switches, messaging, analytics

Updating Things: IETF bods suggest standard

Proposal offers proper authentication, verification and over-the-air delivery