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. 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.
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
