RFC 9000, "QUIC: A UDP-Based Multiplexed and Secure Transport", May 2021

Errata ID: 8240
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jaikiran Pai
Date Reported: 2025-01-06
Verifier Name: Zaheduzzaman Sarker
Date Verified: 2025-03-18

Section 12.4 says:

0x1c-0x1d   CONNECTION_CLOSE  Section 19.19  ih01  N

It should say:

0x1c-0x1d   CONNECTION_CLOSE  Section 19.19  ih01  NC

Notes:

QUIC congestion control RFC 9002 (https://www.rfc-editor.org/rfc/rfc9002) section 3 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. This appears to be an oversight in that table in RFC-9000.


See related discussions here ( https://mailarchive.ietf.org/arch/msg/quic/M3j4UsFxXPS6A8EX1d2zW_ZQrMQ/ )

Report New Errata