8 ms·

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 event

by jws 12y 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 12y 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 12y 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 12y ago
    What exactly is worrying? Sorry, but it seems like you've written a lot but said very little.
    - deleted 12y ago
      [deleted]
    - azakai 12y 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 12y 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 12y 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 12y ago
The Chromium implementation of QUIC is released as Open Source, so I'm not sure how "proprietary" the protocol actually is.
- pcwalton 12y 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 12y ago
    [deleted]
  - dragonwriter 12y 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 12y 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 12y 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 12y 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?

by jws 12y ago

bla2 12y 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 12y 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 12y ago
  What exactly is worrying? Sorry, but it seems like you've written a lot but said very little.
  - deleted 12y ago
    [deleted]
  - azakai 12y 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 12y 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 12y 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 12y ago

The Chromium implementation of QUIC is released as Open Source, so I'm not sure how "proprietary" the protocol actually is.

pcwalton 12y 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 12y ago
  [deleted]
- dragonwriter 12y 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 12y 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 12y 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 12y 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?