QUIC – Next-generation multiplex transport over UDP

https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present?slide=id.g176a9a2e9_0143

by digitalnalogika • 12 years ago

67 25 12 years ago

docs.google.com

bodski• 12 years ago

Video of interview/talk: http://www.youtube.com/watch?v=hQZ-0mXFmk8

crazygringo• 12 years ago

Wait, so how do I enable it on Chrome? I've gone to:

chrome://net-internals/#quic

like the slide says, but Chrome just says "QUIC Enabled: false" without any switch to turn it on. (Chrome 32 on OSX.)

Edit: turns out the answer is to go to chrome://flags/#enable-quic

Also, what web servers support QUIC? Is there some kind of Apache add-on in development? And how will Chrome know whether to try to connect via QUIC or not? If QUIC gets enabled in my Chrome, does this mean Chrome tries to establish both a QUIC and TCP connection to each server always?

virtue3• 12 years ago

you need the chrome canary build.

https://www.google.com/intl/en/chrome/browser/canary.html

rjshade3• 12 years ago

And how will Chrome know whether to try to connect via QUIC or not?

Chrome looks for the "alternate-protocol:443:quic" response header (in non-QUIC requests). Once it sees this it will attempt to talk QUIC in future requests to the same domain.

And thanks for pointing out the omission of chrome://flags/#enable-quic in the slides. Have fixed this.

loganfsmyth• 12 years ago

The protocol is still in prototype development, so there is no general server support yet. At least some of Google's severs have it enabled though.

signa112• 12 years ago

although slightly alluded to in the 'parking lot problem' i dont see any reference to mptcp. any reason why ?

edit-1: quic geek faq contains some more details (https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...)

wmf4• 12 years ago

MPTCP doesn't solve the problems that QUIC cares about and OSes don't support it anyway.

signa112• 12 years ago

hmm, linux-kernel does seem to have some implementation as outlined here: http://www.multipath-tcp.org/

also, may you please elaborate on your statement above ? thanks !

nasalgoat• 12 years ago

Are there any libraries and/or demo code to implement this?

rjshade3• 12 years ago

QUIC is in the Chromium source:

https://code.google.com/p/chromium/codesearch#chromium/src/n...

and there's a demo server here:

https://code.google.com/p/chromium/codesearch#chromium/src/n...

yjh0502• 12 years ago

How about SCTP? It also supports multimple streams on single connection, no head-of-line blocking, multihoming, and in standard.

danellis3• 12 years ago

Although there are libraries that run it over UDP, SCTP is really a genuine layer 4 protocol, which means that it needs to be implemented in the OS and supported by NAT gateways. QUIC is intended to always go over UDP, so it can be implemented in userland with easy updates.

wmf4• 12 years ago

Doing a SCTP four-way handshake and then a TLS handshake is going to be pretty high latency.

zurn• 12 years ago

SCTP deployment stalled when NAT boxes took over the internet. Also it was originally from the telco world and didn't have a lot of cheerleaders among internet applications people.

There's now an incarnation tunneled over UDP that's used in WebRTC. But tunneling rtp on dtls on sctp on udp sounds like a real protocol christmas tree...

AndrewDucker• 12 years ago

No MS support...

danellis3• 12 years ago

Where is the spec for this?

wmf4• 12 years ago

I don't think there is a spec. They're still in the early prototype phase.

rjshade3• 12 years ago

wmf is right in saying this is early days and we're still experimenting.

However there is a roughly up to date wire spec here: https://docs.google.com/a/google.com/document/d/1WJvyZflAO2p...

and a much more detailed design doc here: https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...

danellis3• 12 years ago

Thanks for those links.

erichocean2• 12 years ago

Nice! I implemented this same idea in the social network we're launching today (already Apple approved, ready to hit the Release to Store button in just a few minutes).

Google's right: it's bloody fast, with zero-latency crypto setup times. We love it. This is terrific tech for mobile devices and high-latency, cellular networks.

EDIT: Obviously, I didn't implement QUIC specifically, but something that's equivalent (for our own application). We used NaCl specifically for the cryptography, although there's more to it than just making library calls…

est3• 12 years ago

it's bloody fast

Not so fast (yet).

http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-...

erichocean2• 12 years ago

Comparing an encrypted protocol with an unencrypted one is just lame. Furthermore, QUIC doesn't even have all of its feature set turned on, so these comparisons with unencrypted HTTP are, at best, premature. Also, comparing a single HTTP connection with a SPDY-like connection also misses the point.

We like UDP+PK crypto because it gives us zero latency connection setup times, allows mobile devices to change IPs without disrupting their connections, and for us, our average message size is 256 bytes (think: Twitter), and never over 1400 bytes, so every message we send has zero fragmentation. That leaves message reordering and handling dropped packets, something that's trivial given the rest of our protocol.

QUIC – Next-generation multiplex transport over UDP

Related Stories