Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

plus.google.com

Post reply on HN
Print view View original

91–100 of 118 posts

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

#91

Post by chetanahuja »

sageikosa wrote: post #10
rednukleus wrote: post #4

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?

IPV6 vs IPV4 question is orthogonal to those addressed by the QUIC protocol. IP layer is for addressing nodes on the internet and routing packets to them in a stateless manner (more or less... I'm not counting routing table caches and such as "state"). TCP (and this QUIC protocol) are built on top of the IP layer to provide reliable end-to-end data transfers in some sort of session based mechanism.

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

#92

Post by popee »

jacob019 wrote: post #60

UDP is connectionless. How can we have encryption without a connection? Using a block cypher would be less secure than stream cyphers and the controversy could halt adoption.

It's possible: DTLS. Also CISCO uses UDP for their VPN solutions so go figure.

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

#93

Post by chetanahuja »

As other's have pointed out, it's not a replacement for UDP or "improved version of UDP with some extra features such as encryption" as mentioned in the original article but a reliable, encrypted protocol using UDP as transport layer. That makes sense because most NAT boxes etc. have to let UDP packets get through because they have to support DNS, VOIP protocols et el. I suspect the encryption part has more (or at least just as much) to do with keeping the middle-boxen's dirty hands off of the the protocol innards than MITM security.

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

#94

Post by chetanahuja »

exDM69 wrote: 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…

"Some questions: Why replace UDP? Why not work on top of UDP?"

It's not replacing UDP. It is built on top of UDP. It's all there in the source code.

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

#95

Post by jbooth »

Ao7bei3s wrote: post #79
jbooth wrote: post #65

Earlier quoted context omitted.

The language Java is simpler than the language Python or Ruby. Fewer keywords, those keywords do fewer things. Ruby and Python seem simpler for most web work due to better frameworks and dynamic typing, which is less simple than static typing, but is easier to work with in most web situations. I guess I'm drawing a distinction between 'simple' and 'convenient'. Monkey patching in Ruby is not simple, but can be conven…

The keyword count thing is easily refutable: Python has 38 keywords, Ruby has 41, Java has 50. http://en.wikipedia.org/wiki/List_of_Java_keywords http://docs.python.org/3/reference/lexical_analysis.html#ide... https://github.com/ruby/ruby/blob/trunk/parse.y (grep for reswords) I'm undecided whether Python/Ruby or Java are simpler. At least to me dynamic typing seems much simpler than static typing: from a very very p…

[Now, after having written this, I don't think its possible that any of the three languages is strictly simpler than any of the other ones.]

Me too, great comment, thanks.

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

#96

Post by js2 »

latitude wrote: post #20

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…

From quic_protocol.h:

  // Defines for all types of congestion feedback that will be negotiated in QUIC,
  // kTCP MUST be supported by all QUIC implementations to guarantee 100%
  // compatibility.
  enum CongestionFeedbackType {
    kTCP,  // Used to mimic TCP.
    kInterArrival,  // Use additional inter arrival information.
    kFixRate,  // Provided for testing.
  };
:-)

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

#97

Post by sageikosa »

chetanahuja wrote: post #91
sageikosa wrote: post #10

Earlier quoted context omitted.

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?

IPV6 vs IPV4 question is orthogonal to those addressed by the QUIC protocol. IP layer is for addressing nodes on the internet and routing packets to them in a stateless manner (more or less... I'm not counting routing table caches and such as "state"). TCP (and this QUIC protocol) are built on top of the IP layer to provide reliable end-to-end data transfers in some sort of session based mechanism.

I was thinking primarily of the security aspects, which is one of the few things called out. I'm all for secure and discrete transfers of data between endpoints, since TCP programming APIs often require maintaining process state for each connection and can impact service scaling.

If this is really more or a session layer protocol on top of UDP instead of its own transport protocol, then all the more power to them. It will be more of a programming model than a network configuration quagmire, and I'm sure that eventually intelligent optimizations can be performed via packet inspection if the protocol state details are not encapsulated deep within the security (i.e., trust/privacy) bubble of the protocol.

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

#98

Post by matthiasl »

popee wrote: post #88

Hey, what happened to SCTP?

SCTP is widely used for carrying signalling in mobile and fixed telephone networks. It is _the_ way of carrying SS7 over IP.

(Another angle on the same thing: it didn't get used much outside the thing it was originally designed for.)

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

#99

Post by zobzu »

InclinedPlane wrote: post #21
DanWaterworth wrote: post #5

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…

Having open-source implementation do not mean you're not going to "embrass and extend". It's a common misconception.

If you're the only big player, that your stuff is open just means others can also implement your protocol. But since you're the only big player, they can't have their protocol.

So you can make your protocol work for you, do things that will bring you more money, and have it open-source, AND force it upon others.

Forking it doesn't mean shit if you're forced to use it to access _ANYTHING_ anyways.

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

#100

Post by zobzu »

Flenser wrote: post #83
Dylan16807 wrote: post #81

Earlier quoted context omitted.

What did Microsoft do to WebGL? I thought they simply liked to pretend it doesn't exist.

They said it was a security risk even though Silverlight 3D had the same problem.

They're still right, it is a security risk. Now, it doesn't mean we shouldn't have it. But it is one. Heck, the well known chrome vulns of the past alone should show that.
Post reply on HN