Hi Ian, see blow.
From: Ian Swett <[email protected]> Date: Wednesday, 7. April 2021 at 18:59 To: Mirja Kuehlewind <[email protected]> Cc: Matt Joras <[email protected]>, IETF QUIC WG <[email protected]> Subject: Re: Call For Adoption QUIC: delayed-ack Hi Mirja, 1. min_ack_delay is used to limit the minimum ack delay you can request in the ACK_FREQUENCY frame: "Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid." https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-02#section-4. After re-reading, possibly "this endpoint" is not specific enough? I was missing further guidance on how to implement that. Usually if I have a packet tolerance of e.g. 2, I would just ack every other packet. Am I supposed to delay my ack if the last was ACK was send to close by? Would I need to use the delayed ACK timer for that or a separate timer? Didn’t think that through but thought it would be good to have more guidance in the draft. Mirja 2) I filed https://github.com/janaiyengar/ack-frequency/issues/48<https://protect2.fireeye.com/v1/url?k=630b3661-3c900f2c-630b76fa-86b568293eb5-939d2a901a720566&q=1&e=75fb064a-d6ab-4fbc-942c-316b26352e5b&u=https%3A%2F%2Fgithub.com%2Fjanaiyengar%2Fack-frequency%2Fissues%2F48> for this. Thanks for reading, Ian On Wed, Apr 7, 2021 at 9:56 AM Mirja Kuehlewind <[email protected]<mailto:[email protected]>> wrote: Hi, I know I'm too late but I also support adoption. But now that I found the time to read the draft again, I also have two comment: 1) It seems like min_ack_delay is "only" used for negotiation because the draft does not specify any further what to do with this value. Isn't either min_ack_delay or Packet Tolerance sufficient, e.g. what if you have a packet tolerance of 1 but a min_ack_delay of > 0? 2) For ECN, you don't need to send an immediate ACK for each CE. Immediate ACKs are most important when the codepoint switches to CE, but then, if multiple CEs in a row are received, you can bundle the ACK information. See also https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5.1 (Note that we are still working on that section for AccECN but I think any changes are only relevant for specifics of TCP) Mirja On 30.03.21, 21:39, "QUIC on behalf of Matt Joras" <[email protected]<mailto:[email protected]> on behalf of [email protected]<mailto:[email protected]>> wrote: Hello all, Now that we have been rechartered we can move forward with adopting new items. It is the opinion of the chairs that the delayed-ack draft[1] has sufficient interest from and relevance to the WG to be formally adopted. This email is the call to do so. There are already several interoperating implementations of the current draft. Please reply to this email with any comments, the call will run through April 6th. Thanks, QUIC Chairs [1] https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/
