Hi, On Sep 17, 2024, at 14:32, Martin Thomson <[email protected]> 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 <[email protected]> >> >> 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 >
signature.asc
Description: Message signed with OpenPGP
