12 ms·

QUIC – Will It Replace TCP/IP?

103 points by RMPR 7y ago

mmm_grayons 7y ago
Nah, I think it won't. 1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense. 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement. By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why. [0]: https://tools.ietf.org/html/draft-ietf-quic-recovery-12#section-4 https://tools.ietf.org/html/draft-ietf-quic-recovery-12#sect...
- rakoo 7y ago
  1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ? 2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS
  - dragontamer 7y ago
    > nothing is worse off if it is encrypted Performance and power consumption of low-end devices.
    - Wowfunhappy 7y ago
      And particularly embedded devices. Just because we can make very fast cpu's nowadays doesn't mean that every cpu is that fast.
      - stingraycharles 7y ago
        Yup I work with a lot of industrial IoT companies. QUIC will not replace TCP/IP there any time soon.
  - moomin 7y ago
    The thing is, if you run Istio there’s a standard setting for getting it to do the TLS for you. Indeed, half the features of istio wouldn’t work if you did the TLS yourself. So you kind of need plaintext protocols even if you’re only running them internally within a single (logical) machine.
    - jupp0r 7y ago
      Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.
      - moomin 7y ago
        You're right, but it would provide a permanent use for regular old TCP connections (which means the answer to the article's question would still be no).
        jupp0r 7y ago
        Good point!
  - nickthemagicman 7y ago
    I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.
    - dochtman 7y ago
      QUIC nicely abstracts the crypto from the transport protocol so you could easily plug in different crypto implementations. For example, someone already did a QUIC with Noise implementation.
  - deleted 7y ago
    [deleted]
  - pawalt 7y ago
    "nothing is worse off if it is encrypted" is a pretty big oversimplification. Layer 7 proxies and firewalls frequently use packet data to make more intelligent decisions about where to route packets, whether to drop packets, whether to modify packets, etc.
    - falcor84 7y ago
      I don't see how this refutes the argument. These proxies and firewalls could just have a copy of the decryption key, no? (And if whoever is setting them up doesn't have access to the key, then they probably shouldn't be inspecting the packets anyway) I'd say that the bigger argument against "nothing is worse off if it is encrypted" is that this takes precious time.
    - thayne 7y ago
      not to mention, that while encryption is cheaper than it was, it still isn't free. And managing certificates and CRLs, while much easier than it used to be is still not trivial, especially on an internal network or localhost.
    - kevin_thibedeau 7y ago
      These are the same agents that prevented SCTP from being usable outside of private networks. We need to stop catering for them.
  - Kuinox 7y ago
    Why not ? Because it require a lot of CPU power... A lot.
  - hackmiester 7y ago
    If everything on the Internet ends up encrypted, I will call you to troubleshoot the problematic SIP calls. ;) eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.
    - falcor84 7y ago
      Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)
  - bobbiechen 7y ago
    This is one of the examples of what not to do from "End-to-End Arguments in System Design" (Saltzer, 1984) [1]: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Applications vary in what needs encryption and how that encryption is implemented, so it is better to leave this to them to implement; otherwise, all applications may suffer the cost of your protocol's encryption implementation without getting the actual encryption that they need. [1] http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf
  - tialaramex 7y ago
    QUIC does use TLS, but since TLS sits on top of TCP and QUIC replaces TCP entirely they wire TLS directly into their protocol rather than it resting on top as it does with TCP. Technically this was fairly complicated to do, but cryptographically nothing much really changes, except that now more things are encrypted. Now, if your TLS implementation just presents as a shim layer between a TCP port and your socket code then this may mean a significant rewrite, but again that's not about cryptography it's just an engineering problem.
  - pnako 7y ago
    In many cases you don't want the traffic to be encrypted, so you can audit what's happening. This is common in corporate environments (banks, etc.) It's good to know what e.g. stock traders are talking about so you can monitor for insider trading and market manipulation. If they use the encrypted Googleprotocol using the Googlebrowser to connect to the Googleweb, you can't do that. I get that it's important for Google to encrypt what happens between their browser and their servers, but the rest of the world has different requirements.
- fart_ratty 7y ago
  Other than captive portals, what would be harmed by adding encryption. It might not provide benefit but is there any downside? What is using TCP that wouldn't work with QUIC?
- ajrw 7y ago
  The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.
- vasilvv 7y ago
  > By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why. It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring). Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0]. > 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked. [0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-for-open-source.html http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...
  - thayne 7y ago
    If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.
    - tialaramex 7y ago
      You can do TLS with shared keys. The rest of this comment describes the situation in TLS 1.3 since earlier versions are not used in QUIC and future versions don't exist yet. If you want Forward Secrecy you still need to do the DH steps so that you'll get unique session keys, but you don't need a certificate since your mutual knowledge of the shared key is sufficient. If you don't need Forward Secrecy (pro tip: You actually do, but I can't stop you) then you can skip DH and just go straight to the main course.
      - thayne 7y ago
        > you don't need a certificate since your mutual knowledge of the shared key is sufficient How would you do that? The API's I've seen for TLS all require the use of certificates.
- Ericson2314 7y ago
  QUIC is itself layered post Google, so 1 and 2 don't apply.
doublerabbit 7y ago
As it seems like we won't be rolling out IPv6 anytime soon, why would this replace TCP?
- EdSchouten 7y ago
  Unlike IPv6, QUIC requires (almost?) no buy-in from network operators/ISPs.
  - Carpetsmoker 7y ago
    Which is pretty much the entire point of QUIC, since updating gazillions of network appliances to support newer versions of TCP is rather hard and will take decades, if not longer. With QUIC, that's no longer needed.
- fulafel 7y ago
  https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
  - doublerabbit 7y ago
    Handy but Germany is the only country that has 50% IPv6. I am still calling it's not going to be rolled out any time.
    - fulafel 7y ago
      After all the equipment investment and adding support to all the software, people are going to say "just forget it" and go back to v4-only and piling CGNAT style hacks on top of each other in an endless tower of babel? Possible, but would be quite a dystopia. IPv6 transition mechanisms were designed for a long coexistence of both v4 & v6, not that different from QUIC vs HTTP :)
spdegabrielle 7y ago
Nope
tyingq 7y ago
They would need some incentives to make it work in big orgs that have MITM and/or restrictive firewalls.
- JoshTriplett 7y ago
  Ideally those incentives would be combined with disincentives for those organizations to continue breaking the web. A combination of the two seems more likely to be successful than either alone.
  - kazen44 7y ago
    tcp != the web. Also, most firewall don't break TCP, they break HTTP(S) because they want levels of control.
    - JoshTriplett 7y ago
      I wasn't referring to TCP, and the web isn't purely TCP. UDP and ICMP are important, and some firewalls just block them completely.
    - tyingq 7y ago
      The corporate firewalls I'm talking about do often break UDP. Because chrome races QUIC/UDP with HTTP(S)/TCP, the big corps are often unaware it's broken. Chrome works around it.
      - azinman2 7y ago
        So it doubles the traffic?
        tyingq 7y ago
        Initial "connection" packets, yes. (yes, I get UDP is connectionless, but I assume you know what I mean)
        7y ago
xxpor 7y ago
HTTP isn't the only L7 protocol.
- kazen44 7y ago
  this. Many people here seem to not realize that TCP is used for much more then just http/https. Quick might be nice for web traffic, but i see little reason to use it as an underlay for BGP for instance.
  - CameronNemo 7y ago
    I have not thought much about how BGP would react to QUIC as transport, would be curious to hear your thoughts on the matter.
    - kazen44 7y ago
      for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reassemble tcp packets at line speed. In terms of BGP and quic as a transport. As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration. Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.
      - fart_ratty 7y ago
        BGP not having security has caused many problems.
        CameronNemo 7y ago
        BGP has some security. It's called rpki and the industry is slowly adopting it.
        allarm 7y ago
ChrisMarshallNY 7y ago
"Betteridge's law of headlines" applies, I suspect... We're having difficulty getting IPv6 up and going, and that's 100% supported by everyone.
londons_explore 7y ago
QUIC has a substantial CPU overhead, due to lack of hardware or kernel acceleration. QUIC deployed worldwide might cost us a power station or two...
- fiberoptick 7y ago
  And emerging QUIC acceleration technology is likely to be stifled by intellectual property laws. Intel has already filed (in 2019) for a European patent that seems to claim inventorship of the generic concept of hardware offloading (as it applies to QUIC) https://data.epo.org/publication-server/pdf-document?pn=3541044&ki=A1&cc=EP&pd=20190918 https://data.epo.org/publication-server/pdf-document?pn=3541...
  - spritecranberry 7y ago
    How ironic. If you listened to HN, you'd think that Europe was so pro-consumer, unlike those silly Americans who keep granting Stupid Patents to Evil Bigcorps.
  - stainforth 7y ago
    Is this instance of a patent good or bad?
    - jeltz 7y ago
      Bad, since it is an obvious idea that any engineer in the field could come up with.
    - fiberoptick 7y ago
      Bad, in my view. (Although I am not a lawyer, and would definitely appreciate input from one here!) Hardware offload of a network protocol is an extremely generic concept and this patent seems to describe that concept (without any kind of novel mechanism or implementation details).
- drewg123 7y ago
  In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose: - sendfile - ktls - TSO Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.
_jal 7y ago
> Will It Replace TCP/IP? No. This as been another episode of "simple answers to stupid questions".
- CameronNemo 7y ago
  Also Betteridge's law of headlines.
- thomashusa 7y ago
  Betteridge's law of headlines strikes again
- rektide 7y ago
  Should it though? Quite probably! I see two main ways to look at this question: will QUIC replace TCP as a go to protocol for developing atop of? The other interpretation is, will QUIC replace all TCP ever written? No, indeed, likely not.
- takeda 7y ago
  Just the title itself shows author has no idea what the hell he is talking about TCP/IP != TCP TCP/IP refers to the entire stack that Internet is build on, the UDP is actually part of TCP/IP (it was added later for use cases where low latency was important, like telephony). He probably meant just TCP, but that's still "no".
  - emmelaich 7y ago
    TCP/IP metonymically refers to IP. My guess is that just saying "IP" is too short. (And ambiguous - tee hee)
- dang 7y ago
  Maybe so, but please don't post unsubstantive comments to Hacker News.
OrangeMango 7y ago
I've been told in the recent past that there is so much old internet infrastructure equipment that only knows UDP and TCP that any other protocol will fail to meaningfully catch on. This equipment will drop anything that isn't TCP or UDP and until it's replaced you will have a lot of trouble.
- matthewmacleod 7y ago
  QUIC operates over UDP. That’s really why this question is worth asking.
  - m0th87 7y ago
    Yes, though this is arguably a big reason why SCTP didn't take off, which is similar to QUIC in a lot of ways (there is SCTP over UDP, but it was a second class citizen until WebRTC.)
acheron 7y ago
I see no problems in Google continuing to replace basic protocols. In fact, why not get rid of the open Internet altogether and just use all Google products all the time? It'll be like the good old days of AOL.
- mmm_grayons 7y ago
  The fact that it originated in Google doesn't make it some kind of proprietary protocol. It's subject to the usual IETF process, just like others, and is a public draft: https://tools.ietf.org/html/draft-ietf-quic-transport-22 https://tools.ietf.org/html/draft-ietf-quic-transport-22
  - ocdtrekkie 7y ago
    My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions between gQUIC and QUIC as being prepared for standardization, but it seems unlikely the IETF has the ability to say, discourage shifting a huge portion of Internet traffic to a Google-based protocol. Under these sorts of arrangements, standards bodies have little choice but to rubber stamp the company's interests or face irrelevance. On the HTML/JS side, we often see the same problem with the W3C. The web's baseline protocols are slowly being replaced by protocols designed to favor the interests of a single company without enough meaningful checks on that. I do not really think it's an IETF/W3C problem though, so much as a economic power one.
    - dullgiulio 7y ago
      On the other hand, a protocol that has been battle-tested and proven to work in the real world makes it much easier for a standards body to accept: there is less risk of making a standard that nobody uses. The important point is not to make proprietary deviations to the standard. Of course, Google is guilty here (Chrome-only web service, mostly) but when it comes to network protocols they haven't behaved badly, especially when others were pushing for HTTP/2 without TLS and other harmful ideas...
chirau 7y ago
Quick answer for QUIC... No, it won't replace TCP/IP
deleted 7y ago
[deleted]
suncore 7y ago
I think it might actually succeed to replace TCP. There are a bunch of benefits. There is a great video here about it that you should also watch before passing summary judgement: https://www.youtube.com/watch?v=idViw4anA6E https://www.youtube.com/watch?v=idViw4anA6E
- RMPR 7y ago
  On the flip side there are no multi path implementation for QUIC while Multi Path TCP is being merged since Linux 5.6[1], just for this I think it's won't be simple as your comment may lead to think. [1]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Starts-Multipath-TCP https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....
downerending 7y ago
My bank account awaits a whole new raft of security problems for me to be paid to support/fix.
bregma 7y ago
So, something layered on top of UDP layered on top of IP is going to replace IP? Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines?
- coder543 7y ago
  > Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines? What's that quote about throwing stones while living in glass houses? The headline says nothing about replacing IP. It's talking about replacing "TCP/IP", which is neither "TCP or IP" nor "TCP and IP". In this case, it's asking whether TCP/IP will be replaced with a protocol (QUIC) that is built on UDP/IP. IP is definitely still involved. As with the classic XKCD reference for this situation (https://xkcd.com/927/ https://xkcd.com/927/), I find it very unlikely that it will "replace" TCP/IP in the sense of TCP/IP disappearing altogether, but it certainly stands a chance of replacing TCP/IP in many specific applications that test it and find it beneficial.
  - takeda 7y ago
    TCP/IP != TCP TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of. If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about. [1] https://en.wikipedia.org/wiki/Internet_protocol_suite https://en.wikipedia.org/wiki/Internet_protocol_suite
    - deleted 7y ago
      [deleted]
    - coder543 7y ago
      That's not the singular definition of TCP/IP, as you're seemingly so intent on believing. TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically. Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and I both normally define it.[2] Cloudflare also (logically) refers to UDP/IP as a concept,[3][4] which further supports the notion that TCP/IP is not singularly referring to the whole internet protocol suite. I understand that people do sometimes use TCP/IP to refer to the internet protocol suite as a whole, including UDP. I've seen it before. That doesn't make it the only (or most logical) definition of the term. It's certainly not the definition the authors of this webinar intended you to use when reading the title. In the tech world, many terms are overloaded with multiple definitions. This isn’t an uncommon situation by any means. > this title makes me believe the author doesn't know what he is talking about Because the authors are choosing to use a different common definition of TCP/IP, you think they're the ignorant ones because you don't know that common definition? Or because you're only willing to read the title in the way that makes it seem the most nonsensical? I left my first reply because the author of that comment was being so unnecessarily insulting to the authors, and now you're following up with similar snark, and posting it in multiple places on this topic, when there is no evidence to support that your use of the term is the only valid use of the term. [1]: https://superuser.com/questions/449703/must-tcp-use-ip https://superuser.com/questions/449703/must-tcp-use-ip [2]: https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/ https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/ [3]: https://www.cloudflare.com/learning/ddos/glossary/user-datagram-protocol-udp/ https://www.cloudflare.com/learning/ddos/glossary/user-datag... [4]: https://www.cloudflare.com/learning/ddos/glossary/internet-protocol/ https://www.cloudflare.com/learning/ddos/glossary/internet-p...
davewritescode 7y ago
They're specifically doing QUIC as a way to move TCP to up into the application space so they can iterate more quickly. Ideally, a lot of these concepts could be adopted into TCP stacks eventually.
- swiley 7y ago
  That’s pretty annoying as a user honestly, websockets are difficult enough to deal with.
jasoneckert 7y ago
I don't think it will ever replace TCP/IP. But even if it does, the replacement won't be QUIC.
crazygringo 7y ago
Better framing: Will it replace HTTPS over TCP? Maybe. Mostly. Eventually. (Hopefully?) Will it replace TCP for other purposes? Of course not.
- Rusky 7y ago
  QUIC no longer includes HTTP, so "of course not" is a bit strong. It's easily applicable to a lot more scenarios than HTTPS over TCP.
anfilt 7y ago
The one thing I like about QUIC being more wide spread is that it is making network operators treat UDP traffic more fairly. However, I don't see it replacing TCP, and if anything it's just an other tool to use.
darkr 7y ago
Historically, some of the big problems of running UDP-based services over the internet are related to source spoofing, used in reflection/amplification attacks etc (looking at you, DNS/NTP), which is possible as very few providers carry out source address validation on egress. Looks like QUIC has a nice solution to this, making the impact of source spoofing similar to that of TCP, give or take a few CPU cycles: https://jacobianengineering.com/blog/2016/11/1543/ https://jacobianengineering.com/blog/2016/11/1543/

103 points by RMPR 7y ago

Nah, I think it won't. 1. Not everything needs encryption, so QUIC's built-in TLS doesn't always make sense. 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. These reflect the fact that QUIC is a transport protocol for the WWW more than a TCP replacement. By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why. [0]: https://tools.ietf.org/html/draft-ietf-quic-recovery-12#section-4 https://tools.ietf.org/html/draft-ietf-quic-recovery-12#sect...

rakoo 7y ago
1) Not everything needs encryption, but crucially, nothing is worse off if it is encrypted. Encryption is either useless or better, so why not put it everywhere by default ? 2) QUIC explicitely doesn't use TLS but something different, so indeed, not everything needs TLS
- dragontamer 7y ago
  > nothing is worse off if it is encrypted Performance and power consumption of low-end devices.
  - Wowfunhappy 7y ago
    And particularly embedded devices. Just because we can make very fast cpu's nowadays doesn't mean that every cpu is that fast.
    - stingraycharles 7y ago
      Yup I work with a lot of industrial IoT companies. QUIC will not replace TCP/IP there any time soon.
- moomin 7y ago
  The thing is, if you run Istio there’s a standard setting for getting it to do the TLS for you. Indeed, half the features of istio wouldn’t work if you did the TLS yourself. So you kind of need plaintext protocols even if you’re only running them internally within a single (logical) machine.
  - jupp0r 7y ago
    Istio would not only do TLS, but would also do QUIC for you in the scenario you describe.
    - moomin 7y ago
      You're right, but it would provide a permanent use for regular old TCP connections (which means the answer to the article's question would still be no).
      - jupp0r 7y ago
        Good point!
- nickthemagicman 7y ago
  I like how tcp/ip operates below the encryption layer so encryption schemes can be easily changed.
  - dochtman 7y ago
    QUIC nicely abstracts the crypto from the transport protocol so you could easily plug in different crypto implementations. For example, someone already did a QUIC with Noise implementation.
- deleted 7y ago
  [deleted]
- pawalt 7y ago
  "nothing is worse off if it is encrypted" is a pretty big oversimplification. Layer 7 proxies and firewalls frequently use packet data to make more intelligent decisions about where to route packets, whether to drop packets, whether to modify packets, etc.
  - falcor84 7y ago
    I don't see how this refutes the argument. These proxies and firewalls could just have a copy of the decryption key, no? (And if whoever is setting them up doesn't have access to the key, then they probably shouldn't be inspecting the packets anyway) I'd say that the bigger argument against "nothing is worse off if it is encrypted" is that this takes precious time.
  - thayne 7y ago
    not to mention, that while encryption is cheaper than it was, it still isn't free. And managing certificates and CRLs, while much easier than it used to be is still not trivial, especially on an internal network or localhost.
  - kevin_thibedeau 7y ago
    These are the same agents that prevented SCTP from being usable outside of private networks. We need to stop catering for them.
- Kuinox 7y ago
  Why not ? Because it require a lot of CPU power... A lot.
- hackmiester 7y ago
  If everything on the Internet ends up encrypted, I will call you to troubleshoot the problematic SIP calls. ;) eta: Or at least the ones where one end is a $30 phone someone bought off of Amazon that has no vendor support and the device has no CLI or debug tools available.
  - falcor84 7y ago
    Please sign me up for this future where every phone has to support end-to-end encryption in order to connect to the network :)
- bobbiechen 7y ago
  This is one of the examples of what not to do from "End-to-End Arguments in System Design" (Saltzer, 1984) [1]: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Applications vary in what needs encryption and how that encryption is implemented, so it is better to leave this to them to implement; otherwise, all applications may suffer the cost of your protocol's encryption implementation without getting the actual encryption that they need. [1] http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf http://pages.cs.wisc.edu/~bart/739/papers/end-to-end.pdf
- tialaramex 7y ago
  QUIC does use TLS, but since TLS sits on top of TCP and QUIC replaces TCP entirely they wire TLS directly into their protocol rather than it resting on top as it does with TCP. Technically this was fairly complicated to do, but cryptographically nothing much really changes, except that now more things are encrypted. Now, if your TLS implementation just presents as a shim layer between a TCP port and your socket code then this may mean a significant rewrite, but again that's not about cryptography it's just an engineering problem.
- pnako 7y ago
  In many cases you don't want the traffic to be encrypted, so you can audit what's happening. This is common in corporate environments (banks, etc.) It's good to know what e.g. stock traders are talking about so you can monitor for insider trading and market manipulation. If they use the encrypted Googleprotocol using the Googlebrowser to connect to the Googleweb, you can't do that. I get that it's important for Google to encrypt what happens between their browser and their servers, but the rest of the world has different requirements.
fart_ratty 7y ago
Other than captive portals, what would be harmed by adding encryption. It might not provide benefit but is there any downside? What is using TCP that wouldn't work with QUIC?
ajrw 7y ago
The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.
vasilvv 7y ago
> By the way, does anyone know why QUIC specifically put NewReno as its official congestion control [0]? Different environments benefit from different algorithms so I don't see why. It's a "reasonable default", in the sense that it normally works quite well, and is easy to implement. The dangerous thing about congestion control is that it's really easy to get it wrong and not notice (as noticing requires performance testing and monitoring). Google QUIC uses BBR on the server side. I wrote the initial version of said BBR implementation, and it took a lot of effort to get it to a production-ready state, so I would not generally recommend writing BBR from scratch. CUBIC is much simpler than BBR, but is also prone to subtle bugs like [0]. > 2. Not everything that needs encryption needs TLS specifically. TLS is not a one-size-fits-all solution. I'm actually curious what use cases you have in mind. TLS definitely does not cover 100% of all possible cases, but I've seen a surprising number of cases where people rolled their own thing when using (D)TLS would have just worked. [0] http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-for-open-source.html http://bitsup.blogspot.com/2015/09/thanks-google-tcp-team-fo...
- thayne 7y ago
  If you are in a situation where you can have a shared key, TLS, with it's asymmetric handshake is probably overkill.
  - tialaramex 7y ago
    You can do TLS with shared keys. The rest of this comment describes the situation in TLS 1.3 since earlier versions are not used in QUIC and future versions don't exist yet. If you want Forward Secrecy you still need to do the DH steps so that you'll get unique session keys, but you don't need a certificate since your mutual knowledge of the shared key is sufficient. If you don't need Forward Secrecy (pro tip: You actually do, but I can't stop you) then you can skip DH and just go straight to the main course.
    - thayne 7y ago
      > you don't need a certificate since your mutual knowledge of the shared key is sufficient How would you do that? The API's I've seen for TLS all require the use of certificates.
Ericson2314 7y ago
QUIC is itself layered post Google, so 1 and 2 don't apply.

doublerabbit 7y ago

As it seems like we won't be rolling out IPv6 anytime soon, why would this replace TCP?

EdSchouten 7y ago
Unlike IPv6, QUIC requires (almost?) no buy-in from network operators/ISPs.
- Carpetsmoker 7y ago
  Which is pretty much the entire point of QUIC, since updating gazillions of network appliances to support newer versions of TCP is rather hard and will take decades, if not longer. With QUIC, that's no longer needed.
fulafel 7y ago
https://www.google.com/intl/en/ipv6/statistics.html https://www.google.com/intl/en/ipv6/statistics.html
- doublerabbit 7y ago
  Handy but Germany is the only country that has 50% IPv6. I am still calling it's not going to be rolled out any time.
  - fulafel 7y ago
    After all the equipment investment and adding support to all the software, people are going to say "just forget it" and go back to v4-only and piling CGNAT style hacks on top of each other in an endless tower of babel? Possible, but would be quite a dystopia. IPv6 transition mechanisms were designed for a long coexistence of both v4 & v6, not that different from QUIC vs HTTP :)

spdegabrielle 7y ago

Nope

tyingq 7y ago

They would need some incentives to make it work in big orgs that have MITM and/or restrictive firewalls.

JoshTriplett 7y ago
Ideally those incentives would be combined with disincentives for those organizations to continue breaking the web. A combination of the two seems more likely to be successful than either alone.
- kazen44 7y ago
  tcp != the web. Also, most firewall don't break TCP, they break HTTP(S) because they want levels of control.
  - JoshTriplett 7y ago
    I wasn't referring to TCP, and the web isn't purely TCP. UDP and ICMP are important, and some firewalls just block them completely.
  - tyingq 7y ago
    The corporate firewalls I'm talking about do often break UDP. Because chrome races QUIC/UDP with HTTP(S)/TCP, the big corps are often unaware it's broken. Chrome works around it.
    - azinman2 7y ago
      So it doubles the traffic?
      - tyingq 7y ago
        Initial "connection" packets, yes. (yes, I get UDP is connectionless, but I assume you know what I mean)
      - 7y ago

xxpor 7y ago

HTTP isn't the only L7 protocol.

kazen44 7y ago
this. Many people here seem to not realize that TCP is used for much more then just http/https. Quick might be nice for web traffic, but i see little reason to use it as an underlay for BGP for instance.
- CameronNemo 7y ago
  I have not thought much about how BGP would react to QUIC as transport, would be curious to hear your thoughts on the matter.
  - kazen44 7y ago
    for one, not having hardware acceleration makes quic very slow compared to TCP. This is especially a problem on firewalls, as they need to tear apart and reassemble tcp packets at line speed. In terms of BGP and quic as a transport. As far as i know, quic is not backwards compatible with TCP, and having two different transport protocols for the routing protocols that ties the internet together would be problematic in terms of migration. Im not entirely up to speed in terms of how quick would handle MSS size, but this could pose a problem in some situations.
    - fart_ratty 7y ago
      BGP not having security has caused many problems.
      - CameronNemo 7y ago
        BGP has some security. It's called rpki and the industry is slowly adopting it.
      - allarm 7y ago

ChrisMarshallNY 7y ago

"Betteridge's law of headlines" applies, I suspect... We're having difficulty getting IPv6 up and going, and that's 100% supported by everyone.

londons_explore 7y ago

QUIC has a substantial CPU overhead, due to lack of hardware or kernel acceleration. QUIC deployed worldwide might cost us a power station or two...

fiberoptick 7y ago
And emerging QUIC acceleration technology is likely to be stifled by intellectual property laws. Intel has already filed (in 2019) for a European patent that seems to claim inventorship of the generic concept of hardware offloading (as it applies to QUIC) https://data.epo.org/publication-server/pdf-document?pn=3541044&ki=A1&cc=EP&pd=20190918 https://data.epo.org/publication-server/pdf-document?pn=3541...
- spritecranberry 7y ago
  How ironic. If you listened to HN, you'd think that Europe was so pro-consumer, unlike those silly Americans who keep granting Stupid Patents to Evil Bigcorps.
- stainforth 7y ago
  Is this instance of a patent good or bad?
  - jeltz 7y ago
    Bad, since it is an obvious idea that any engineer in the field could come up with.
  - fiberoptick 7y ago
    Bad, in my view. (Although I am not a lawyer, and would definitely appreciate input from one here!) Hardware offload of a network protocol is an extremely generic concept and this patent seems to describe that concept (without any kind of novel mechanism or implementation details).
drewg123 7y ago
In estimates I've done, in its current un-accelerated state, it would at least triple the CPU cost per byte served on our CDN workload. We basically lose: - sendfile - ktls - TSO Its like stepping into a time machine and going back to the mid 90s. To send data with QUIC, we have to get byes from kernel into userspace, encrypt them in userspace, and then write them back to the kernel, where they travel down to the NIC an MTU at a time. Ugh.

_jal 7y ago

> Will It Replace TCP/IP? No. This as been another episode of "simple answers to stupid questions".

CameronNemo 7y ago
Also Betteridge's law of headlines.
thomashusa 7y ago
Betteridge's law of headlines strikes again
rektide 7y ago
Should it though? Quite probably! I see two main ways to look at this question: will QUIC replace TCP as a go to protocol for developing atop of? The other interpretation is, will QUIC replace all TCP ever written? No, indeed, likely not.
takeda 7y ago
Just the title itself shows author has no idea what the hell he is talking about TCP/IP != TCP TCP/IP refers to the entire stack that Internet is build on, the UDP is actually part of TCP/IP (it was added later for use cases where low latency was important, like telephony). He probably meant just TCP, but that's still "no".
- emmelaich 7y ago
  TCP/IP metonymically refers to IP. My guess is that just saying "IP" is too short. (And ambiguous - tee hee)
dang 7y ago
Maybe so, but please don't post unsubstantive comments to Hacker News.

OrangeMango 7y ago

I've been told in the recent past that there is so much old internet infrastructure equipment that only knows UDP and TCP that any other protocol will fail to meaningfully catch on. This equipment will drop anything that isn't TCP or UDP and until it's replaced you will have a lot of trouble.

matthewmacleod 7y ago
QUIC operates over UDP. That’s really why this question is worth asking.
- m0th87 7y ago
  Yes, though this is arguably a big reason why SCTP didn't take off, which is similar to QUIC in a lot of ways (there is SCTP over UDP, but it was a second class citizen until WebRTC.)

acheron 7y ago

I see no problems in Google continuing to replace basic protocols. In fact, why not get rid of the open Internet altogether and just use all Google products all the time? It'll be like the good old days of AOL.

mmm_grayons 7y ago
The fact that it originated in Google doesn't make it some kind of proprietary protocol. It's subject to the usual IETF process, just like others, and is a public draft: https://tools.ietf.org/html/draft-ietf-quic-transport-22 https://tools.ietf.org/html/draft-ietf-quic-transport-22
- ocdtrekkie 7y ago
  My concern with Google engaging standards bodies is that if Google is the monopoly on all sides, the standards body has little choice but to eventually accept it: Google didn't wait for an IETF standard to implement it in both their monopoly-scale browser and their monopoly-scale services and then declare that a large portion of Internet traffic was now already using QUIC. I am aware there have been some revisions between gQUIC and QUIC as being prepared for standardization, but it seems unlikely the IETF has the ability to say, discourage shifting a huge portion of Internet traffic to a Google-based protocol. Under these sorts of arrangements, standards bodies have little choice but to rubber stamp the company's interests or face irrelevance. On the HTML/JS side, we often see the same problem with the W3C. The web's baseline protocols are slowly being replaced by protocols designed to favor the interests of a single company without enough meaningful checks on that. I do not really think it's an IETF/W3C problem though, so much as a economic power one.
  - dullgiulio 7y ago
    On the other hand, a protocol that has been battle-tested and proven to work in the real world makes it much easier for a standards body to accept: there is less risk of making a standard that nobody uses. The important point is not to make proprietary deviations to the standard. Of course, Google is guilty here (Chrome-only web service, mostly) but when it comes to network protocols they haven't behaved badly, especially when others were pushing for HTTP/2 without TLS and other harmful ideas...

chirau 7y ago

Quick answer for QUIC... No, it won't replace TCP/IP

deleted 7y ago

[deleted]

suncore 7y ago

I think it might actually succeed to replace TCP. There are a bunch of benefits. There is a great video here about it that you should also watch before passing summary judgement: https://www.youtube.com/watch?v=idViw4anA6E https://www.youtube.com/watch?v=idViw4anA6E

RMPR 7y ago
On the flip side there are no multi path implementation for QUIC while Multi Path TCP is being merged since Linux 5.6[1], just for this I think it's won't be simple as your comment may lead to think. [1]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Starts-Multipath-TCP https://www.phoronix.com/scan.php?page=news_item&px=Linux-5....

downerending 7y ago

My bank account awaits a whole new raft of security problems for me to be paid to support/fix.

bregma 7y ago

So, something layered on top of UDP layered on top of IP is going to replace IP? Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines?

coder543 7y ago
> Maybe the marketing department needs to hire someone who knows the fundamentals to write the headlines? What's that quote about throwing stones while living in glass houses? The headline says nothing about replacing IP. It's talking about replacing "TCP/IP", which is neither "TCP or IP" nor "TCP and IP". In this case, it's asking whether TCP/IP will be replaced with a protocol (QUIC) that is built on UDP/IP. IP is definitely still involved. As with the classic XKCD reference for this situation (https://xkcd.com/927/ https://xkcd.com/927/), I find it very unlikely that it will "replace" TCP/IP in the sense of TCP/IP disappearing altogether, but it certainly stands a chance of replacing TCP/IP in many specific applications that test it and find it beneficial.
- takeda 7y ago
  TCP/IP != TCP TCP/IP is a name for the Internet Protocol Suite[1], which UDP ironically is part of. If someone talks about one protocol replacing another they should be aware of this distinction, and this title makes me believe the author doesn't know what he is talking about. [1] https://en.wikipedia.org/wiki/Internet_protocol_suite https://en.wikipedia.org/wiki/Internet_protocol_suite
  - deleted 7y ago
    [deleted]
  - coder543 7y ago
    That's not the singular definition of TCP/IP, as you're seemingly so intent on believing. TCP and IP are separable[1], so it logically makes sense to have "TCP/IP" mean that you're using them together, rather than meaning some arbitrary suite of protocols that may have nothing to do with TCP specifically. Cloudflare, which is obviously a major industry player, defines TCP/IP the same way that the webinar authors and I both normally define it.[2] Cloudflare also (logically) refers to UDP/IP as a concept,[3][4] which further supports the notion that TCP/IP is not singularly referring to the whole internet protocol suite. I understand that people do sometimes use TCP/IP to refer to the internet protocol suite as a whole, including UDP. I've seen it before. That doesn't make it the only (or most logical) definition of the term. It's certainly not the definition the authors of this webinar intended you to use when reading the title. In the tech world, many terms are overloaded with multiple definitions. This isn’t an uncommon situation by any means. > this title makes me believe the author doesn't know what he is talking about Because the authors are choosing to use a different common definition of TCP/IP, you think they're the ignorant ones because you don't know that common definition? Or because you're only willing to read the title in the way that makes it seem the most nonsensical? I left my first reply because the author of that comment was being so unnecessarily insulting to the authors, and now you're following up with similar snark, and posting it in multiple places on this topic, when there is no evidence to support that your use of the term is the only valid use of the term. [1]: https://superuser.com/questions/449703/must-tcp-use-ip https://superuser.com/questions/449703/must-tcp-use-ip [2]: https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/ https://www.cloudflare.com/learning/ddos/glossary/tcp-ip/ [3]: https://www.cloudflare.com/learning/ddos/glossary/user-datagram-protocol-udp/ https://www.cloudflare.com/learning/ddos/glossary/user-datag... [4]: https://www.cloudflare.com/learning/ddos/glossary/internet-protocol/ https://www.cloudflare.com/learning/ddos/glossary/internet-p...

davewritescode 7y ago

They're specifically doing QUIC as a way to move TCP to up into the application space so they can iterate more quickly. Ideally, a lot of these concepts could be adopted into TCP stacks eventually.

swiley 7y ago
That’s pretty annoying as a user honestly, websockets are difficult enough to deal with.

jasoneckert 7y ago

I don't think it will ever replace TCP/IP. But even if it does, the replacement won't be QUIC.

crazygringo 7y ago

Better framing: Will it replace HTTPS over TCP? Maybe. Mostly. Eventually. (Hopefully?) Will it replace TCP for other purposes? Of course not.

Rusky 7y ago
QUIC no longer includes HTTP, so "of course not" is a bit strong. It's easily applicable to a lot more scenarios than HTTPS over TCP.

anfilt 7y ago

The one thing I like about QUIC being more wide spread is that it is making network operators treat UDP traffic more fairly. However, I don't see it replacing TCP, and if anything it's just an other tool to use.

darkr 7y ago

Historically, some of the big problems of running UDP-based services over the internet are related to source spoofing, used in reflection/amplification attacks etc (looking at you, DNS/NTP), which is possible as very few providers carry out source address validation on egress. Looks like QUIC has a nice solution to this, making the impact of source spoofing similar to that of TCP, give or take a few CPU cycles: https://jacobianengineering.com/blog/2016/11/1543/ https://jacobianengineering.com/blog/2016/11/1543/