QUIC – Next-generation multiplex transport over UDP | Hacker News Reader

QUIC – Next-generation multiplex transport over UDP

docs.google.com

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?

you need the chrome canary build.

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

> 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.

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.

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…

> it's bloody fast

Not so fast (yet).

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

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.

> Comparing an encrypted protocol with an unencrypted one is just lame

Still, that doesn't explain the chart "Goodput as connection speed increases". Something must be capped in QUIC (or perhaps the benchmark setup)

If you think their methodology is flawed you can take a look at the source code maybe fork and improve it.

https://github.com/Connectify/benchmarking/

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

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...)

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

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 !

MPTCP does not solve latency, head of line blocking, TLS handshakes, IP spoofing, or packet bursts.

How many production servers out there risk to upgrade their kernel? I've seen plenty of 2.6 boxes even today.

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

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.

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

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...

No MS support...

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

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...

Where is the spec for this?

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

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...

Thanks for those links.

Reply on news.ycombinator.com