

QUIC – Next-generation multiplex transport over UDP - digitalnalogika
https://docs.google.com/presentation/d/13LSNCCvBijabnn1S4-Bb6wRlm79gN6hnPFHByEXXptk/present?slide=id.g176a9a2e9_0143

======
crazygringo
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?

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

------
erichocean
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…

~~~
est
> it's bloody fast

Not so fast (yet).

[http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-...](http://tech-
beta.slashdot.org/story/13/11/08/1818258/taking-googles-quic-for-a-test-drive)

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

~~~
est
> 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/](https://github.com/Connectify/benchmarking/)

------
bodski
Video of interview/talk:
[http://www.youtube.com/watch?v=hQZ-0mXFmk8](http://www.youtube.com/watch?v=hQZ-0mXFmk8)

------
signa11
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...](https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/mobilebasic?pli=1))

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

~~~
signa11
hmm, linux-kernel does seem to have some implementation as outlined here:
[http://www.multipath-tcp.org/](http://www.multipath-tcp.org/)

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

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

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

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

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

~~~
rjshade
QUIC is in the Chromium source:

[https://code.google.com/p/chromium/codesearch#chromium/src/n...](https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/)

and there's a demo server here:

[https://code.google.com/p/chromium/codesearch#chromium/src/n...](https://code.google.com/p/chromium/codesearch#chromium/src/net/tools/quic/quic_server.h)

------
danellis
Where is the spec for this?

~~~
rjshade
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...](https://docs.google.com/a/google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-
B_U/edit)

and a much more detailed design doc here:
[https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-
saqs...](https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-
ev2jRFUoVD34/preview?sle=true)

~~~
danellis
Thanks for those links.

