The two documents you want to read or cite are RFC 9002 and the QUIC
Acknowledgment Frequency draft
(https://datatracker.ietf.org/doc/html/draft-ietf-quic-ack-frequency).
Specifically, section 6 of RFC 9002 defining "Loss detection", defining
kPacketThreshold and recommending at least 3 and then kTimeThreshold,
with a suggested value of 9/8 RTT.
-- Christian Huitema
On 2/6/2025 1:34 AM, Ingemar Johansson S wrote:
OK, so that means that time based loss detection is not yet implemented in QUIC
stacks, or ?
The reason I ask is that we poll the interest in the support for out of order
delivery of packets in 5G. The outline is that we ensure in order delivery for
up to some given milliseconds, to handle possible HARQ retransmissions on the
MAC layer. Beyond that we forward packets as they are processed by the radio
stack.
The rationale behind this is to avoid that packets for latency sensitive flows
(streams) are delayed more than necessary if they share the same data radio
bearer as other streams.
We see that TCP Linux is robust to packet reordering (up to 1 RTT reordering
depth) and fast retransmits are avoided (except in the initial phase when the
reordering window grows). Thus I wonder if there are plans to make also QUIC
stacks support time based RACK?
/Ingemar
-----Original Message-----
From: Christian Huitema <[email protected]>
Sent: Thursday, 6 February 2025 08:57
To: Ingemar Johansson S <[email protected]>; Ingemar
Johansson S <[email protected]>;
[email protected]
Subject: Re: Robustness to packet reordering
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 <[email protected]>
Sent: Thursday, 6 February 2025 02:00
To: Ingemar Johansson S
<[email protected]>; [email protected]
Cc: Ingemar Johansson S <[email protected]>
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
