Everything you Wanted to know about QUIC as a WebRTC Data Channel Transport

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:

1. A transport protocol somewhere between UDP and TCP
2. It is built on top of UDP, offering TCP-like capabilities
3. It is designed to improve on TCP when running HTTP protocols on top of it
4. It is modern

What does it improve over TCP (and TLS)?

1. 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)
2. 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:

1. In the signaling, which is out of scope of WebRTC, but interesting, as it enables faster connection of the initial call (theoretically at least)
2. 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