Re: Robustness to packet reordering

[Christian Huitema <[e-mail]>]

On 2/5/2025 6:21 AM, Ingemar Johansson S wrote:
> Hi
>
> A very short question, with possibly many answers:
> Do current QUIC stacks support out of order delivery up to one RTT, as is the case with TCP Linux with RACK enabled.

Define support. Do you mean "at the API" or "in the stack"?

The programming APi for QUIC exposes a set of "streams", as well as 
possibly a "datagram" capability. Data sent on one stream is delivered 
in sequence on that stream. Multiple streams can be processed in 
parallel. There is no guarantee of ordering between stream. If a packet 
containing data for stream number N is lost, delivery on that stream 
will stop until the loss recovery -- but delivery will continue for 
other streams.

Data sent as datagram is delivered whenever the datagram arrives. There 
is no guarantee of ordering between datagrams, or between datagrams and 
streams. There is also no expectation of loss recovery: if a packet 
containing a datagram is lost, the datagram is lost.

In the stack, QUIC stacks are expected to check whether a packet was 
"already received", and not process duplicates. Note that if packets are 
lost, the frames contained in the packet may be processed differently -- 
some may not be resent, either because they are now obsolete, or because 
the frame has already been received -- for example, in case of spurious 
retransmission. The packets carrying the repeated data will have their 
own packet number, different from the initial packet.

In order to not process duplicate, implementations have to maintain 
knowledge of already received packets. That knowledge typically has some 
kind of horizon, such as "the last N packets". Packets that are older 
than that will be ignored, because there is no way to tell whether they 
are duplicate. The value of that "horizon" is implementation dependent. 
About 1 RTT worth of packet makes sense, but implementations could use 
something else, like for example 3*PTO.

-- Christian Huitema