I think the table is incorrect. Looking back at https://github.com/quicwg/base-drafts/issues/3097, it seems we discussed the issue in 2019 in Cupertino, and agreed that CONNECTION_CLOSE frames are neither ack-eliciting nor governed by CC. We merged changes accordingly to the drafts in https://github.com/quicwg/base-drafts/issues/3097.
Note, at that point, we did not have the Spec column. In 2020, we added the Spec column to the frame table in https://github.com/quicwg/base-drafts/pull/3776. That's when the inconsistency was introduced. #3776 was meant to be editorial (it is labeled as such). Therefore, my belief that our consensus has been to exclude CONNECTION_CLOSE frames from CC, text is correct, and that this is an error in the table. 2025年1月7日(火) 22:19 Mirja Kuehlewind <mirja.kuehlewind= [email protected]>: > 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 > >> > >> > >> > > > > > > -- Kazuho Oku
