2025年1月7日(火) 13:35 Christian Huitema <[email protected]>: > I think that if we go there, we need a much larger errata. > > For starter, RFC 9002 has a definition of "Ack-eliciting frames", "All > frames other than ACK, PADDING, and CONNECTION_CLOSE are considered > ack-eliciting." So we have a definition per enumeration in RFC 9002 and > then a parallel definition by table in section 12.4 of RFC 9000. That's > obviously a recipe for contradiction. IMHO, RFC 9002 is wrong. It should > replace the definition by enumeration by a reference to the definition > in RFC 9000/12.4. > > We have the of "extension" frame types. We are asking the extension > creator to specify whether the frame is "ack eliciting" or not. For > frames that are NOT ack-eliciting, should we add a requirement to > specify whether they count for congestion or not? For example, should > the multipath draft say something like that for the PATH_ACK frames? > > Of course, we do NOT have such a definition in RFC 9002. Instead, it > says "Packets are considered in flight when they are ack-eliciting or > contain a PADDING frame, and they have been sent but are not > acknowledged, declared lost, or discarded along with old keys." We are > making up something in RFC 9000 with the C flag. > > Then, there is the little problem that this definition of "bytes in > flight" in RFC 9002 is probably wrong. What we want to say is that ACKs > and Close Connection frames are exception to congestion control.
I do not think that was our conclusion. We discussed this "design issue" and reached consensus on this problem in https://github.com/quicwg/base-drafts/issues/3097. The arguments that I see are: * CONNECTION_CLOSE does not elicit an ACK and therefore is not governed by CC * it makes sense to send CONNECTION_CLOSE even when CC is blocking data. The "Spec" column was introduced as an "editorial" change in https://github.com/quicwg/base-drafts/pull/3776, after the changes for #3097 went in. But as pointed out, the value of the "Spec" column for CONNECTION_CLOSE frame contradicts the text introduced by #3097. > But > mathematically, every packet sent on a path and not yet acked or > discarded should be counted as "bytes in flight", and the count should > be used when estimating the capacity of the flight. > I am not sure if that was the model behind RFC 9002. IIUC, we defined congestion control as a mechanism that works independently in each direction. Data is sent in one direction and ACKs are sent in the other direction. Senders of data use ACKs they receive for congestion control. Considering these aspects, I think the correct way forward is to change the "Spec" column of CONNECTION_CLOSE to "NC," building on the consensus established in #3097. > What I think RFC9002 is trying to say is that it is fine to send ACKs or > Close Connection packets even if the amount of bytes in flight already > exceeds the congestion window, because they are important and should be > sent immediately. Of course, this is a debatable statement. For example, > what happens in multipath when PATH_ACK are sent on another path? (see > https://github.com/quicwg/multipath/issues/454). It is also an > incomplete statement. Some congestion control algorithms (e.g., BBR) > control traffic by specifying both a pacing rate and a congestion > window. We don't want ACK to be delayed by the congestion window. > > Do we want them to be delayed by pacing? My personal opinion is, yes we > do. We want ACKs to be sent as soon as they are needed and pacing > permits, so the "paced" ACK contains the most recent value of the ACK > list, filled with a "just in time" logic. Not all implementations will > want to do that. But all implementations probably should try to not send > so many ACK frames that they overwhelm the path capacity. Sending ACK > frames to see the network randomly drop them cannot be the right strategy. > > Bottom line, the "C" flag in RFC 9000 is kinda misleading, and is not > needed by RFC 9002. There are some frames that implementations will send > without regard for congestion control, but the corresponding packets > should absolutely count as "bytes in flight". If we do an errata, I > would propose to just remove the C flag instances and definition. And > let developers think and do the right thing. After all, congestion > control is a local decision, and does not affect interoperability. > > -- Christian Huitema > > > On 1/6/2025 6:26 PM, Ian Swett wrote: > > 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 > >>>> > >>>> > > -- Kazuho Oku
