I disagree. There is no point performing any congestion control
whatsoever when the transmission is closing. The sender of the
connection close is committing to not sending any more data, so it does
not matter whether the bytes in the congestion control packets are
counted or not as bytes in flight or compared to the congestion control
window. I believe the text is just fine.
-- Christian Huitema
On 1/5/2025 12:52 AM, Jaikiran Pai wrote:
Thank you Ian.
If no one disagrees, then I'll go ahead and open an errata in the next
couple of days.
-Jaikiran
On 31/12/24 12:09 am, Ian Swett wrote:
I believe that's an oversight, and I don't see an errata for it yet:
https://www.rfc-editor.org/errata/rfc9000
I'm curious if others agree?
Thanks, Ian
On Fri, Dec 27, 2024 at 8:44 PM Jaikiran Pai
<[email protected]> wrote:
Hello everyone,
I was looking at the QUIC congestion control RFC 9002
(https://www.rfc-editor.org/rfc/rfc9002) section 3 and it states:
"The types of frames contained in a packet affect recovery and
congestion control logic:
...
Packets containing frames besides ACK or CONNECTION_CLOSE frames
count
toward congestion control limits and are considered to be in
flight."
So as per RFC-9002, it means that ACK and CONNECTION_CLOSE frames
do not
contribute to congestion control limits.
On the other hand, RFC-9000, section 12.4 has a Table 3
(https://www.rfc-editor.org/rfc/rfc9000#frame-types) which states:
"The "Spec" column in Table 3 summarizes any special rules
governing the
processing or generation of the frame type, as indicated by the
following characters:
...
C: Packets containing only frames with this marking do not count
toward
bytes in flight for congestion control purposes; see
[QUIC-RECOVERY]."
However, in that table, the CONNECTION_CLOSE frame isn't marked
with the
"C" character and only the ACK frame is. Is this an oversight in
this table?
-Jaikiran
