Live data from Hacker News

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

plus.google.com

51–60 of 118 posts

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

#51

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.

If they'd announced this before they had a working implementation then Microsoft would have either created their own competing standard or wanted changes that only benefit themselves and slowed down development.

AFTER EDIT:

Why the downvote?

Ok, maybe I shouldn't have singled out Microsoft, but I think their past behaviour explains a lot the way Google are behaving now. I'm thinking in particular of what happened with XForms and WebGL.

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

#52
post #40
post #39

These use cases spring to my mind: real-time data and multi-player action games, perhaps even streaming media. TCP and HTTP are less than ideal transports when it comes to real time data. In case of a network error, TCP retransmits the lost data but in a real-time environment, the data is already old and therefore next to useless. Real time action games (like quake) favor udp over tcp. Some questions: Why replace UDP…

Why not use DCCP then?

Is DCCP widely used by anyone?

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

#53

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.

Both SPDY and Dart are open, neither are patent encumbered, and nobody is forcing you to use either.

I am wary too.... but I don't see anything obviously wrong.

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

#54
post #9

Note how SPDY has proven to have limited benefits in the realworld vs a lab. Not that I want to stop their brilliant minds from looking at these problems and trying to solve them, especially on their dime.

If SPDY has limited benefits in the real-world why have both Facebook and Twitter deployed it?

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

#55

Earlier quoted context omitted.

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.)

Java 7!

Java was Sun.

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

#56

Earlier quoted context omitted.

Well I did post the source port, which reduces the effort by a factor of tens of thousands... also, the up-thread did say "with a single fake RST or FIN packet"... which is why I mentioned window guessing... Also, crap, I'm an idiot. Let me do that non-natted ;) tcp 0 0 216.240.155.220:4007 60.225.131.226:43972 ESTABLISHED 18694/nc

Write failed: Broken pipe Well done! Also, you didn't packet me off the Internet, which was nice :) Bet you can't do it with one packet though!

Sorry for the beginner questions, but how did the remote port change from 80 to 4007? Are you NATed on both ends? And, how did you go about getting the IP:port of your local router? Are you using some tool, or do you have root on your office router?

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

#57

I'll tell you a dirty little secret of the protocol design. Say, you want to design a protocol with reliable delivery and/or loss detection. You will then have ACKs, send window and retransmissions. Guess what? If you don't follow windowing semantics of TCP, then one of two things will happen on saturated links - either TCP will end up with all the bandwidth or you will. So - surprise! - you have no choice but to des…

[deleted]

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

#58
post #41

Earlier quoted context omitted.

The Java Community Process back in the day was a good example of how lots of large companies working together could define a standard and yet still leave room for innovation. H.264 and WiFi standards are recent examples of a lot of companies working together.

Yeah, but 90% of those standards were TERRIBLE. Like, GOD AWFUL. EJB? SOAP? It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java. Eventually the JCP turned into "take popular open source ideas like hibernate and spring, and bless them with a JCP number". Which worked a lot better, and each of those individual projects was usually launched by an individual or…

> It's the hangover from those standards that leaves kids today thinking that Python or Ruby are simpler than Java.

I would really love to hear how you could possibly believe otherwise.

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

#59

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…

I believe there was a flaw in his argument, and that was Facebook was using SPDY on the front end, but not on all the back end services, or external services Facebook uses...
Post reply on HN