Will we see QUIC in WebRTC?
Google just announced they want to make QUIC into an IETF standard.
What is QUIC?
To answer this one QUICkly, let’s put it into bullets:
- A transport protocol somewhere between UDP and TCP
- It is built on top of UDP, offering TCP-like capabilities
- It is designed to improve on TCP when running HTTP protocols on top of it
- It is modern
What does it improve over TCP (and TLS)?
- The initiation time to get a connection running is shorter. Think 0-RTT (no roundtrip of messages to connect – can’t do any faster than that)
- A modern congestion control mechanism, suitable to this day and age (TCP is broken in today’s network, at many times leading to bufferbloat)
Google’s intentions?
- Make the browser faster. By replacing TCP with QUIC, it can get better performance for the web
- This affects the time you wait when loading a page
- You will also have less nagging buffering incidents when watching videos
- The idea behind it is to wrap concepts and algorithms from QUIC back into TCP – or to replace TCP altogether. Not sure which, but my guess is that Google will be content with either option
Where does it fit in WebRTC?
Google indicated in June 2014 that QUIC is on their radar for WebRTC’s data channel. No additional update came about it since then.
There are two places where QUIC fits in WebRTC:
- In the signaling, which is out of scope of WebRTC, but interesting, as it enables faster connection of the initial call (theoretically at least)
- In the data channel, by replacing SCTP with QUIC wholesale
SCTP is what is used today by WebRTC’s data channel. It gets the job done, but it is an old protocol from around 2000. As such, it suffers from many of the same issues of TCP when it comes to congestion control – it just doesn’t factor in how our networks have changed (think larger memory buffers in routers, switches and operating systems; WiFi networks; LTE networks).
This means that theoretically, using SCTP won’t yield the best throughput from the network which can affect the performance of use cases such as P2P CDN. QUIC might be able to improve the situation there.
Why is this important?
- Google is religious about performance. While most of the focus when it comes to WebRTC was on media quality, adding QUIC into the mix can greatly improve the data channel
- There are now multiple WebRTC stacks out there – not just Google’s. The Google one is the one more important:
- Google use the same stack to run the WebRTC stack, Chrome’s WebRTC implementation and eventually Google Hangouts
- This means that if you adopt it, you are aligned with whatever happens with Chrome
- If you rely on the data channel for your use case, and you need more throughput, then QUIC is something to wait for
- This isn’t going to affect our lives in 2015, but it is something to keep an eye on
Wouldn’t say TCP is broken, devices in the network are broken.
QUIC does not fix bufferbloat. Bufferbloat also has bad effects on other protocols like VoIP and WebRTC. Probably even worse effect on those.
Bufferbloat can not be solved at the transport protocol layer.
Bufferbloat is a problem that exists on routers, modems, network-cards, the drivers for those networkcards and operating systems. It’s a problem of packet scheduling.
And the problem is fixed, a lot of vendors now have newer implementations, it just takes a lot of time before it is deployed.
The problem with TCP is it is harder to update and experiment at scale, because TCP is part of the operating systems. QUIC is a protocol implemented in userspace part of a piece of software which frequently gets updates. Basically TCP isn’t Agile. 😉
The biggest reason why QUIC is faster in my opinion is because it does not use standard TLS (the newer version of SSL). Lots and lots of servers on the Internet only support old versions of SSL/TLS probably old TCP-versions even more.
Because QUIC runs over UDP and is a userspace implementation it can experiment much quicker with newer TLS-like and TCP-like streams.
The reason why SCTP for WebRTC datachannels is slow is because it hasn’t had any experimentation yet. They just wanted something they can deploy. Even though the SCTP implementation is a userspace implementation and runs over UDP and DTLS.
New versions of TCP and SSL/TLS protocols and extensions are created just not widely deployed. Organizations like Google wants the whole web to be fast, not just Google websites.
For example TCP fast open which is in the Linux kernel is pretty widely deployed in servers. But Windows doesn’t support it I believe. So browsers on Windows clients won’t benefit from it.
QUIC also has network encoding. Something which the IETF has been wanting to add to TCP for a number of years now but they haven’t seen a way to do that which can be widely deployed because of backward compatibility.
It is the same reason why SCTP at the transport layer did not get widely deployed because on the Internet there are to many old systems (in case of SCTP especially middleboxes) which just won’t support it anytime soon and which is worse even block it.
Lennie,
Thanks for the clarifications – as always – your inputs here are extremely helpful.
I stand corrected.
And I can’t see who was so helpful because of the horribly oversized avatars on mobile version of site 🙁
Brian,
Thanks for the feedback – I’ll get it fixed in the next week or two.
SCTP throughput is actually not that bad (>100mbit/s have been reported, depends on the RTT though; see https://code.google.com/p/webrtc/issues/detail?id=2276#c27)
QUIC won’t be able to play its big advantage, fast connection establishment, when run ontop of ICE. Whether it’s faster than the DTLS handshake… remains to be seen.
I suppose we’ll see google experiment with this using a proprietary peerconnection constraint.
Yap. I think the main difference between SCTP and QUIC will be when the connection isn’t clear or static – there QUIC will probably adapt better to the network conditions.