4 ms·

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is beca

The article mentions gives an example of why it’s difficult to improve TCP further. TCP Fast Open was standardized 8 years ago and is barely used. This is because updating TCP requires kernel updates, which just isn’t going to happen on most mobile devices. Thus, moving the protocol to userspace makes a lot of sense.

kijin 8y ago
That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.
- lclarkmichalek 8y ago
  Much easier to update an app and its HTTP library than mobile device kernels. Particularly given how a large proportion of mobile devices are unsupported and won't get kernel upgrades any more.
  - michaelt 8y ago
    The thing is, there are two possible extremes: 1. Our design is complete, error-free and designed to stand the tests of time. It will be in common use, largely unchanged, in 40 years time. The TCP of the 2010s. There is widespread industry support. We want to move to the application layer to ease the initial roll-out. 2. Our design will need to change every few years, even we authors don't think it's finished. This is a Google-only project and most vendors are refusing to support it as they think it's badly designed crap. The ActiveX of the 2010s. We want to move to the application layer so we can force it through without anyone else's support. Where are we on the spectrum between those two options? I don't know.
    - chrisweekly 8y ago
      Great question!
- cdmckay 8y ago
  An app can control which HTTP library it’s using and even bypass the built in one on the mobile device. That’s not possible in the case of TCP. So no, it’s not the same. Another issue they mention in the article is middleboxes, which basically will never be upgraded, and will never support new TCP features.
  - josteink 8y ago
    Nor will they support new HTTP-features.
daurnimator 8y ago
I think TCP fast open is a bad example for this. None of the common socket libraries that I know (never mind http libraries) have gained support for TCP fast open yet.
- Avamander 8y ago
  It's a bad example because it's badly adopted?
  - daurnimator 8y ago
    It's a bad example of middle-boxes causing ossification, as the adoption has been more limited by library/framework support than middle-boxes blocking it.
    - jyounker 8y ago
      Chicken and egg problem. It doesn't tend to work reliably because of middle boxes so there is no push to implement it widely. It is not widely implemented so there is little pressure to update middle boxes.
zamadatix 8y ago
> Thus, moving the protocol to userspace makes a lot of sense. Raw IP sockets are accessible from the same userspace facing APIs as e.g. UDP sockets and don't require climbing up the stack. Unfortunately operating systems started to consider custom protocol implementations security risks but rather than reverse that thinking we've just continued to abstract up past it. In reality I think "where it is implemented in code" was a small portion of QUICs design choices compared to "IPv4 NAT & external firewalling has ossified protocols" which is a similar story of "just abstact up to avoid the issues". Unfortunately in that case I don't think abstracting up isn't as permanent a solution as it was on the OS side.
- bdonlan 8y ago
  Raw sockets don't really allow for multiple applications to use the same custom protocol. If, for example, chrome and firefox were both running, which gets packets destined for the QUIC transport protocol? The kernel wouldn't know; without the UDP header it can't distinguish flows. Likewise NAT devices typically support UDP flows today due to their prevalence in games, but if you introduce a new transport protocol at the IP layer, they wouldn't be able to identify which flow (and therefore which NATed endpoint) the packet is destined for.
  - vbezhenar 8y ago
    Chrome and Firefox could develop standardized system service which will deliver package to a proper application. NAT is not needed in a bright IPv6 world of the future. Though I don't know what's wrong with UDP. 8 bytes of overhead for 1450 bytes IP payload is 0.5% bandwidth. Checksum overhead should be negligible.
    - brozaman 8y ago
      > system service which will deliver package to a proper application That's expensive. Even if you avoid copying the packages by sharing memory between processes, there are still a lot of context switches...
  - zamadatix 8y ago

kijin 8y ago

That doesn't sound like a particularly convincing reason. In order for mobile devices to benefit from HTTP/3, commonly used HTTP client libraries will have to be updated. Which usually happens on a similar timescale as kernel updates anyway.

lclarkmichalek 8y ago
Much easier to update an app and its HTTP library than mobile device kernels. Particularly given how a large proportion of mobile devices are unsupported and won't get kernel upgrades any more.
- michaelt 8y ago
  The thing is, there are two possible extremes: 1. Our design is complete, error-free and designed to stand the tests of time. It will be in common use, largely unchanged, in 40 years time. The TCP of the 2010s. There is widespread industry support. We want to move to the application layer to ease the initial roll-out. 2. Our design will need to change every few years, even we authors don't think it's finished. This is a Google-only project and most vendors are refusing to support it as they think it's badly designed crap. The ActiveX of the 2010s. We want to move to the application layer so we can force it through without anyone else's support. Where are we on the spectrum between those two options? I don't know.
  - chrisweekly 8y ago
    Great question!
cdmckay 8y ago
An app can control which HTTP library it’s using and even bypass the built in one on the mobile device. That’s not possible in the case of TCP. So no, it’s not the same. Another issue they mention in the article is middleboxes, which basically will never be upgraded, and will never support new TCP features.
- josteink 8y ago
  Nor will they support new HTTP-features.

daurnimator 8y ago

I think TCP fast open is a bad example for this. None of the common socket libraries that I know (never mind http libraries) have gained support for TCP fast open yet.

Avamander 8y ago
It's a bad example because it's badly adopted?
- daurnimator 8y ago
  It's a bad example of middle-boxes causing ossification, as the adoption has been more limited by library/framework support than middle-boxes blocking it.
  - jyounker 8y ago
    Chicken and egg problem. It doesn't tend to work reliably because of middle boxes so there is no push to implement it widely. It is not widely implemented so there is little pressure to update middle boxes.

zamadatix 8y ago

> Thus, moving the protocol to userspace makes a lot of sense. Raw IP sockets are accessible from the same userspace facing APIs as e.g. UDP sockets and don't require climbing up the stack. Unfortunately operating systems started to consider custom protocol implementations security risks but rather than reverse that thinking we've just continued to abstract up past it. In reality I think "where it is implemented in code" was a small portion of QUICs design choices compared to "IPv4 NAT & external firewalling has ossified protocols" which is a similar story of "just abstact up to avoid the issues". Unfortunately in that case I don't think abstracting up isn't as permanent a solution as it was on the OS side.

bdonlan 8y ago
Raw sockets don't really allow for multiple applications to use the same custom protocol. If, for example, chrome and firefox were both running, which gets packets destined for the QUIC transport protocol? The kernel wouldn't know; without the UDP header it can't distinguish flows. Likewise NAT devices typically support UDP flows today due to their prevalence in games, but if you introduce a new transport protocol at the IP layer, they wouldn't be able to identify which flow (and therefore which NATed endpoint) the packet is destined for.
- vbezhenar 8y ago
  Chrome and Firefox could develop standardized system service which will deliver package to a proper application. NAT is not needed in a bright IPv6 world of the future. Though I don't know what's wrong with UDP. 8 bytes of overhead for 1450 bytes IP payload is 0.5% bandwidth. Checksum overhead should be negligible.
  - brozaman 8y ago
    > system service which will deliver package to a proper application That's expensive. Even if you avoid copying the packages by sharing memory between processes, there are still a lot of context switches...
- zamadatix 8y ago