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