9 ms·

What are the proposed benefits of QUIC? May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over

What are the proposed benefits of QUIC? May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.

Jonnax 6y ago
Here's a comparison of HTTP2 vs HTTP3 (QUIC) from Cloudflare: https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/
jsnell 6y ago
Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades and by preventing middleboxes from messing up flows when new options are introduced.
- the8472 6y ago
  > working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrades from OS upgrades This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
  - infogulch 6y ago
    Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
    - simias 6y ago
      I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.
      - skissane 6y ago
        > I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
        tialaramex 6y ago
        People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
        skissane 6y ago
        That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
    - saagarjha 6y ago
      Not to bring up the usual debate again, but anyone trying to sell you one side of the static/dynamic debate without acknowledging that this is not a cut-and-dry issue is doing you a disservice and it is probably in your best interest to not listen to them.
- jlokier 6y ago
  > solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades QUIC explicitly addresses "network middlebox ossification" of TCP, by encrypting almost everything about the protocol. This type of ossification is where the network blocks or corrupts any deviations that it doesn't recognise but thinks it does. TCP "OS ossification" is a different kind. By itself, this could have been overcome by streaming TCP-in-UDP and amending it from there. Even that is only because of OS APIs. If OSes allowed applications to bind to a TCP port and process the raw packets, applications that want to could implement TCP themselves. If that kind of dual-binding seems strange, I think it's actually more or less what we'll end up with with QUIC in the end: The OS providing QUIC sockets (socket(AF_INET,SOCK_QUIC,...)) to applications that don't care to implement the QUIC stack themselves, while allowing other applications to bind to UDP in the usual way and implement their own application-level QUIC. I think current QUIC solves application vs. OS ossification issues in the short term, allowing things to evolve beyond TCP, but it's a temporary benefit. In time I think we will see QUIC ossify when it's implemented in many applications that don't get updated. Most browsers are updated often. But I'm seeing more obscure applications starting to include QUIC and depend on it (without any TCP fallback even) - leading eventually to hundreds of "hand-written quality" QUIC implementations, all destined to get out of date. Various languages are implementing their own QUIC libraries, and these aren't all going to be maintained the same way. Shipped applications ossify too. That's why I think it'll end up in the OS kernels eventually.
  - jsnell 6y ago
    You're right that the two forms of ossification are distinct, but I'm quite certain that both were driving factors here. Rolling out new TCP options is a decade-long process, and if anything goes wrong with the initial design, once it is shipping you're basically never fixing it. Applications are much easier to update than operating systems, auto-update for the vast majority of users, and for the <1% who don't update the app can always fall back to TCP. (E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.) The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.
uluyol 6y ago
QUIC is TCP+TLS. HTTP is done as a separate layer on top. The benefits are: future protocol evolution (TCP is extremely difficult to change because of middleboxes, QUIC encrypts almost all of the header to stop middleboxes from messing things up) faster connection establishment (fewer RTTs thanks to bundling TCP+TLS handshakes), no head-of-line blocking when sending multiply streams over a single connection.
- paulryanrogers 6y ago
  Is this sustainable though? Won't the middle boxes adapt?
  - judge2020 6y ago
    Almost nothing is plaintext so iterations can be done within the encrypted layer. Iterations could start being done at the same speed that http is done today.
    - oarsinsync 6y ago
      Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
      - cmckn 6y ago
        One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
        oarsinsync 6y ago
        Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes. I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic. There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed. This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.
isbvhodnvemrwvn 6y ago
From my understanding it's mostly head-of-the-line blocking. HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 connection could only handle one request at the time, barring poorly supported pipelining) TCP itself also only allows one stream of data to flow at the time (in each direction) - in case of poor network quality you are going to lose some TCP segments, and if you fill in the receiver's window, the transfer might halt until retransmission succeeds (this includes ALL streams within HTTP/2). Using UDP allows you to circumvent that.
- anderspitman 6y ago
  I've wondered about this. It makes sense in theory, but it seems like if you have data loss on one channel and need retransmission, you probably also have data loss on other channels so they'll end up waiting for their own retransmissions anyway. It seems more like an inherent issue with building reliable streams on an unreliable channel. I'm sure there's hard research on it. Anyone know some good papers?
  - cakoose 6y ago
    This one seems pretty thorough: https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1de1.pdf https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1d... (Chapter 5). There's also a bunch from Google at various stages of QUIC development.
drewg123 6y ago
As a counterpoint to the advantages, the disadvantage is that QUIC is much more expensive on the server side. You loose 25 years of stateless hardware offloads done by the NIC. Measuring the workload that I care about (Netflix CDN serving static videos), loosing TSO, LRO, and software kTLS, like you would with QUIC, takes a server from serving 90Gb/s @ 62% CPU to serving 35Gb/s and CPU limited. So we'd need essentially 3x as many servers to serve via QUIC as we do to serve via TCP. That has real environmental costs. And these are old numbers, from servers that don't support hardware kTLS, so the impact of loosing hardware kTLS would make things even worse.
- jeffbee 6y ago
  Horses for courses. Is anyone suggesting QUIC for gigantic bulk transfers? TCP isn’t great for latency-sensitive small transfers so we will have QUIC. QUIC will not be perfect for everything, like TCP is not perfect for everything.
  - drewg123 6y ago
    I'm pretty sure YouTube uses QUIC for video streaming today, which is a similar workload to ours.
    - jeffbee 6y ago
      I think that indicates more about the economics of YouTube than anything. Probably their frontend CPU costs would have to go up by a factor of ten thousand before it even began to approach their costs for compression and storage of user uploads.
    - virattara 6y ago
      > I'm pretty sure YouTube uses QUIC for video streaming today Is there any media transfer protocol based on QUIC?
      - drewg123 6y ago
        I found an article from 4 years ago saying that 20% of youtube's traffic was QUIC: https://www.fiercewireless.com/wireless/youtube-driving-more-quic-based-traffic-mobile-vasona https://www.fiercewireless.com/wireless/youtube-driving-more...
chaz6 6y ago
Most of QUIC is already supported by SCTP, which could have made IPv6 an even more attractive proposition because the reason SCTP has been poorly adopted is because of the number of middleboxes, mostly for NAT.
- zlynx 6y ago
  There were a few experimental HTTP/2 over SCTP implementations. It worked pretty well. But since the current NAT infested Internet requires smuggling SCTP over UDP anyway you may as well go all out and use QUIC which collapses the various protocol layers into a single, more efficient protocol.
dhdhhdd 6y ago
0rtt handshake (or 1rtt for new connections) and stream multiplexing (no head of line blocking) come to my mind. Oh, and connection migration (wifi to cell), but that's a bit more tricky.

What are the proposed benefits of QUIC? May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.

Jonnax 6y ago

Here's a comparison of HTTP2 vs HTTP3 (QUIC) from Cloudflare: https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/

jsnell 6y ago

Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades and by preventing middleboxes from messing up flows when new options are introduced.

the8472 6y ago
> working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrades from OS upgrades This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
- infogulch 6y ago
  Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
  - simias 6y ago
    I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.
    - skissane 6y ago
      > I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. IBM z/OS actually does this with a feature called AT-TLS (Application Transparent TLS) [0]. You don't even need to call setsockopt (actually z/OS uses ioctl instead of setsockopt for this, but same idea). You can turn a non-TLS service into a TLS service simply by modifying the OS configuration. [0] https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/com.ibm.zos.v2r2.halx001/transtls.htm https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.2.0/...
      - tialaramex 6y ago
        People have built (more than once even) the same functionality for the Linux and NT kernels. https://www.kernel.org/doc/html/latest/networking/tls.html https://www.kernel.org/doc/html/latest/networking/tls.html https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-13-and-go/ https://blog.filippo.io/playing-with-kernel-tls-in-linux-4-1... https://docs.microsoft.com/en-us/windows/win32/http/kernel-mode-ssl https://docs.microsoft.com/en-us/windows/win32/http/kernel-m...
        skissane 6y ago
        That isn't the same functionality. - Linux kernel TLS doesn't provide a full implementation of TLS in the Linux kernel, only the symmetric encryption part. The handshake still has to be performed by the application in user space, and the application then needs to call setsockopt() in order to inject the keys into the kernel. By contrast, z/OS AT-TLS implements all of TLS (including the handshake), so the application doesn't have to do anything. As far as the application is concerned, a TLS socket looks exactly the same as a plain one (unless the application starts calling the AT-TLS ioctl, which will tell it whether a socket is plain or TLS) - The Windows "kernel mode SSL" is only for the built-in HTTP server. It doesn't apply to clients, or to other protocols than HTTP. By contrast, z/OS AT-TLS works for any protocol, not just HTTP, and supports both clients and servers So nobody has built the same functionality as z/OS AT-TLS in Linux or Windows. People have built some small subsets of z/OS AT-TLS's functionality, but not the generality that AT-TLS provides.
  - saagarjha 6y ago
    Not to bring up the usual debate again, but anyone trying to sell you one side of the static/dynamic debate without acknowledging that this is not a cut-and-dry issue is doing you a disservice and it is probably in your best interest to not listen to them.
jlokier 6y ago
> solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades QUIC explicitly addresses "network middlebox ossification" of TCP, by encrypting almost everything about the protocol. This type of ossification is where the network blocks or corrupts any deviations that it doesn't recognise but thinks it does. TCP "OS ossification" is a different kind. By itself, this could have been overcome by streaming TCP-in-UDP and amending it from there. Even that is only because of OS APIs. If OSes allowed applications to bind to a TCP port and process the raw packets, applications that want to could implement TCP themselves. If that kind of dual-binding seems strange, I think it's actually more or less what we'll end up with with QUIC in the end: The OS providing QUIC sockets (socket(AF_INET,SOCK_QUIC,...)) to applications that don't care to implement the QUIC stack themselves, while allowing other applications to bind to UDP in the usual way and implement their own application-level QUIC. I think current QUIC solves application vs. OS ossification issues in the short term, allowing things to evolve beyond TCP, but it's a temporary benefit. In time I think we will see QUIC ossify when it's implemented in many applications that don't get updated. Most browsers are updated often. But I'm seeing more obscure applications starting to include QUIC and depend on it (without any TCP fallback even) - leading eventually to hundreds of "hand-written quality" QUIC implementations, all destined to get out of date. Various languages are implementing their own QUIC libraries, and these aren't all going to be maintained the same way. Shipped applications ossify too. That's why I think it'll end up in the OS kernels eventually.
- jsnell 6y ago
  You're right that the two forms of ossification are distinct, but I'm quite certain that both were driving factors here. Rolling out new TCP options is a decade-long process, and if anything goes wrong with the initial design, once it is shipping you're basically never fixing it. Applications are much easier to update than operating systems, auto-update for the vast majority of users, and for the <1% who don't update the app can always fall back to TCP. (E.g. the rationale for TOU, now-dead Facebook's UDP-based transport explicitly stated userspace-only deployability as requirement. They needed a solution for all their other requirements to be deployed in 2015, not with a consensus design approved in 2020 and in wide deployement in 2025.) The middle-box driven ossification happened by making things harder. The OS upgrade driven ossification happened by reducing/delaying the payoff.

uluyol 6y ago

QUIC is TCP+TLS. HTTP is done as a separate layer on top. The benefits are: future protocol evolution (TCP is extremely difficult to change because of middleboxes, QUIC encrypts almost all of the header to stop middleboxes from messing things up) faster connection establishment (fewer RTTs thanks to bundling TCP+TLS handshakes), no head-of-line blocking when sending multiply streams over a single connection.

paulryanrogers 6y ago
Is this sustainable though? Won't the middle boxes adapt?
- judge2020 6y ago
  Almost nothing is plaintext so iterations can be done within the encrypted layer. Iterations could start being done at the same speed that http is done today.
  - oarsinsync 6y ago
    Middleboxes by design MITM connections. They'll terminate the connection from the client and the server, unencrypt and reencrypt as necessary. That's the whole point of the troublesome middleboxes. They're not passive listeners. They're active participants, with fragile implementations.
    - cmckn 6y ago
      One does not simply “unencrypt” traffic, though. That’s the whole point of TLS.
      - oarsinsync 6y ago
        Indeed, one intercepts and terminates the TCP (or now UDP) session. No version of TLS is immune to these middleboxes. I suspect I'm being misunderstood. I don't intend to suggest these pasky middleboxes spring up randomly on the Internet and anyone is at risk. These are deliberately installed on the edge of corporate networks, and their sole purpose is to intercept, unencrypt and filter traffic. There's no technological solution for a middleware box that emulates a client to servers, and emulates a server to clients, and is operating exactly as designed. This shouldn't be new or surprising or groundbreaking to anyone. It's just a fancy name for a poorly implemented proxy.

isbvhodnvemrwvn 6y ago

From my understanding it's mostly head-of-the-line blocking. HTTP/2 was introduced to solve head-of-the-line blocking on the application level (one HTTP/1.1 connection could only handle one request at the time, barring poorly supported pipelining) TCP itself also only allows one stream of data to flow at the time (in each direction) - in case of poor network quality you are going to lose some TCP segments, and if you fill in the receiver's window, the transfer might halt until retransmission succeeds (this includes ALL streams within HTTP/2). Using UDP allows you to circumvent that.

anderspitman 6y ago
I've wondered about this. It makes sense in theory, but it seems like if you have data loss on one channel and need retransmission, you probably also have data loss on other channels so they'll end up waiting for their own retransmissions anyway. It seems more like an inherent issue with building reliable streams on an unreliable channel. I'm sure there's hard research on it. Anyone know some good papers?
- cakoose 6y ago
  This one seems pretty thorough: https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1de1.pdf https://upcommons.upc.edu/bitstream/handle/2117/169283/TJM1d... (Chapter 5). There's also a bunch from Google at various stages of QUIC development.

drewg123 6y ago

As a counterpoint to the advantages, the disadvantage is that QUIC is much more expensive on the server side. You loose 25 years of stateless hardware offloads done by the NIC. Measuring the workload that I care about (Netflix CDN serving static videos), loosing TSO, LRO, and software kTLS, like you would with QUIC, takes a server from serving 90Gb/s @ 62% CPU to serving 35Gb/s and CPU limited. So we'd need essentially 3x as many servers to serve via QUIC as we do to serve via TCP. That has real environmental costs. And these are old numbers, from servers that don't support hardware kTLS, so the impact of loosing hardware kTLS would make things even worse.

jeffbee 6y ago
Horses for courses. Is anyone suggesting QUIC for gigantic bulk transfers? TCP isn’t great for latency-sensitive small transfers so we will have QUIC. QUIC will not be perfect for everything, like TCP is not perfect for everything.
- drewg123 6y ago
  I'm pretty sure YouTube uses QUIC for video streaming today, which is a similar workload to ours.
  - jeffbee 6y ago
    I think that indicates more about the economics of YouTube than anything. Probably their frontend CPU costs would have to go up by a factor of ten thousand before it even began to approach their costs for compression and storage of user uploads.
  - virattara 6y ago
    > I'm pretty sure YouTube uses QUIC for video streaming today Is there any media transfer protocol based on QUIC?
    - drewg123 6y ago
      I found an article from 4 years ago saying that 20% of youtube's traffic was QUIC: https://www.fiercewireless.com/wireless/youtube-driving-more-quic-based-traffic-mobile-vasona https://www.fiercewireless.com/wireless/youtube-driving-more...

chaz6 6y ago

Most of QUIC is already supported by SCTP, which could have made IPv6 an even more attractive proposition because the reason SCTP has been poorly adopted is because of the number of middleboxes, mostly for NAT.

zlynx 6y ago
There were a few experimental HTTP/2 over SCTP implementations. It worked pretty well. But since the current NAT infested Internet requires smuggling SCTP over UDP anyway you may as well go all out and use QUIC which collapses the various protocol layers into a single, more efficient protocol.

dhdhhdd 6y ago

0rtt handshake (or 1rtt for new connections) and stream multiplexing (no head of line blocking) come to my mind. Oh, and connection migration (wifi to cell), but that's a bit more tricky.