RACK is the default for QUIC. The detection gap is set to 3 by default,
that is, a packet considered lost if a packet N+3 or later has been
received. Implementations are free to implement dynamic RACK gaps and
the ACK Frequency extension can ask the peer to send packets
accordingly, but AFAIK most implementations go for robustness and keep
the detection gap fixed.
Note that QUIC does not "reorder" packets -- packets are processed as
soon as they arrive.
-- Christian Huitema
On 2/5/2025 10:50 PM, Ingemar Johansson S wrote:
Hi Christian
I was perhaps a bit unclear, sorry.
I refer to "in the stack".
The RACK function in Linux TCP increases the reordering window when packet
reordering is detected and thus avoids fast retransmits. In current Linux TCP
the reordering window can increase to accept up to one RTT reordering.
Do any current QUIC stack support this RACK functionality and/or is it planned.
/Ingemar
-----Original Message-----
From: Christian Huitema <huit...@huitema.net>
Sent: Thursday, 6 February 2025 02:00
To: Ingemar Johansson S
<ingemar.s.johansson=40ericsson....@dmarc.ietf.org>; quic@ietf.org
Cc: Ingemar Johansson S <ingemar.s.johans...@ericsson.com>
Subject: Re: Robustness to packet reordering
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
