I thought the intent was to clarify that congestion control should not prevent you from sending the connection close frame?
I agree that there is no congestion control once the frame is sent, since the connection doesn't exist anymore. Thanks, Ian On Mon, Jan 6, 2025 at 6:47 PM Christian Huitema <[email protected]> wrote: > As mentioned in another email, I disagree. This is not necessary, and is > in fact confusing. It would imply that congestion control still applies > after sending the connection close frame, which makes no sense. > > -- Christian Huitema > > On 1/6/2025 10:08 AM, Ian Swett wrote: > > 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 > >> > >> >
