Re:A Technology Preview of Nginx Support for QUIC and HTTP/3
by baybal2 on Saturday June 20, 2020 @08:01AM
(#23583459)
> broken middleboxes
I think this notion that you need to work around them, and accommodate, rather than to ignore them, and do things right needs to be thrown out.
All those middleboxes are non-essential, and not are not inherent part of the original design.
I especially don't understand google engineers who decided on TLS 1.3 version hack when the very same situation has repeated itself with 1.3, and many new TLS extensions.
The logic fail for example with IPv6, a giant amount of IPv6 software/hardware is plainly unusable, but this is not a reason to try to hack around it, by trying reimplementing IPv6 in v4.
0RTT session resumption, while TFO could offer this too most people don't enable it due to broken middleboxes. Header encryption, which hopefully prevents future ossification due to those broken middleboxes. Multiple independent streams within a connection where each stream only suffers from its own packet losses instead of all streams being affected together. This provides a small latency benefit. TCP SACKs and fast retransmits should paper over most of this latency, but not all of it. QUIC also offers more SACK ranges than TCP SACK which might help on links with high, non-bursty packet loss. Then there's path migration, e.g. when switching from mobile to wifi. This could also be achieved with MPTCP, but that's still making its way into the kernel.