5 ms·

Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification iss

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

by jsnell 6y ago

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.