Re: Robustness to packet reordering

[Christian Huitema <[e-mail]>]

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