16 ms·

A QUIC update on Google’s experimental transport

231 points by jplevine 11y ago

jws 11y ago
Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic Google says they will eventually submit this to IETF and produce a reference implementation, but it is interesting how a company was able to quietly move a large user base from open protocols to a proprietary protocol.
- bla2 11y ago
  You can't design protocols without implementation experience. Looks like they're going the same route they went with SPDY, and that has worked really well.
  - azakai 11y ago
    There is something about the amount of usage, though. 50% of all communication between Chrome and Google sites is now through a path that is not standardized, nor on track to standardization, and is just special to the combination of Google's browser plus Google's sites. That sets off warning lights for some people, and for good reason. I totally get that to experiment with a new protocol, you need real-world data. Definitely. So if say 1% or 5% of that communication were non-standard, I really wouldn't have much of an issue. But when the "experimentation" is 50%, it's on the verge of being the normal path; it doesn't seem like experimentation. Perhaps they could continue the experiment and go from 50% to 60% or 80% - there isn't much a difference at that point. In fact, if the new protocol is better, it would be almost irrational not to - if 50% is considered ok ethically, and moving to 60% saves costs, then why wouldn't you? I'm not saying that there is something wrong here. It's not even seriously worrying, given Google's positive track record on SPDY. Still, it's very close to the edge of being worrying. That worry of course is that they expand beyond 50%, and are slow to standardize or never do so - in which case things would clearly be wrong. Again, Google has a good reputation here, given SPDY. Still, I'm surprised Google feels ok to move half of all communication to a non-standard protocol, apparently unconcerned about that worrying anyone.
    - manigandham 11y ago
      What exactly is worrying? Sorry, but it seems like you've written a lot but said very little.
      - deleted 11y ago
        [deleted]
      - azakai 11y ago
        As I said, I don't think it's likely or an actual cause for worry. But what this comes close to causing worrying about is if a majority of people using the web were using a non-standard protocol to browse it. That's completely antithetical to the idea of an open web. Right now, 50% of Chrome users (the #1 browser), on Google websites (some of the #1 websites), are in that state.
        manigandham 11y ago
        Antithetical? The web is still open. This is only Google sites visited by Chrome. It's not like you can't visit these Google sites with normal HTTP with other browsers, nor does Chrome use QUIC on the rest of the web. If they walled themselves in then I could see a cause for concern but right now, even 50% of the traffic between Google sites and Chrome is still nowhere near the majority of internet traffic in any sense. Because the web is open and massive is precisely the reason why changes like these will not happen overnight but potentially take decades. The amount of old legacy stuff on the web including protocols, implementations, security holes, ipv4, etc that seem like they'll never get upgraded is far more worrying to me.
      - lkbm 11y ago
        Probably because they've sped up communication between the browser they provide and their website. The logic behind it is benevolent and reasonable, but the short-term effect is that Chrome users get an incentive to use GWS/Gmail/Drive rather than Yahoo/Dropbox, and GWS/GMail/Yahoo users get an incentive to use Chrome rather than Firefox/Safari/IE. If Chrome intentionally started rendering Yahoo slower, that would be blatantly anti-competitive. This is, in effect, just about the same thing, only with practical reasons behind it (much like their were practical reasons behind integrating IE into Windows).
- _stephan 11y ago
  The Chromium implementation of QUIC is released as Open Source, so I'm not sure how "proprietary" the protocol actually is.
  - pcwalton 11y ago
    In a competitive multi-vendor ecosystem like the Web, public-facing protocols that are introduced and controlled by a single vendor are proprietary, regardless of whether you can look at the source code. NaCl and Pepper, for example, are proprietary, even though they have open-source implementations. The distinction between open-source-but-proprietary and open-standard is important for many reasons. One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.
    - deleted 11y ago
      [deleted]
    - dragonwriter 11y ago
      > One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility I think there is a distinction to be made between closed spec protocols and protocols developed prior to being submitting for standardization; while its hard to tell them apart prior to the latter actually being submitted for standardization outside of potentially misleading forward-looking statements of intent, the latter is a reasonable way of cleaning up something and getting some solid real-world feedback and proving utility before submitting something as the basis for standards work while the former carries the problem you describe.
    - kjksf 11y ago
      I don't understand this negativity towards QUIC/Dart/NaCL/Pepper etc. which are exemplary open-source efforts. By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary. Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards. There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol. They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla). Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it. This is exactly how HTTP/2 happened. We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.
- zaroth 11y ago
  This is, after all, half the reason for making Chrome in the first place, right? All better protocols will start as proprietary protocols. To make the web better, faster, larger, yes, Google adds features to Chrome, and of course some of those are at the protocol level. If the feature is actually an improvement, it should be on for everyone that's able to run the code as soon as possible. Ship fast and break nothing. To address a different aspect of your comment, I do think it's very interesting how little attention we pay to the packets of data sent between software running on our personal devices and remote servers. Slap some TLS on it, and nobody even notices. I think there's a fundamental OS level feature, and a highly visible UI component which is outright missing, allowing users to understand no just what programs are connecting to where, but what are they actually sending out and receiving. If it didn't have such horrendous implications and failure modes, I would love to have highly functional deep packet MitM proxy keeping tabs on exactly what my computer is doing over the network. You know, or the NSA could publish a JSON API to access their copy?
  - xg15 11y ago
    This is - as a personal, opt-in debugging tool something I have dreamt if for some time. However, I'm curious what horrendous implications you see there. Could you explain?
FreakyT 11y ago
Interesting, I wonder if this will will end up gaining enough momentum to become a standard, similarly to how SPDY ended up essentially becoming HTTP/2.
josho 11y ago
Google really gets how standardization works. They innovate and once the innovation has proven its value they offer the technology for standardization. I previously saw companies, like Sun, completely fail at this. Eg. The many Java specifications that were created by the standards bodies. Sun tried to do it right by having a reference implementation with the spec. But the Reference implementations were rarely used for real work, so it proved only that the spec could be built, not that the spec elegantly solved real problems.
- username223 11y ago
  > Google really gets how standardization works. They innovate and once the innovation has proven its value they offer the technology for standardization. I wouldn't necessarily say "innovate" or "offer," but they do understand the process. You can make pretty much anything a "standard" with a bit of money and time (isn't Microsoft Office's XML format a "standard"?), but adoption is always an issue. However, Google controls a popular web server (Google search) and client (Google Chrome), so for web-things, they can create "widespread adoption" for whatever they standardize.
  - xorcist 11y ago
    That's not really the complete picture. People want to use the Google standards you mention because they solve a real problem and is proved in production. What problem does Office Open XML solve, apart from not being Open Document XML? You use it because of external factors, not because it is an elegant solution to a problem.
    - pfranz 11y ago
      I think Open Document XML solves a problem--it's just not an immediate problem. It won't make saving and emailing around a document easier, but it will make interoperability (I'm talking even between two versions of Word--not just between word processors) simpler. Even if it's not supported you have some recourse for extracting data. Tragedy of the commons. Google has an advantage because there's an obvious win over the old standard and they offer a big enough buy-in. GIF, for example, is generally better served by PNG. But adoption has been slow because the benefits aren't good enough and wide support took awhile to get implemented.
polskibus 11y ago
Google should investigate (or perhaps just buy outright) a low level communications technology stack from one of the HFT firms - they've already mastered low-latency networking, they just have no incentive to share this knowledge with the outside world.
- _delirium 11y ago
  I think Google's solving a pretty different problem, low-latency communications over a quite heterogeneous network, where they don't control the lower-level infrastructure. HFT firms typically have a narrow range of configurations they have to work over and control the setup of their pipe; they aren't trying to ship technology that will work over every random person's DSL line and funky NAT setup.
- JoshTriplett 11y ago
  Those communication stacks are not suitable for general-purpose use; they sacrifice everything, including usability, robustness, portability, and a hundred other factors in favor of latency. For example, such stacks often put the entire communication stack in userspace, with hardcoded knowledge of how to talk to a specific hardware networking stack, and no ability to cooperate with other clients on the same hardware.
- chollida1 11y ago
  I think you'd be a bit disappointed with what HFT firms do. They are limited in what they can do because they have to talk to the exchange, so its still tcp/ip for order sending, with either FIX or a binary protocol like ITCH/OUCH on top. as far as their networking stack, if they are ultra low HFT then they'll use FPGA's and Arista brand switches or Infinband hardware. The only big customization that most HFT firms do is move the networking stack into user land, but that's a well known area. I"m not aware of any HFT firms that write their own networking stack from the ground up though I'm sure there are a few:) Not much that they do is transferable to everyday computing because most, I'd say 90%, of the performance comes from custom hardware and not the software. Or put another way, Google already has more than enough talent to optimize their QUIC protocol, buying a HFT firm wouldn't do much for them as the HFT speed comes from area's that most people setting up servers won't want touch.
portmanteaufu 11y ago
Possibly silly question: I was under the impression that only TCP allowed for NAT traversal; if I send a UDP packet to Google, how can Google respond without me configuring my router?
- wmf 11y ago
  NAT traversal is easier with UDP than with TCP. Here's a good article on the topic: https://www.zerotier.com/blog/?p=226 https://www.zerotier.com/blog/?p=226
  - manigandham 11y ago
    Thanks for posting, that was a nice article but the intro to ZeroTier was even better, pretty cool software.
- gliptic 11y ago
  NAT traversal isn't necessary when you send packets out of your network, be they TCP or UDP. That's standard operation for NATs.
  - JoeAltmaier 11y ago
    However routers often have an 'allow UDP' checkbox. UDP can be globally disabled, or enabled only for certain ports. uPNP can mitigate this, but most of us have that turned off to prevent Trojan horses from opening the gates entirely.
    - nomel 11y ago
      Bigger question is, why in the world does your router disable UDP by default!? Things like games and video streams are almost universally UDP, because it's better to forget about the data than stop everything, and go get your lost packet.
      - stephen_g 11y ago
rpcope1 11y ago
It will be interesting to see how this works out with NAT being as difficult to work with UDP as it often can be. It's a shame that SCTP is not more widely adopted, as I suspect it may be just as good (if not better) as a transport layer for building a new web protocol on.
- lucian1900 11y ago
  It's unlikely that DTLS over SCTP would be faster than QUIC, which has been specifically designed to have TLS with a minimal number of round trips.
jzawodn 11y ago
I wonder if this is why I've been having weird stalls and intermittent failures using GMail the last few weeks. Every time, I try it in Firefox or Safari and it works perfectly.
- svijaykr1 11y ago
  I work on the QUIC team. If you file a bug with a network log, we'll take a look to see what is going on.
antirez 11y ago
50% and nobody noticed. Can't wait for another marginal latency win that makes the software stack more complex.
- tptacek 11y ago
  Isn't this an argument that nothing in TCP/IP should change, and that we should still be pretending that there is a point to the URG pointer?
  - brighteyes 11y ago
    I took it more for an argument on the "and nobody noticed" aspect.
- billyhoffman 11y ago
  > Software Stack more complex Does QUIC make things more complex? You are replacing TCP + TLS with roughly TLS over UDP with some reliability features build in. TLS and TCP are already crazy complex (behold the state diagram from closing a TCP connection! [CS undergrad heads explode]). Plus, people have already built a number pseudo TCP protocols run over UDP. QUIC + their kindof TLS lite protocol is certainly newer and less well know. That may make things a little harder. But ARP is complex. IP is complex. TCP is complex. Wireshark and others largely abstract this away. I'm excited by the speed, and by the hopefully reduced attack surface of these potentially simpler protocols.
- panopticon 11y ago
  I think the win here is for content providers more so than end users. Might not be a large overhead to the users, but I'm sure it saves Google tons of bandwidth over their hundreds of millions of users.
  - FullyFunctional 11y ago
    That's a very pessimistic view. Technology improvements in general benefits everyone, eventually. The invention of the plane didn't benefit the masses until much later when scaling brought the costs down. I for one welcome what this would do for me on high-latency high-loss connections (read: poor cell phone coverage). I just need Apple to buy into this ...
Splendor 11y ago
The first image really confused me with the 'Receiver' looking like a server and the 'Sender' looking like a laptop.
higherpurpose 11y ago
Wasn't the point of QUIC that it's basically encrypted UDP? I'm not seeing that great of a performance improvement here - 1 second shaved off the loading of top 1% slowest sites. Are those sites that load in 1 minute? Then 1 second isn't that great. However, if the promise is to be an always-encrypted Transport layer (kind of like how CurveCP [1] wanted to be - over TCP though) with small performance gains - or in other words no performance drawbacks - then I'm all for it. I'm just getting the feeling Google is promoting it the wrong way. Shouldn't they be saying "hey, we're going to encrypt the Transport layer by default now!" ? Or am I misunderstanding the purpose of QUIC? [1] - http://curvecp.org/ http://curvecp.org/
- billyhoffman 11y ago
  You got the stats wrong. Its always the same site specifically some unnamed Google property (they used Search and Youtube as other examples so it could be one of them). Google is say that, for clients connecting to the same site, the slowest 1% of those clients saw a 1 second improvement in page load time by using QUIC instead of TCP. (presumably its SPDY + QUIC against SPDY + TCP as they say at the end of the article). That's pretty good. It was 1 second shaved
  - ricardobeat 11y ago
    Not sure what you are getting at, s/sites/clients/. The definition of 'pretty good' depends on how slow that 1% of clients are, as the parent said, 1 second out of 60 (or even 30 or 10) would not really be anything of note.
- wmf 11y ago
  QUIC was never intended to be encrypted UDP, although plenty of people had that misinterpretation. (DTLS is already encrypted UDP.) QUIC is a replacement for TCP and TLS.
  - higherpurpose 11y ago
    So then it's an "always-encrypted" TCP? Or is the "always-encrypted" part wrong? Is it going to be like HTTP/2 where it still has an option for plain-text? (hopefully not)
easytiger 11y ago
I assume they aren't counting the transit time of the first SYN equivalent? Are they saying it traverses the network infinitely fast. Because it doesn't
FullyFunctional 11y ago
MinimaLT [1], developed independently and about the same time as QUIC, also features the minimal latency, but with more (and better IMO) emphasis on security and privacy. (Though both are based on Curve25519). QUIC has an edge with header compression and an available implementation. EDIT: and of course, forward error correction! [1] cr.yp.to/tcpip/minimalt-20130522.pdf
- djcapelis 11y ago
  I hate to be harsh because I like a lot about MinimaLT, but until MinimaLT ships code it doesn't feature anything. I wish we were having a conversation where djb had written an amazing and performant minimaLT implementation that we could prepare against QUIC. But we're not. We're having a conversation where shipping performant code runs a protocol and you're presenting an alternative that pretty much exists only as a PDF document. Believe me, I looked to figure out if there was a good solution for incorporating MinimaLT into code right now and there's not. I have a project where this is relevant. I'm looking at QUIC now and I may incorporate it as an alternative transport layer. (It duplicates some of my own work though, so I'm not sure whether to strip that stuff out or just make mine flexible enough to work on top.) (To say nothing that QUIC can be implemented without a kernel module, which is a handy side-effect of doing things over UDP. A shame that's a factor, but of course it is in realistic systems deployment.)
  - FullyFunctional 11y ago
    Not harsh at all. I agree completely and wish it wasn't so. At this rate, it might be better to focus on improving the security and privacy of QUIC. Re. kernel module: both QUIC and MinimaLT can be implemented in user space.
Fando 11y ago
I wonder how they managed the zero RTT connections? How would that ever work?
- api 11y ago
  Crypto? You can know who your peer is with a single packet if you've already exchanged keys, and other cleverness is also possible.
  - ndesaulniers 11y ago
    At the cost of perfect forward secrecy, since then you're no longer using ephemeral keys?
    - jorangreef 11y ago
      QUIC has a mechanism to upgrade to ephemeral keys once the connection has started.
      - ndesaulniers 11y ago
        As will TLS 1.3, starting from page 3: http://www.ietf.org/proceedings/92/slides/slides-92-tls-3.pdf http://www.ietf.org/proceedings/92/slides/slides-92-tls-3.pd...
- magicalist 11y ago
  You might be interested in https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?usp=sharing https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH... ("Client handshake" section). The key is "Conceptually, all handshakes in QUIC are 0-RTT, it’s just that some of them fail and need to be retried" (at least the first time you contact the server a 1-roundtrip handshake is required).
jeremie 11y ago
As part of telehash v3, we've separated out most of the crypto/handshake packeting into E3X, which has a lot of similarities to QUIC: https://github.com/telehash/telehash.org/blob/master/v3/e3x/intro.md https://github.com/telehash/telehash.org/blob/master/v3/e3x/... Personally I have a much broader use case in mind for E3X than QUIC is designed for, incorporating IoT and meta-transport / end-to-end private communication channels. So, I expect they'll diverge more as they both evolve...
- 1gn1t10n 11y ago
  How is work on Telehash coming? I'm still waiting for an XMPP equivalent for the mobile age that will free us from the medieval [1] state of communication we are experiencing. [1] https://www.schneier.com/blog/archives/2012/12/feudal_sec.html https://www.schneier.com/blog/archives/2012/12/feudal_sec.ht...
rdsubhas 11y ago
I'm not sure if this is related. But sometimes I have a slow home internet (60 kbps after I cross a threshold). At those times, I see websites loading really slow, specially HTTPS connections crawling - But YouTube streaming, Google search and Google webcache works really fast! In fact I've been waiting for a normal website to load for a few minutes on my PC, and the whole time YouTube was streaming in another mobile without any interruptions. Does UDP mess up other traffic?

231 points by jplevine 11y ago

jws 11y ago

Today, roughly half of all requests from Chrome to Google servers are served over QUIC and we’re continuing to ramp up QUIC traffic Google says they will eventually submit this to IETF and produce a reference implementation, but it is interesting how a company was able to quietly move a large user base from open protocols to a proprietary protocol.

bla2 11y ago
You can't design protocols without implementation experience. Looks like they're going the same route they went with SPDY, and that has worked really well.
- azakai 11y ago
  There is something about the amount of usage, though. 50% of all communication between Chrome and Google sites is now through a path that is not standardized, nor on track to standardization, and is just special to the combination of Google's browser plus Google's sites. That sets off warning lights for some people, and for good reason. I totally get that to experiment with a new protocol, you need real-world data. Definitely. So if say 1% or 5% of that communication were non-standard, I really wouldn't have much of an issue. But when the "experimentation" is 50%, it's on the verge of being the normal path; it doesn't seem like experimentation. Perhaps they could continue the experiment and go from 50% to 60% or 80% - there isn't much a difference at that point. In fact, if the new protocol is better, it would be almost irrational not to - if 50% is considered ok ethically, and moving to 60% saves costs, then why wouldn't you? I'm not saying that there is something wrong here. It's not even seriously worrying, given Google's positive track record on SPDY. Still, it's very close to the edge of being worrying. That worry of course is that they expand beyond 50%, and are slow to standardize or never do so - in which case things would clearly be wrong. Again, Google has a good reputation here, given SPDY. Still, I'm surprised Google feels ok to move half of all communication to a non-standard protocol, apparently unconcerned about that worrying anyone.
  - manigandham 11y ago
    What exactly is worrying? Sorry, but it seems like you've written a lot but said very little.
    - deleted 11y ago
      [deleted]
    - azakai 11y ago
      As I said, I don't think it's likely or an actual cause for worry. But what this comes close to causing worrying about is if a majority of people using the web were using a non-standard protocol to browse it. That's completely antithetical to the idea of an open web. Right now, 50% of Chrome users (the #1 browser), on Google websites (some of the #1 websites), are in that state.
      - manigandham 11y ago
        Antithetical? The web is still open. This is only Google sites visited by Chrome. It's not like you can't visit these Google sites with normal HTTP with other browsers, nor does Chrome use QUIC on the rest of the web. If they walled themselves in then I could see a cause for concern but right now, even 50% of the traffic between Google sites and Chrome is still nowhere near the majority of internet traffic in any sense. Because the web is open and massive is precisely the reason why changes like these will not happen overnight but potentially take decades. The amount of old legacy stuff on the web including protocols, implementations, security holes, ipv4, etc that seem like they'll never get upgraded is far more worrying to me.
    - lkbm 11y ago
      Probably because they've sped up communication between the browser they provide and their website. The logic behind it is benevolent and reasonable, but the short-term effect is that Chrome users get an incentive to use GWS/Gmail/Drive rather than Yahoo/Dropbox, and GWS/GMail/Yahoo users get an incentive to use Chrome rather than Firefox/Safari/IE. If Chrome intentionally started rendering Yahoo slower, that would be blatantly anti-competitive. This is, in effect, just about the same thing, only with practical reasons behind it (much like their were practical reasons behind integrating IE into Windows).
_stephan 11y ago
The Chromium implementation of QUIC is released as Open Source, so I'm not sure how "proprietary" the protocol actually is.
- pcwalton 11y ago
  In a competitive multi-vendor ecosystem like the Web, public-facing protocols that are introduced and controlled by a single vendor are proprietary, regardless of whether you can look at the source code. NaCl and Pepper, for example, are proprietary, even though they have open-source implementations. The distinction between open-source-but-proprietary and open-standard is important for many reasons. One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility with a giant pile of C++.
  - deleted 11y ago
    [deleted]
  - dragonwriter 11y ago
    > One of the most important is that open-source-but-proprietary protocols, if they catch on, end up devolving into bug-for-bug compatibility I think there is a distinction to be made between closed spec protocols and protocols developed prior to being submitting for standardization; while its hard to tell them apart prior to the latter actually being submitted for standardization outside of potentially misleading forward-looking statements of intent, the latter is a reasonable way of cleaning up something and getting some solid real-world feedback and proving utility before submitting something as the basis for standards work while the former carries the problem you describe.
  - kjksf 11y ago
    I don't understand this negativity towards QUIC/Dart/NaCL/Pepper etc. which are exemplary open-source efforts. By your definition Mozilla's (your employer's) asm.js and Rust are also proprietary. Somehow I doubt that you jump on every thread about asm.js or Rust to point out how proprietary they are or how they are implemented as a giant pile of C++. Double standards. There have been plenty of research and work even in standard bodies like IETF that try to implement a better tcp/ip-like protocol. They all went nowhere because at this point in time, you can't just have some guys in a room to design a new transmission protocol and have it taken seriously by anyone that matters (Google/Apple/Microsoft/Mozilla). Google is following the only realistic route: implement something, test it in a scale large enough to conclusively show an improvement and then standardize it. This is exactly how HTTP/2 happened. We should be cheering them on instead of spreading FUD because it doesn't live up to your impossible standard of non-proprieterness.
zaroth 11y ago
This is, after all, half the reason for making Chrome in the first place, right? All better protocols will start as proprietary protocols. To make the web better, faster, larger, yes, Google adds features to Chrome, and of course some of those are at the protocol level. If the feature is actually an improvement, it should be on for everyone that's able to run the code as soon as possible. Ship fast and break nothing. To address a different aspect of your comment, I do think it's very interesting how little attention we pay to the packets of data sent between software running on our personal devices and remote servers. Slap some TLS on it, and nobody even notices. I think there's a fundamental OS level feature, and a highly visible UI component which is outright missing, allowing users to understand no just what programs are connecting to where, but what are they actually sending out and receiving. If it didn't have such horrendous implications and failure modes, I would love to have highly functional deep packet MitM proxy keeping tabs on exactly what my computer is doing over the network. You know, or the NSA could publish a JSON API to access their copy?
- xg15 11y ago
  This is - as a personal, opt-in debugging tool something I have dreamt if for some time. However, I'm curious what horrendous implications you see there. Could you explain?

FreakyT 11y ago

Interesting, I wonder if this will will end up gaining enough momentum to become a standard, similarly to how SPDY ended up essentially becoming HTTP/2.

josho 11y ago

Google really gets how standardization works. They innovate and once the innovation has proven its value they offer the technology for standardization. I previously saw companies, like Sun, completely fail at this. Eg. The many Java specifications that were created by the standards bodies. Sun tried to do it right by having a reference implementation with the spec. But the Reference implementations were rarely used for real work, so it proved only that the spec could be built, not that the spec elegantly solved real problems.

username223 11y ago
> Google really gets how standardization works. They innovate and once the innovation has proven its value they offer the technology for standardization. I wouldn't necessarily say "innovate" or "offer," but they do understand the process. You can make pretty much anything a "standard" with a bit of money and time (isn't Microsoft Office's XML format a "standard"?), but adoption is always an issue. However, Google controls a popular web server (Google search) and client (Google Chrome), so for web-things, they can create "widespread adoption" for whatever they standardize.
- xorcist 11y ago
  That's not really the complete picture. People want to use the Google standards you mention because they solve a real problem and is proved in production. What problem does Office Open XML solve, apart from not being Open Document XML? You use it because of external factors, not because it is an elegant solution to a problem.
  - pfranz 11y ago
    I think Open Document XML solves a problem--it's just not an immediate problem. It won't make saving and emailing around a document easier, but it will make interoperability (I'm talking even between two versions of Word--not just between word processors) simpler. Even if it's not supported you have some recourse for extracting data. Tragedy of the commons. Google has an advantage because there's an obvious win over the old standard and they offer a big enough buy-in. GIF, for example, is generally better served by PNG. But adoption has been slow because the benefits aren't good enough and wide support took awhile to get implemented.

polskibus 11y ago

Google should investigate (or perhaps just buy outright) a low level communications technology stack from one of the HFT firms - they've already mastered low-latency networking, they just have no incentive to share this knowledge with the outside world.

_delirium 11y ago
I think Google's solving a pretty different problem, low-latency communications over a quite heterogeneous network, where they don't control the lower-level infrastructure. HFT firms typically have a narrow range of configurations they have to work over and control the setup of their pipe; they aren't trying to ship technology that will work over every random person's DSL line and funky NAT setup.
JoshTriplett 11y ago
Those communication stacks are not suitable for general-purpose use; they sacrifice everything, including usability, robustness, portability, and a hundred other factors in favor of latency. For example, such stacks often put the entire communication stack in userspace, with hardcoded knowledge of how to talk to a specific hardware networking stack, and no ability to cooperate with other clients on the same hardware.
chollida1 11y ago
I think you'd be a bit disappointed with what HFT firms do. They are limited in what they can do because they have to talk to the exchange, so its still tcp/ip for order sending, with either FIX or a binary protocol like ITCH/OUCH on top. as far as their networking stack, if they are ultra low HFT then they'll use FPGA's and Arista brand switches or Infinband hardware. The only big customization that most HFT firms do is move the networking stack into user land, but that's a well known area. I"m not aware of any HFT firms that write their own networking stack from the ground up though I'm sure there are a few:) Not much that they do is transferable to everyday computing because most, I'd say 90%, of the performance comes from custom hardware and not the software. Or put another way, Google already has more than enough talent to optimize their QUIC protocol, buying a HFT firm wouldn't do much for them as the HFT speed comes from area's that most people setting up servers won't want touch.

portmanteaufu 11y ago

Possibly silly question: I was under the impression that only TCP allowed for NAT traversal; if I send a UDP packet to Google, how can Google respond without me configuring my router?

wmf 11y ago
NAT traversal is easier with UDP than with TCP. Here's a good article on the topic: https://www.zerotier.com/blog/?p=226 https://www.zerotier.com/blog/?p=226
- manigandham 11y ago
  Thanks for posting, that was a nice article but the intro to ZeroTier was even better, pretty cool software.
gliptic 11y ago
NAT traversal isn't necessary when you send packets out of your network, be they TCP or UDP. That's standard operation for NATs.
- JoeAltmaier 11y ago
  However routers often have an 'allow UDP' checkbox. UDP can be globally disabled, or enabled only for certain ports. uPNP can mitigate this, but most of us have that turned off to prevent Trojan horses from opening the gates entirely.
  - nomel 11y ago
    Bigger question is, why in the world does your router disable UDP by default!? Things like games and video streams are almost universally UDP, because it's better to forget about the data than stop everything, and go get your lost packet.
    - stephen_g 11y ago

rpcope1 11y ago

It will be interesting to see how this works out with NAT being as difficult to work with UDP as it often can be. It's a shame that SCTP is not more widely adopted, as I suspect it may be just as good (if not better) as a transport layer for building a new web protocol on.

lucian1900 11y ago
It's unlikely that DTLS over SCTP would be faster than QUIC, which has been specifically designed to have TLS with a minimal number of round trips.

jzawodn 11y ago

I wonder if this is why I've been having weird stalls and intermittent failures using GMail the last few weeks. Every time, I try it in Firefox or Safari and it works perfectly.

svijaykr1 11y ago
I work on the QUIC team. If you file a bug with a network log, we'll take a look to see what is going on.

antirez 11y ago

50% and nobody noticed. Can't wait for another marginal latency win that makes the software stack more complex.

tptacek 11y ago
Isn't this an argument that nothing in TCP/IP should change, and that we should still be pretending that there is a point to the URG pointer?
- brighteyes 11y ago
  I took it more for an argument on the "and nobody noticed" aspect.
billyhoffman 11y ago
> Software Stack more complex Does QUIC make things more complex? You are replacing TCP + TLS with roughly TLS over UDP with some reliability features build in. TLS and TCP are already crazy complex (behold the state diagram from closing a TCP connection! [CS undergrad heads explode]). Plus, people have already built a number pseudo TCP protocols run over UDP. QUIC + their kindof TLS lite protocol is certainly newer and less well know. That may make things a little harder. But ARP is complex. IP is complex. TCP is complex. Wireshark and others largely abstract this away. I'm excited by the speed, and by the hopefully reduced attack surface of these potentially simpler protocols.
panopticon 11y ago
I think the win here is for content providers more so than end users. Might not be a large overhead to the users, but I'm sure it saves Google tons of bandwidth over their hundreds of millions of users.
- FullyFunctional 11y ago
  That's a very pessimistic view. Technology improvements in general benefits everyone, eventually. The invention of the plane didn't benefit the masses until much later when scaling brought the costs down. I for one welcome what this would do for me on high-latency high-loss connections (read: poor cell phone coverage). I just need Apple to buy into this ...

Splendor 11y ago

The first image really confused me with the 'Receiver' looking like a server and the 'Sender' looking like a laptop.

higherpurpose 11y ago

Wasn't the point of QUIC that it's basically encrypted UDP? I'm not seeing that great of a performance improvement here - 1 second shaved off the loading of top 1% slowest sites. Are those sites that load in 1 minute? Then 1 second isn't that great. However, if the promise is to be an always-encrypted Transport layer (kind of like how CurveCP [1] wanted to be - over TCP though) with small performance gains - or in other words no performance drawbacks - then I'm all for it. I'm just getting the feeling Google is promoting it the wrong way. Shouldn't they be saying "hey, we're going to encrypt the Transport layer by default now!" ? Or am I misunderstanding the purpose of QUIC? [1] - http://curvecp.org/ http://curvecp.org/

billyhoffman 11y ago
You got the stats wrong. Its always the same site specifically some unnamed Google property (they used Search and Youtube as other examples so it could be one of them). Google is say that, for clients connecting to the same site, the slowest 1% of those clients saw a 1 second improvement in page load time by using QUIC instead of TCP. (presumably its SPDY + QUIC against SPDY + TCP as they say at the end of the article). That's pretty good. It was 1 second shaved
- ricardobeat 11y ago
  Not sure what you are getting at, s/sites/clients/. The definition of 'pretty good' depends on how slow that 1% of clients are, as the parent said, 1 second out of 60 (or even 30 or 10) would not really be anything of note.
wmf 11y ago
QUIC was never intended to be encrypted UDP, although plenty of people had that misinterpretation. (DTLS is already encrypted UDP.) QUIC is a replacement for TCP and TLS.
- higherpurpose 11y ago
  So then it's an "always-encrypted" TCP? Or is the "always-encrypted" part wrong? Is it going to be like HTTP/2 where it still has an option for plain-text? (hopefully not)

easytiger 11y ago

I assume they aren't counting the transit time of the first SYN equivalent? Are they saying it traverses the network infinitely fast. Because it doesn't

FullyFunctional 11y ago

MinimaLT [1], developed independently and about the same time as QUIC, also features the minimal latency, but with more (and better IMO) emphasis on security and privacy. (Though both are based on Curve25519). QUIC has an edge with header compression and an available implementation. EDIT: and of course, forward error correction! [1] cr.yp.to/tcpip/minimalt-20130522.pdf

djcapelis 11y ago
I hate to be harsh because I like a lot about MinimaLT, but until MinimaLT ships code it doesn't feature anything. I wish we were having a conversation where djb had written an amazing and performant minimaLT implementation that we could prepare against QUIC. But we're not. We're having a conversation where shipping performant code runs a protocol and you're presenting an alternative that pretty much exists only as a PDF document. Believe me, I looked to figure out if there was a good solution for incorporating MinimaLT into code right now and there's not. I have a project where this is relevant. I'm looking at QUIC now and I may incorporate it as an alternative transport layer. (It duplicates some of my own work though, so I'm not sure whether to strip that stuff out or just make mine flexible enough to work on top.) (To say nothing that QUIC can be implemented without a kernel module, which is a handy side-effect of doing things over UDP. A shame that's a factor, but of course it is in realistic systems deployment.)
- FullyFunctional 11y ago
  Not harsh at all. I agree completely and wish it wasn't so. At this rate, it might be better to focus on improving the security and privacy of QUIC. Re. kernel module: both QUIC and MinimaLT can be implemented in user space.

Fando 11y ago

I wonder how they managed the zero RTT connections? How would that ever work?

api 11y ago
Crypto? You can know who your peer is with a single packet if you've already exchanged keys, and other cleverness is also possible.
- ndesaulniers 11y ago
  At the cost of perfect forward secrecy, since then you're no longer using ephemeral keys?
  - jorangreef 11y ago
    QUIC has a mechanism to upgrade to ephemeral keys once the connection has started.
    - ndesaulniers 11y ago
      As will TLS 1.3, starting from page 3: http://www.ietf.org/proceedings/92/slides/slides-92-tls-3.pdf http://www.ietf.org/proceedings/92/slides/slides-92-tls-3.pd...
magicalist 11y ago
You might be interested in https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit?usp=sharing https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH... ("Client handshake" section). The key is "Conceptually, all handshakes in QUIC are 0-RTT, it’s just that some of them fail and need to be retried" (at least the first time you contact the server a 1-roundtrip handshake is required).

jeremie 11y ago

As part of telehash v3, we've separated out most of the crypto/handshake packeting into E3X, which has a lot of similarities to QUIC: https://github.com/telehash/telehash.org/blob/master/v3/e3x/intro.md https://github.com/telehash/telehash.org/blob/master/v3/e3x/... Personally I have a much broader use case in mind for E3X than QUIC is designed for, incorporating IoT and meta-transport / end-to-end private communication channels. So, I expect they'll diverge more as they both evolve...

1gn1t10n 11y ago
How is work on Telehash coming? I'm still waiting for an XMPP equivalent for the mobile age that will free us from the medieval [1] state of communication we are experiencing. [1] https://www.schneier.com/blog/archives/2012/12/feudal_sec.html https://www.schneier.com/blog/archives/2012/12/feudal_sec.ht...

rdsubhas 11y ago

I'm not sure if this is related. But sometimes I have a slow home internet (60 kbps after I cross a threshold). At those times, I see websites loading really slow, specially HTTPS connections crawling - But YouTube streaming, Google search and Google webcache works really fast! In fact I've been waiting for a normal website to load for a few minutes on my PC, and the whole time YouTube was streaming in another mobile without any interruptions. Does UDP mess up other traffic?