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 <[email protected]> wrote:
I agree with Kazuho's points, and thanks for the detailed discussion.
On Wed, Jan 15, 2025 at 1:33 AM Kazuho Oku <[email protected]>
wrote:
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
