On 07/01/25 7:56 am, Ian Swett wrote:
I thought the intent was to clarify that congestion control should not
prevent you from sending the connection close frame?
Right, that was the context of my question/errata.
-Jaikiran
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
>>
>>
