Hi all, Thanks for the discussion it helps.
Reading Kazuho’s details, it feels that the errata should be verified. I will keep this as reported for one more week to get more comments/views , and if the discussions would not lead to any change of opinion, I will verify it after this period is over. // Zahed On Thu, 23 Jan 2025 at 19:08, Ian Swett <iansw...@google.com> wrote: > 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 >> >
