QUIC & HTTP/3

[krizhanovsky]

There were several requests for QUIC support, which is still experimental. There is Google Chromium documentation. Appropriate IETF discussion can be found in this video. This paper can be a good point to start learning the protocol. Current status of the QUIC discussions can be found at IEFT meetings.

The source code of QUIC library.

Also see this video from BlackHat'16 https://www.youtube.com/watch?v=wCa5nylzJCo , which discusses the protocol from security point of view.

ngtcp2 and nghttp3 have compatible licenses and can be used as a foundation for the QUIC handshakes and HTTP/3, while https://github.com/lxin/quic provides the in-kernel QUIC transport.

Design considerations

Do not multiplex multiple streams into one packet to avoid multiple streams stall in case of the packet loss.

Tools

• https://github.com/google/quic-trace
• QUICvis https://quic.edm.uhasselt.be/
• quiclog for network traffic observability and the protocol debugging, also see the FOSDEM talk for the usage examples

References

• https://h3.edm.uhasselt.be/, Resource Multiplexing and Prioritizationin HTTP/2 over TCP versus HTTP/3 over QUIC in particular
• RFC 8999 Version-Independent Properties of QUIC
• RFC 9000 QUIC: A UDP-Based Multiplexed and Secure Transport
• RFC 9001 Using TLS to Secure QUIC
• RFC 9002 QUIC Loss Detection and Congestion Control
• QPACK: Field Compression for HTTP/3
• RFC 9218 Extensible Prioritization Scheme for HTTP
• Extending HTTP Semantics (draft)
• Revision of HTTP caching (draft)
• QUIC discussion in our HTTP/2 implementation https://github.com/tempesta-tech/tempesta/issues/309

[krizhanovsky]

Probably QUIC has no sense and doesn't provide any significant performance benefits with fast TLS 1.3 handshakes and TCP fast open. Also Tmpesta's HTTP layer, especially with #391 point 1, is aware about network layer and vise versa. Also probably there is sense to introduce HTTP specialized TCP congestion control algorithm in opposite to QUIC's algorithms.

Also see Ideal HTTP Performance by Mark Nottingham for HTTP/2, TLS 1.3 and QUIC discussion.

[krizhanovsky]

A recent research shows that QUIC outperforms TCP in many cases, but still worse in some cases, e.g. reordered packets. QUIC adaptation in the Internet is still small (see also Nginx task's comment) - less than 10% and 98% of them are generated by Google's browser and sites. Also there are several issues with QUIC with current implementation and existing middleboxes. However, hardware manufactures and the Linux kernel (UDP_SEGMENT, UDP_GRO, SO_TXTIME - see also talk LPC2018 - Optimizing UDP for Content Delivery with GSO) take steps in getting even better performance for QUIC.

It's worth mentioning a discussion about possible performance improvements if QUIC is implemented in OS kernel. QUIC addresses dynamic receive buffer size and other stream parameters similar to #488 requirements.

Since UDP is much simpler than TCP and QUIC is designed from scratch, it has sense to use kernel bypass UDP/IP stack with the QUIC implementation. However, with Meltdown-like attacks one must recompile the kernel to switch off KPTI (if there is no user-space applications controlled by a possibly malicious user) or accept 40% performance degradation. The kernel implementation still has more performance facilities.

QUIC uses UDP with encrypted data, so traffic analyzing is almost impossible and a full proxy is required to prevent DDoS attacks using QUIC.

Performance considerations for in-kernel QUIC

User space QUIC implementations suffer from context switches and data copying. kTLS is unavailable for them (as well as for HTTP/2) due to data framing.

The only way for user space QUIC to be as fast as in-kernel implementation is to use kernel bypass technologies like DPDK together with SPDK for network and disk I/O intermixed with a fast TLS implementation.

[krizhanovsky]

Reference: my recent talk current state of QUIC.

QUIC is a massive protocol, requiring advanced flow and congestion control, just like TCP. The standard takes into account current TCP features in the Linux kernel. Thus, it'll take years to get a good implementation comparable with current Linux TCP implementation. Probably, implementing QUIC in the kernel will allow to reuse some TCP code, e.g. already plugable congestion control algorithms.

The target for the issue is a very first step in 2 directions:

1. Tempesta FW QUIC - just a basic port of some reasonable open source implementation, as we did this with mbedTLS.

2. Linux kernel patch solving very narrow problem: make kTLS encrypt & decrypt QUIC traffic and leave everything other to user space.

The both implementations must be designed with good API to make the kernel patch useful for normal user-space programs, make extensible for further development. While the Tempesta QUIC must use the kTLS/QUIC code.

[vankoven]

Quic community has a spread sheet with QUIC implementations interoperability https://docs.google.com/spreadsheets/d/1D0tW89vOoaScs3IY9RGC0UesWGAwE6xyLk0l4JtvTVg/edit#gid=1268516408

[krizhanovsky]

QUIC has severe issues with flooding attacks and even sophisticated algorithms can not fully filer out DDoS attacks.