Live data from Hacker News

Google is working on creating a new protocol named QUIC to replace UDP

plus.google.com

21–30 of 118 posts

Re: Google is working on creating a new protocol named QUIC to replace UDP

#21

I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.

Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome.

I'd go so far as to say that in these areas Google is serving as a model corporate citizen, and I wish others would imitate them.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#22

I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.

Your kind of skepticism is ultimately one of the few things that holds corporations in check, so I am not discouraging you from persistently aiming it at Google, Facebook, et al.

But that being said, I was a full-time dev there for 5 years, and I can say with a (however misguided) degree of certainty: all of those projects have one goal in mind - to make the experience of using the web better. Whatever else is true about the dangers of monoculture, Google's intentions are benign.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#23

Can any boffins please explain what impact this might have in practice? Is this just going to mean faster and more secure data transfer, or are there wider implications?

So like others have pointed out, this is not aiming to replace UDP any more than HTTP is aiming to replace TCP. So it's more like a feature rich TCP replacement, a transport protocol that happens to sit on top of UDP (which is what you have to do unless you want to write a OS driver).

As for impact, depends entirely what applications they plan to deploy it on. WebSockets, peer-to-peer WebRTC and media streaming could benefit from real-time friendly properties (fixing head-of-line blocking and enabling selectively unreliable packets). Hard to see anything significant for traditional web content delivery.

There are many things that you might want from a post-TCP transport protocol. Look at some of the SCTP features for a taste. It has stream multiplexing over the single connection, multipath and dynamic address changes, datagram mode, per-message reliable/unreliable option, to name a few.

SCTP seems to have bombed partly because they were "doing it right", ie getting their own IP protocol number and trying to get it deployed inside OS IP stacks instead of of sitting at application level on top of UDP.

The FEC feature in QUIC sounds a little unorthodox unless it's for multicasting or some control plane function, since at this protocol layer it's considered prudent to be sensitive to congestion when coping with packet loss...

Re: Google is working on creating a new protocol named QUIC to replace UDP

#24
post #14
post #6

why does google need to come up with protocols? does the IETF and other processes in place for over a decade not work for them? I know nothing of the protocol (the link only mentions the 'cheeky' naming scheme and the source in the chrome tree); I'm merely commenting on googles motives...

How do you think things get proposed to organizations like the IETF? Someone comes up with a working implementation, proves it to work & to be better than the existing stuff, and then they propose it for inclusion. That's what Google is doing, and they're using Google Chrome as their test bed (along presumably, with a bunch of non-Chrome stuff internally). This is the same thing they did with SPDY. See http://en.wiki…

I appreciate their initiative and their wealth of engineering talent. I completely get what you're saying -- someone has to propose it; and a usable reference implementation is all the better. Unfortunately it seems, given Googles mammoth size, that many folks who might otherwise chime in simply shrug and go "oh, Google has already solved/implemented/popularized a solution" and move on.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#25

Earlier quoted context omitted.

Care to point me to some sources on these limitations? I'm just curious.

I think they're talking about this: Not as SPDY as you thought : http://www.guypo.com/technical/not-as-spdy-as-you-thought/ The guy seems to know what he's talking about, and has actually run some tests but the test setup seems kind of weird. Effectively he's saying "if you only change HTTP to SPDY and make no other changes, then it's 3% slower (though more secure)" or "if you only change HTTPS to SPDY and make no ot…

Yeah, another way of framing it is: even if you do not put the least effort into SPDY, you will benefit a little from security, if nothing else. Tuning incrementally will buy you further improvements.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#26

Can any boffins please explain what impact this might have in practice? Is this just going to mean faster and more secure data transfer, or are there wider implications?

Low uptake as routers will not have built-in support, and admins will be slow to enable it when and if it becomes available (unless its tunneled over another protocol). Why not just push IPv6 adoption?

It's tunneled over UDP.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#27

I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.

Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome. I'd go so far as to say that in these areas Google is serving as a model…

   >I'd go so far as to say that in these areas Google is serving as a model corporate citizen.
Well that is a curious way to look at it.

Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work.

And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#28

I'm all for innovation, but I become wary when a company that controls a sizeable proportion of the browser market-share and also serves a not insignificant proportion of all web traffic makes extensions like this. SPDY, Dart and now this.

Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome. I'd go so far as to say that in these areas Google is serving as a model…

SPDY was heavily used by Google back when it was basically "do what Google do", putting other browser developers under pressure to implement it somehow or be seen as slower. (There was nominally documentation of how it worked. It was wrong.)

Re: Google is working on creating a new protocol named QUIC to replace UDP

#29
post #17

The title seems wrong, at least based on a quick glance this doesn't look like a UDP replacement. It could be a TCP replacement that's encapsulated in UDP. There would potentially be huge benefits to be had from replacing TCP, but of course that's something the people have been trying to do for a long time and failed. Google has a huge advantage in achieving this thanks to controlling a significant proportion of clie…

I agree. Besides they are doing it "secretly" in a public repository.

Re: Google is working on creating a new protocol named QUIC to replace UDP

#30

Earlier quoted context omitted.

Google is the least scary company in this regard. They're putting their extensions out into public hands instead of using an "embrace/extend" model. SPDY is open, soon to become an official web standard, and implemented by popular web server software and browsers (nginx, apache, firefox). The same is true of Chromium as well, the core of Chrome. I'd go so far as to say that in these areas Google is serving as a model…

>I'd go so far as to say that in these areas Google is serving as a model corporate citizen. Well that is a curious way to look at it. Instead of working with other companies to define a common standard they force it through attrition. That's the exact opposite of how this sort of thing should work. And given Google's disgraceful behaviour in abusing the FRAND process they are hardly a model citizen by any measure.

Okay, can you name some standards which were created by multiple companies working together? (I'm not talking about maintenance -- HTML was invented by Tim Berners-Lee, SGML came out of IBM, JavaScript was Netscape, etc.)
Post reply on HN