Hacker News Reader

Comment by chucknthem | Hacker News Reader

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/

View on HN

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.

All of this is covered in the "Boxes" section in the article

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.

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.

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

Doesn't the tracking problem also apply to 0RTT TLS? So we would have to discount either.

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.

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.

Reply on news.ycombinator.com