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
<jai.forums2...@gmail.com> 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
