4 ms·

Uber was an early adopter of QUIC and saw significant performance improvements for its apps from it, especially in markets where mobile connectivity is poor htt

Uber was an early adopter of QUIC and saw significant performance improvements for its apps from it, especially in markets where mobile connectivity is poor https://eng.uber.com/employing-quic-protocol/ https://eng.uber.com/employing-quic-protocol/

the8472 7y ago
With recent linux kernels most of the cited quic advantages are also available for TCP, the exceptions are HoL blocking which is inherent in TCP (but how bad it is depends on loss recovery, which is improving) and connection migration which will come to TCP via MP-TCP. Their article doesn't even mention against which kernel verison they're comparing > In the future, TLS1.3 will support 0-RTT, but the TCP three-way handshake will still be required. This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake.
- treve 7y ago
  All of this is covered in the "Boxes" section in the article
  - deleted 7y ago
    [deleted]
  - the8472 7y ago
    I was sppecifically responding to the bullet list in the "Adopting QUIC" section of the uber article. I don't think the general "middle boxes ruing everything" argument addresses this. BBR has very few if any middlebox problems. Neither do tail loss probe improvements or any other sender side optimizations such as TCP_NOTSENT_LOWAT. TFO may cause issues in corporate environments (works fine with my home equipment) but fallback is easy. So I don't think this really "addresses" the issue. Improved acking is not strictly needed if you use tcp timestamps for RTT estimation and still ack improvements have been added to the kernel over the years.
    - londons_explore 7y ago
      Fallback for TFO isn't easy because your request might not have been idempotent. Start running some HTTP requests multiple times and you can quickly see hard to debug breakage.
- riobard 7y ago
  > This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake. Yes in theory but it fails on its face in practice. Many middle boxes are not happy with TCP Fast Open, and there's the tracking problem. Chrome dropped TFO.
  - the8472 7y ago
    Doesn't the tracking problem also apply to 0RTT TLS? So we would have to discount either.
    - tialaramex 7y ago
      TLS lives in the browser stack. So your browser can provide policy here. For example the browser can say "OK, this is a Porn tab, so we shouldn't re-use the google.com TLS connection from the tab that's logged into GMail and searching for Tom Hanks movies, we'll spin up a new one (without 0RTT)". But TCP lives down in the OS stack, so maybe without knowing it the browser's new TLS connection has TFO cookies the OS learned from the Tom Hanks connection, which ties the two sessions together. Oops.
      - the8472 7y ago
        The application has to explicitly ask for fast open to happen, so just as it does with TLS it can choose not to do so with TFO. But you're right, it has no control over the cookies themselves. That could be added with some ioctl or socket option, but I guess things haven't developed that far. But cookieless TFO is also an option, combined with 0RTT TLS the application would be in charge of either accepting or rejecting the connection based on the TLS resumption cookie.

the8472 7y ago

With recent linux kernels most of the cited quic advantages are also available for TCP, the exceptions are HoL blocking which is inherent in TCP (but how bad it is depends on loss recovery, which is improving) and connection migration which will come to TCP via MP-TCP. Their article doesn't even mention against which kernel verison they're comparing > In the future, TLS1.3 will support 0-RTT, but the TCP three-way handshake will still be required. This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake.

treve 7y ago
All of this is covered in the "Boxes" section in the article
- deleted 7y ago
  [deleted]
- the8472 7y ago
  I was sppecifically responding to the bullet list in the "Adopting QUIC" section of the uber article. I don't think the general "middle boxes ruing everything" argument addresses this. BBR has very few if any middlebox problems. Neither do tail loss probe improvements or any other sender side optimizations such as TCP_NOTSENT_LOWAT. TFO may cause issues in corporate environments (works fine with my home equipment) but fallback is easy. So I don't think this really "addresses" the issue. Improved acking is not strictly needed if you use tcp timestamps for RTT estimation and still ack improvements have been added to the kernel over the years.
  - londons_explore 7y ago
    Fallback for TFO isn't easy because your request might not have been idempotent. Start running some HTTP requests multiple times and you can quickly see hard to debug breakage.
riobard 7y ago
> This is outright wrong. With TCP you have fast open, which provides 0-RTT send just like the TLS 0-RTT handshake. Yes in theory but it fails on its face in practice. Many middle boxes are not happy with TCP Fast Open, and there's the tracking problem. Chrome dropped TFO.
- the8472 7y ago
  Doesn't the tracking problem also apply to 0RTT TLS? So we would have to discount either.
  - tialaramex 7y ago
    TLS lives in the browser stack. So your browser can provide policy here. For example the browser can say "OK, this is a Porn tab, so we shouldn't re-use the google.com TLS connection from the tab that's logged into GMail and searching for Tom Hanks movies, we'll spin up a new one (without 0RTT)". But TCP lives down in the OS stack, so maybe without knowing it the browser's new TLS connection has TFO cookies the OS learned from the Tom Hanks connection, which ties the two sessions together. Oops.
    - the8472 7y ago
      The application has to explicitly ask for fast open to happen, so just as it does with TLS it can choose not to do so with TFO. But you're right, it has no control over the cookies themselves. That could be added with some ioctl or socket option, but I guess things haven't developed that far. But cookieless TFO is also an option, combined with 0RTT TLS the application would be in charge of either accepting or rejecting the connection based on the TLS resumption cookie.