Hi Christian, it is correct that it doesn't matter if the close frame is counted as bytes in flight or not after is was sent because the connection is closed anyway, however, the thing that matter is that you need to be able to always send a close frame even if the congestion window currently does not allow you to send anything. As such the close frame should not be counted as bytes in flight because that means you can always sent it immediately.
I agree with Ian that this as an oversight. It doesn't matter for congestion control itself, but it must be clear that you can always sent the close frame and are not limited by the congestion window. Also both specs should be aligned and therefore marking the close frame also in RFC9000 with C seems correct to me. Mirja On 07.01.25, 00:46, "Christian Huitema" <[email protected] <mailto:[email protected]>> wrote: 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 >> <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] <mailto:[email protected]>> wrote: >> >> Hello everyone, >> >> I was looking at the QUIC congestion control RFC 9002 >> (https://www.rfc-editor.org/rfc/rfc9002 >> <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 >> <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 >> >> >>
