Re: [Editorial Errata Reported] RFC9000 (8106)

[Lars Eggert <[e-mail]>]

Hi,

On Sep 17, 2024, at 14:32, Martin Thomson <[e-mail]> wrote:
> 
> I don't think that this is right.
> 
> Acknowledgments for non-ack-eliciting packets do not need to occur within the ACK delay.  In fact, that's the whole point.

huh. I always thought that non-ack-eliciting packet need not be ACK'ed *at all*, but that any sent ACKs (whether for ack-eliciting or non-ack-eliciting packets) would need to be sent within the max ACK delay.

Because if we allow non-ack-eliciting packets to be ACK'ed later than the max ACK delay, doesn't that inflate the RTT samples? (Because we only subtract out max_ack_delay?)

> I also can't see how you might read the text to say that you might avoid acknowledging an ack-eliciting packet.

That's good, because I wasn't trying to day that :-)

Thanks,
Lars


> On Tue, Sep 17, 2024, at 03:00, RFC Errata System 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/eid8106
>> 
>> --------------------------------------
>> Type: Editorial
>> Reported by: Lars Eggert <[e-mail]>
>> 
>> Section: 13.2.1
>> 
>> Original Text
>> -------------
>>   Every packet SHOULD be acknowledged at least once, and ack-eliciting
>>   packets MUST be acknowledged at least once within the maximum delay
>>   an endpoint communicated using the max_ack_delay transport parameter;
>> 
>> 
>> Corrected Text
>> --------------
>>   Every packet SHOULD be acknowledged at least once, and ack-eliciting
>>   packets MUST be acknowledged at least once. All acknowledgments MUST
>>   occur within the maximum delay an endpoint communicated using the
>>   max_ack_delay transport parameter;
>> 
>> 
>> Notes
>> -----
>> The original text can be read as if it were OK to only ACK once within 
>> the max_ack_delay, and not always.
>> 
>> 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
>