This LGTM, but I'd like Jana or Martin to approve as well. On Mon, Jan 6, 2025 at 1:43 AM RFC Errata System <[email protected]> wrote:
> The following errata report has been submitted for RFC9000, > "QUIC: A UDP-Based Multiplexed and Secure Transport". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8240 > > -------------------------------------- > Type: Technical > Reported by: Jaikiran Pai <[email protected]> > > Section: 12.4 > > Original Text > ------------- > 0x1c-0x1d CONNECTION_CLOSE Section 19.19 ih01 N > > Corrected Text > -------------- > 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. > > P.S: I raised this as a question in the QUIC working group mailing list > before raising this errata. That mail thread is here > https://mailarchive.ietf.org/arch/msg/quic/aBYUxanWVO-yEQASSxUNGbQQ8Kk/ > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC9000 (draft-ietf-quic-transport-34) > -------------------------------------- > Title : QUIC: A UDP-Based Multiplexed and Secure Transport > Publication Date : May 2021 > Author(s) : J. Iyengar, Ed., M. Thomson, Ed. > Category : PROPOSED STANDARD > Source : QUIC > Stream : IETF > Verifying Party : IESG > >
