9 ms·

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

192 points by patrickaljord 14y ago

zx2c4 14y ago
Prior: http://news.ycombinator.com/item?id=4854839 http://news.ycombinator.com/item?id=4854839
simplexion 14y ago
Is it connectionless?
rednukleus 14y ago
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?
- sageikosa 14y ago
  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?
  - rednukleus 14y ago
    They aren't mutually exclusive, are they?
  - JulianMorrison 14y ago
    It's tunneled over UDP.
  - chetanahuja 14y ago
    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.
    - sageikosa 14y ago
      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.
- potkor 14y ago
  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...
DanWaterworth 14y ago
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.
- alexjeffrey 14y ago
  arguably, google are well positioned to see where improvements to traffic protocols can be made due to both chrome's large market share and their massive traffic requirements for google search et al. Later on if/when their protocols are finalised and released, I'm sure one standards body or another will work to integrate them.
- RexRollman 14y ago
  So long as it is available for everyone to use in a free manner, I really don't have a problem with it.
- deleted 14y ago
  [deleted]
- InclinedPlane 14y ago
  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.
  - taligent 14y ago
    >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.
pyvpx 14y ago
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...
- leothekim 14y ago
  In general, NIH is a way of life at Google. Still, they solve problems at a variety and scale s.t. I can understand their tendency to work this way.
- avar 14y ago
  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.wikipedia.org/wiki/SPDY#Relation_to_HTTP http://en.wikipedia.org/wiki/SPDY#Relation_to_HTTP for details. If what you're hinting at is that they should first start some wider discussion about what a next-gen UDP should look like before they start doing anything, then I suggest you look up "bikeshedding". Such a process would never get anywhere.
  - pyvpx 14y ago
    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.
    - wmf 14y ago
      That's not happening with SPDY, WebRTC, Dart, or WebP. Google's competitors are going over these proposals with the proverbial fine-toothed comb. I get the impression that people are extra skeptical of Google standards because of the potential to get steamrolled.
leothekim 14y ago
Hm I suppose it's not secret anymore. :-) The file listing shows reliable_quic_stream.cc and .h files as well, so maybe it goes a step past UDP?
ck2 14y ago
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.
- santaragolabs 14y ago
  Care to point me to some sources on these limitations? I'm just curious.
  - ZeroGravitas 14y ago
    I think they're talking about this: Not as SPDY as you thought: http://www.guypo.com/technical/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 other changes, then it's only 4% faster" assuming your site looks like some kind of average of the top 500 sites. And his conclusion is much more positive than most of the 3rd party coverage of it: "I believe SPDY is still awesome, and is a step in the right direction. This study and its conclusions do not mean we should stop working on SPDY, but rather that we should work on it more, and make it even faster."
    - JulianMorrison 14y ago
      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.
    - youngtaff 14y ago
      Guy does know what's talking about but there are some limitations to his tests - which to be fair he's pretty open about in the post. The biggest challenge is optimising for SPDY is different to optimising for HTTP and so many of the test sites may have behaviours that aren't optimal for SPDY. In addition to Google, Facebook and Twitter are/have deploying SPDY so I think we can be sure it has benefits.
jsnell 14y ago
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 clients and servers.
- reidrac 14y ago
  I agree. Besides they are doing it "secretly" in a public repository.
deleted 14y ago
[deleted]
latitude 14y ago
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 design a TCP clone. [ EDIT ] That said, there is a fundamental problem with TCP, when it's used for carrying secure connections. Since TCP acts as a pure transport protocol, it has no per-packet authentication and so any connection can be trivially DoS'd with a single fake FIN or RST packet. There are ways to solve this, e.g. by reversing the TCP and security layers and running TCP over ESP-over-UDP or TLS-over-UDP (OpenVPN protocol). This requires either writing a user-space TCP library or doing some nasty tunneling at the kernel level, but even as cumbersome as this is, it's still not a reason enough to re-invent the wheel. Also, if you want compression, it's readily available in TLS or as a part of IPsec stack (IPcomp). If you want FEC, same thing - just add a custom transform to TLS and let the client and server negotiate if to use it or not. I mean, every network programmer invents a protocol or two in his lifetime. It's like a right of passage and it's really not a big deal. Unless it ends up attached to a brand name, in which case it starts attracting snarky remarks like this one :)
- xyzzy123 14y ago
  I agree with your original point, but none of the stuff after [EDIT] makes much sense to me. "Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet." I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption thingy you use. Otherwise, any modern TCP stack should be able to reject blind FINs or RSTs as out-of-sequence. Generally, the reason people avoid TCP-over-TCP is not DoS, but basically "timer fights", as per: http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html. That said, everything-over SSL is still popular for practical reasons, such as clientless VPNs which need to work around proxies, firewalls etc.
  - latitude 14y ago
advm 14y ago
This is more than merely UDP with encryption. Rather, this seems to be a reliable stream protocol that aimed at dethroning TCP. I don't think it intends to replace UDP. If anything, I would describe it as a user space replacement for TCP. It uses UDP, yes, but that's because UDP is about as close as you can get to IP at the user level. It's about time, too. Certainly user-level substitutes for TCP are not a new idea (I've worked a good deal with UDT), but this the first one to my knowledge that has the weight of something like Google behind it. There are a lot of advantages to doing this as the user level with UDP as well. Not needing to install a kernel module, for one. But also P2P rendezvous connections through NAT with UDP (we wouldn't even need to wait for router manufacturers to adopt anything), better control over protocol options without going through the kernel, custom congestion control algorithms, finer control over buffers (mmap'd files as buffer for file transfers anyone?), etc. I'd much rather see this at the kernel level, but TCP as it's implemented on most systems has too many issues on modern networks, and most acceptable user-level solutions (ugh, parallel streams) are really terrible hacks. If Google does it right, maybe it'll force OS developers to wake up and rethink the increasingly clunky and antiquated BSD sockets API that is the source of many of TCP's woes and finally modernize the network stack for the fiber era.
- anonymfus 14y ago
  >If Google does it right, maybe it'll force OS developers to wake up and rethink the increasingly clunky and antiquated BSD sockets API that is the source of many of TCP's woes and finally modernize the network stack for the fiber era. WinRT don't ever has BSD sockets.
- X-Istence 14y ago
  What exactly about the BSD sockets API makes it a source of TCP's many woes? What woes are you talking about? Also, why do we want to re-implement TCP in user space, when it still needs to traverse the kernel as a UDP packet, this doesn't have any of the benefits that netmap or PF_RING for example bring to the table where the software is doing the full stack and thus there is less latency involved. QUIC as it currently stands will be sitting on top of UDP, so all packets traverse the kernel, get dumped to user space, user space parses it, and sends packets back, as UDP. All that extra copying, when with TCP in the kernel the kernel would be responsible for reassembling packets, would be responsible for ACK'ing packets, and stuff like that. Also, mmap'd files as buffer for file transfers ... you are going to have to explain that one. There are already various zero copy mechanisms for sending files, such as sendfile(). As for new congestion control algorithms, great, sounds fantastic, but how much more of a nightmare is it going to be to get the parties to agree on a congestion control mechanism? We already have that problem now ... Sorry, but I see a whole lot of complaining without any real data or information to back it up. [[citation needed]].
exDM69 14y ago
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 work on top of UDP? There must be a reason for this. What about multicast?
- rumcajz 14y ago
  Why not use DCCP then?
  - morsch 14y ago
    Is DCCP widely used by anyone?
    - rthomas6 14y ago
      Is QUIC widely used by anyone?
- popee 14y ago
  UDP doesn't have any guarantee that packet is received. If you stream video that can handle few lost packet it is ok, but if you need reliability than you need TCP. So, it's kind of programmer decision what to use. In reality there should be protocol that is lightweight and somewhere in between TCP and UDP (from personal experience). I haven't read anything about this new google protocol, but i'm not sure if they are trying to do that. Well, maybe i should go and read it >:-)
- chetanahuja 14y ago
  "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.
jacob019 14y ago
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.
- AnthonyMouse 14y ago
  http://www.ietf.org/rfc/rfc4303.txt http://www.ietf.org/rfc/rfc4303.txt http://www.ietf.org/rfc/rfc4347.txt http://www.ietf.org/rfc/rfc4347.txt
- popee 14y ago
  It's possible: DTLS. Also CISCO uses UDP for their VPN solutions so go figure.
  - zobzu 14y ago
    Not Invented Here. Google wants control, IMO. I'd be interested in their reasons for not using DTLS, or improving DTLS. They actually use it for WebRTC.
- jacob019 14y ago
  come to think of it OpenVPN uses UDP also, and that's considered quite secure. So what kind of encryption are they using? Rolling their own sounds scary.
beagle3 14y ago
Hopefully they'd take a lot from djb NaCl ( http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ , which predates Google's NaCl and is unrelated). Transport security, endpoint multiplexing and endpoint mobility done right.
- pjscott 14y ago
  Good news! Their crypto stuff looks pretty reasonable. Key exchange uses ECDH with either the P-256 or curve25519 polynomials. Once the session key is established, it's encrypted with AES-128 and authenticated with either GCM or HMAC-SHA256. None of this is implemented yet, but it's at least cause for hope.
popee 14y ago
Hey, what happened to SCTP?
- wmf 14y ago
  SCTP is DOA since Windows doesn't implement it and it doesn't pass through NATs. WebRTC DataChannel is SCTP over DTLS over UDP, though.
- matthiasl 14y ago
  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.)
chetanahuja 14y ago
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.
benth 14y ago
Curious how it compares with SCTP over DTLS over UDP (which WebRTC uses).

192 points by patrickaljord 14y ago

zx2c4 14y ago

Prior: http://news.ycombinator.com/item?id=4854839 http://news.ycombinator.com/item?id=4854839

simplexion 14y ago

Is it connectionless?

rednukleus 14y ago

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?

sageikosa 14y ago
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?
- rednukleus 14y ago
  They aren't mutually exclusive, are they?
- JulianMorrison 14y ago
  It's tunneled over UDP.
- chetanahuja 14y ago
  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.
  - sageikosa 14y ago
    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.
potkor 14y ago
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...

DanWaterworth 14y ago

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.

alexjeffrey 14y ago
arguably, google are well positioned to see where improvements to traffic protocols can be made due to both chrome's large market share and their massive traffic requirements for google search et al. Later on if/when their protocols are finalised and released, I'm sure one standards body or another will work to integrate them.
RexRollman 14y ago
So long as it is available for everyone to use in a free manner, I really don't have a problem with it.
deleted 14y ago
[deleted]
InclinedPlane 14y ago
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.
- taligent 14y ago
  >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.

pyvpx 14y ago

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

leothekim 14y ago
In general, NIH is a way of life at Google. Still, they solve problems at a variety and scale s.t. I can understand their tendency to work this way.
avar 14y ago
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.wikipedia.org/wiki/SPDY#Relation_to_HTTP http://en.wikipedia.org/wiki/SPDY#Relation_to_HTTP for details. If what you're hinting at is that they should first start some wider discussion about what a next-gen UDP should look like before they start doing anything, then I suggest you look up "bikeshedding". Such a process would never get anywhere.
- pyvpx 14y ago
  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.
  - wmf 14y ago
    That's not happening with SPDY, WebRTC, Dart, or WebP. Google's competitors are going over these proposals with the proverbial fine-toothed comb. I get the impression that people are extra skeptical of Google standards because of the potential to get steamrolled.

leothekim 14y ago

Hm I suppose it's not secret anymore. :-) The file listing shows reliable_quic_stream.cc and .h files as well, so maybe it goes a step past UDP?

ck2 14y ago

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.

santaragolabs 14y ago
Care to point me to some sources on these limitations? I'm just curious.
- ZeroGravitas 14y ago
  I think they're talking about this: Not as SPDY as you thought: http://www.guypo.com/technical/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 other changes, then it's only 4% faster" assuming your site looks like some kind of average of the top 500 sites. And his conclusion is much more positive than most of the 3rd party coverage of it: "I believe SPDY is still awesome, and is a step in the right direction. This study and its conclusions do not mean we should stop working on SPDY, but rather that we should work on it more, and make it even faster."
  - JulianMorrison 14y ago
    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.
  - youngtaff 14y ago
    Guy does know what's talking about but there are some limitations to his tests - which to be fair he's pretty open about in the post. The biggest challenge is optimising for SPDY is different to optimising for HTTP and so many of the test sites may have behaviours that aren't optimal for SPDY. In addition to Google, Facebook and Twitter are/have deploying SPDY so I think we can be sure it has benefits.

jsnell 14y ago

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 clients and servers.

reidrac 14y ago
I agree. Besides they are doing it "secretly" in a public repository.

deleted 14y ago

[deleted]

latitude 14y ago

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 design a TCP clone. [ EDIT ] That said, there is a fundamental problem with TCP, when it's used for carrying secure connections. Since TCP acts as a pure transport protocol, it has no per-packet authentication and so any connection can be trivially DoS'd with a single fake FIN or RST packet. There are ways to solve this, e.g. by reversing the TCP and security layers and running TCP over ESP-over-UDP or TLS-over-UDP (OpenVPN protocol). This requires either writing a user-space TCP library or doing some nasty tunneling at the kernel level, but even as cumbersome as this is, it's still not a reason enough to re-invent the wheel. Also, if you want compression, it's readily available in TLS or as a part of IPsec stack (IPcomp). If you want FEC, same thing - just add a custom transform to TLS and let the client and server negotiate if to use it or not. I mean, every network programmer invents a protocol or two in his lifetime. It's like a right of passage and it's really not a big deal. Unless it ends up attached to a brand name, in which case it starts attracting snarky remarks like this one :)

xyzzy123 14y ago
I agree with your original point, but none of the stuff after [EDIT] makes much sense to me. "Since TCP acts as a pure transport protocol, it has no per-packet authentication info and so any connection can be trivially DoS'd with a single fake FIN or RST packet." I guess you mean if you're sharing medium or your adversary has MITM? You're generally screwed for DoS in that scenario anyway, no matter what encryption thingy you use. Otherwise, any modern TCP stack should be able to reject blind FINs or RSTs as out-of-sequence. Generally, the reason people avoid TCP-over-TCP is not DoS, but basically "timer fights", as per: http://sites.inka.de/~W1011/devel/tcp-tcp.html http://sites.inka.de/~W1011/devel/tcp-tcp.html. That said, everything-over SSL is still popular for practical reasons, such as clientless VPNs which need to work around proxies, firewalls etc.
- latitude 14y ago

advm 14y ago

This is more than merely UDP with encryption. Rather, this seems to be a reliable stream protocol that aimed at dethroning TCP. I don't think it intends to replace UDP. If anything, I would describe it as a user space replacement for TCP. It uses UDP, yes, but that's because UDP is about as close as you can get to IP at the user level. It's about time, too. Certainly user-level substitutes for TCP are not a new idea (I've worked a good deal with UDT), but this the first one to my knowledge that has the weight of something like Google behind it. There are a lot of advantages to doing this as the user level with UDP as well. Not needing to install a kernel module, for one. But also P2P rendezvous connections through NAT with UDP (we wouldn't even need to wait for router manufacturers to adopt anything), better control over protocol options without going through the kernel, custom congestion control algorithms, finer control over buffers (mmap'd files as buffer for file transfers anyone?), etc. I'd much rather see this at the kernel level, but TCP as it's implemented on most systems has too many issues on modern networks, and most acceptable user-level solutions (ugh, parallel streams) are really terrible hacks. If Google does it right, maybe it'll force OS developers to wake up and rethink the increasingly clunky and antiquated BSD sockets API that is the source of many of TCP's woes and finally modernize the network stack for the fiber era.

anonymfus 14y ago
>If Google does it right, maybe it'll force OS developers to wake up and rethink the increasingly clunky and antiquated BSD sockets API that is the source of many of TCP's woes and finally modernize the network stack for the fiber era. WinRT don't ever has BSD sockets.
X-Istence 14y ago
What exactly about the BSD sockets API makes it a source of TCP's many woes? What woes are you talking about? Also, why do we want to re-implement TCP in user space, when it still needs to traverse the kernel as a UDP packet, this doesn't have any of the benefits that netmap or PF_RING for example bring to the table where the software is doing the full stack and thus there is less latency involved. QUIC as it currently stands will be sitting on top of UDP, so all packets traverse the kernel, get dumped to user space, user space parses it, and sends packets back, as UDP. All that extra copying, when with TCP in the kernel the kernel would be responsible for reassembling packets, would be responsible for ACK'ing packets, and stuff like that. Also, mmap'd files as buffer for file transfers ... you are going to have to explain that one. There are already various zero copy mechanisms for sending files, such as sendfile(). As for new congestion control algorithms, great, sounds fantastic, but how much more of a nightmare is it going to be to get the parties to agree on a congestion control mechanism? We already have that problem now ... Sorry, but I see a whole lot of complaining without any real data or information to back it up. [[citation needed]].

exDM69 14y ago

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 work on top of UDP? There must be a reason for this. What about multicast?

rumcajz 14y ago
Why not use DCCP then?
- morsch 14y ago
  Is DCCP widely used by anyone?
  - rthomas6 14y ago
    Is QUIC widely used by anyone?
popee 14y ago
UDP doesn't have any guarantee that packet is received. If you stream video that can handle few lost packet it is ok, but if you need reliability than you need TCP. So, it's kind of programmer decision what to use. In reality there should be protocol that is lightweight and somewhere in between TCP and UDP (from personal experience). I haven't read anything about this new google protocol, but i'm not sure if they are trying to do that. Well, maybe i should go and read it >:-)
chetanahuja 14y ago
"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.

jacob019 14y ago

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.

AnthonyMouse 14y ago
http://www.ietf.org/rfc/rfc4303.txt http://www.ietf.org/rfc/rfc4303.txt http://www.ietf.org/rfc/rfc4347.txt http://www.ietf.org/rfc/rfc4347.txt
popee 14y ago
It's possible: DTLS. Also CISCO uses UDP for their VPN solutions so go figure.
- zobzu 14y ago
  Not Invented Here. Google wants control, IMO. I'd be interested in their reasons for not using DTLS, or improving DTLS. They actually use it for WebRTC.
jacob019 14y ago
come to think of it OpenVPN uses UDP also, and that's considered quite secure. So what kind of encryption are they using? Rolling their own sounds scary.

beagle3 14y ago

Hopefully they'd take a lot from djb NaCl ( http://nacl.cr.yp.to/ http://nacl.cr.yp.to/ , which predates Google's NaCl and is unrelated). Transport security, endpoint multiplexing and endpoint mobility done right.

pjscott 14y ago
Good news! Their crypto stuff looks pretty reasonable. Key exchange uses ECDH with either the P-256 or curve25519 polynomials. Once the session key is established, it's encrypted with AES-128 and authenticated with either GCM or HMAC-SHA256. None of this is implemented yet, but it's at least cause for hope.

popee 14y ago

Hey, what happened to SCTP?

wmf 14y ago
SCTP is DOA since Windows doesn't implement it and it doesn't pass through NATs. WebRTC DataChannel is SCTP over DTLS over UDP, though.
matthiasl 14y ago
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.)

chetanahuja 14y ago

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.

benth 14y ago

Curious how it compares with SCTP over DTLS over UDP (which WebRTC uses).