4 ms·

QUIC – Next-generation multiplex transport over UDP

bodski 13y ago
Video of interview/talk: http://www.youtube.com/watch?v=hQZ-0mXFmk8 http://www.youtube.com/watch?v=hQZ-0mXFmk8
crazygringo 13y 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 13y ago
  you need the chrome canary build. https://www.google.com/intl/en/chrome/browser/canary.html https://www.google.com/intl/en/chrome/browser/canary.html
- rjshade 13y 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 13y 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.
signa11 13y 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/1lmL9EF6qKrk7gbazY8bIdvq3Pno2Xj_l_YShP40GLQE/mobilebasic?pli=1 https://docs.google.com/document/d/1lmL9EF6qKrk7gbazY8bIdvq3...)
- wmf 13y ago
  MPTCP doesn't solve the problems that QUIC cares about and OSes don't support it anyway.
  - signa11 13y ago
    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 13y ago
      MPTCP does not solve latency, head of line blocking, TLS handshakes, IP spoofing, or packet bursts.
    - est 13y ago
      How many production servers out there risk to upgrade their kernel? I've seen plenty of 2.6 boxes even today.
nasalgoat 13y ago
Are there any libraries and/or demo code to implement this?
- rjshade 13y ago
  QUIC is in the Chromium source: https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/ 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/net/tools/quic/quic_server.h https://code.google.com/p/chromium/codesearch#chromium/src/n...
yjh0502 13y ago
How about SCTP? It also supports multimple streams on single connection, no head-of-line blocking, multihoming, and in standard.
- danellis 13y 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.
- wmf 13y ago
  Doing a SCTP four-way handshake and then a TLS handshake is going to be pretty high latency.
- zurn 13y 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 13y ago
  No MS support...
danellis 13y ago
Where is the spec for this?
- wmf 13y ago
  I don't think there is a spec. They're still in the early prototype phase.
- rjshade 13y 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/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit 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-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
  - danellis 13y ago
    Thanks for those links.
erichocean 13y 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…
- est 13y ago
  > it's bloody fast Not so fast (yet). http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-googles-quic-for-a-test-drive http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-...
  - erichocean 13y 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.
    - est 13y ago
      > 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/

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

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 13y ago
you need the chrome canary build. https://www.google.com/intl/en/chrome/browser/canary.html https://www.google.com/intl/en/chrome/browser/canary.html
rjshade 13y 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 13y 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.

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

wmf 13y ago
MPTCP doesn't solve the problems that QUIC cares about and OSes don't support it anyway.
- signa11 13y ago
  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 13y ago
    MPTCP does not solve latency, head of line blocking, TLS handshakes, IP spoofing, or packet bursts.
  - est 13y ago
    How many production servers out there risk to upgrade their kernel? I've seen plenty of 2.6 boxes even today.

nasalgoat 13y ago

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

rjshade 13y ago
QUIC is in the Chromium source: https://code.google.com/p/chromium/codesearch#chromium/src/net/quic/ 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/net/tools/quic/quic_server.h https://code.google.com/p/chromium/codesearch#chromium/src/n...

yjh0502 13y ago

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

danellis 13y 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.
wmf 13y ago
Doing a SCTP four-way handshake and then a TLS handshake is going to be pretty high latency.
zurn 13y 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 13y ago
No MS support...

danellis 13y ago

Where is the spec for this?

wmf 13y ago
I don't think there is a spec. They're still in the early prototype phase.
rjshade 13y 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/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit 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-saqsQx7rFV-ev2jRFUoVD34/preview?sle=true https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqs...
- danellis 13y ago
  Thanks for those links.

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

est 13y ago
> it's bloody fast Not so fast (yet). http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-googles-quic-for-a-test-drive http://tech-beta.slashdot.org/story/13/11/08/1818258/taking-...
- erichocean 13y 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.
  - est 13y ago
    > 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/