I agree with Kazuho's points, and thanks for the detailed discussion. On Wed, Jan 15, 2025 at 1:33 AM Kazuho Oku <kazuho...@gmail.com> wrote:
> > > 2025年1月7日(火) 13:35 Christian Huitema <huit...@huitema.net>: > >> 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 <huit...@huitema.net> >> > 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 < >> >> rfc-edi...@rfc-editor.org> >> >>> 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 <jai.forums2...@gmail.com> >> >>>> >> >>>> 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 >
