Brian,

Thanks for the feedback – I’ll get it fixed in the next week or two.

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.

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.

And I can’t see who was so helpful because of the horribly oversized avatars on mobile version of site 🙁

Lennie,

Thanks for the clarifications – as always – your inputs here are extremely helpful.

I stand corrected.

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.