Well, QUIC receivers can easily handle an almost unlimited amount of reordering. The problem is the senders, and in particular the loss detection and congestion controller. As has already been mentioned in the thread, the default packet reordering threshold<https://www.rfc-editor.org/rfc/rfc9002.html#name-packet-threshold> (kPacketThreshold) is only three packets.
It is of course possible to adapt the threshold dynamically as the RFC mentions, and with Ack Frequency<https://datatracker.ietf.org/doc/draft-ietf-quic-ack-frequency/> you can also reduce the number of (spurious) acks. Until it is verified that "all" production QUIC stacks implement dynamic packet reordering thresholds, it seems unwise to completely turn off L2 in-order delivery. /me From: David Schinazi <[email protected]><mailto:[email protected]> Subject: [tsvwg] Re: Robustness to packet reordering Date: Fri, 7 Feb 2025 00:14:28 +0100 (Central European Standard Time) Having the link-layer delay packets to provide them in-order to the transport layer was helpful multiple decades ago when TCP implementations had more naive algorithms and were very resource-constrained. Given how modern implementations work, reordering at the link-layer is almost always harmful. TCP and QUIC stacks can handle reordering well, thanks to both protocol features and implementations having more memory to work with. The delay induced by this reordering will generally cause more harm than good. Furthermore, one of the biggest motivators for QUIC was to break head-of-line blocking and allow out-of-order delivery to the application layer. We have large bodies of data showing that this improves performance. Please disable reordering at the 5G layer. David On Thu, Feb 6, 2025 at 2:15 PM Christian Huitema <[email protected]<mailto:[email protected]>> wrote: On 2/6/2025 12:55 PM, Martin Thomson wrote: > > On Fri, Feb 7, 2025, at 04:59, Greg White wrote: >> This is an important topic relating to the expectations and >> requirements that transport protocols place on layer 2 protocols. In >> layer 2 standards bodies that I've been involved in, it has been >> understood that "the upper layers" expect in-order delivery, > As far as QUIC goes, it is sensitive to reordering in the network. Some > reordering will be interpreted as damage (Christian cited the relevant parts) > and performance suffers in a few minor way when things arrive out of order > (ACKs are less efficient, data needs to be held, memory accesses are less > likely to be contiguous, etc...). > > However, the idea that the network might seek to "fix" these problems, when > doing so necessarily involves extra work and delays, is not a good trade. > Stuff that is delayed to "fix" a reordering that happened might delay signals > that the QUIC stack could use, even if some data needs to be held at the > endpoint. QUIC packets contain many things, some of which don't need to be > strictly ordered to be useful. Applications that are sensitive to delays will break their traffic into multiple QUIC streams. In case of packet loss, only one of those streams will be blocked, the others will be delivered without "head of queue blocking". Implementing L2 correction will make the response worse, not better, because all the streams will be delayed for the duration of the L2 correction instead of just one. -- Christian Huitema
