Subject: Re: Call For Adoption QUIC: delayed-ack

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 1 Apr 2021 11:32:31 +0100

On 30/03/2021 20:38, Matt Joras 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/

I support adoption and would like to contribute to this work,

Gorry

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 5 Apr 2021 16:18:22 +0000

+1.

I support adoption

/Ingemar

From: David Schinazi <[email-masked]>
Sent: den 31 mars 2021 20:09
To: IETF QUIC WG <[email-masked]>
Subject: Re: Call For Adoption QUIC: delayed-ack

I support adoption.

David

On Tue, Mar 30, 2021 at 8:20 PM Sean Turner <[email-masked] 
<mailto:[email-masked]> > wrote:

I support adoption.

spt

> On Mar 30, 2021, at 15:38, Matt Joras <[email-masked] 
> <mailto:[email-masked]> > wrote:
>
> Hello all,
>

---

From: Matt Joras <[email-masked]>
Date: Tue, 6 Apr 2021 08:48:31 -0700

Hello all,

As all comments have been supportive we have adopted
draft-iyengar-quic-delayed-ack.

Thanks,
QUIC Chairs

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Apr 2021 13:55:40 +0000

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-masked] on behalf of [email-masked]> wrote:

    Hello all,

    Thanks,
    QUIC Chairs

---

From: Ian Swett <[email-masked]>
Date: Wed, 7 Apr 2021 12:58:45 -0400

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?

2) I filed https://github.com/janaiyengar/ack-frequency/issues/48 for this.

Thanks for reading, Ian

On Wed, Apr 7, 2021 at 9:56 AM Mirja Kuehlewind <mirja.kuehlewind=
[email-masked]> wrote:

> 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-masked]
> on behalf of [email-masked]> wrote:
>
>     Hello all,
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Apr 2021 17:06:30 +0000

Hi Ian,

see blow.

From: Ian Swett <ianswett=[email-masked]>
Date: Wednesday, 7. April 2021 at 18:59
To: Mirja Kuehlewind <[email-masked]>
Cc: Matt Joras <[email-masked]>, IETF QUIC WG <[email-masked]>
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 <mirja.kuehlewind=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Mirja

On 30.03.21, 21:39, "QUIC on behalf of Matt Joras" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hello all,

    Thanks,
    QUIC Chairs

---

From: Matt Joras <[email-masked]>
Date: Wed, 7 Apr 2021 12:00:40 -0700

Hi Mirja,

Below is my interpretation though since we are having this discussion
perhaps this needs to be made clearer in the text.

On Wed, Apr 7, 2021 at 10:06 AM Mirja Kuehlewind
<[email-masked]> wrote:
> 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?
>
>
>

The ACK_FREQUENCY frame essentially just gives a sender a mechanism to
alter the otherwise hard coded behavior of the receiver and otherwise
does nothing to change the logic. In QUIC we have 3 things which can
affect ACK frequency :
1. "packet tolerance" (I really wish we could come up with a better
term for this), which is defaulted to two, or every other packet.
2. Max ack delay, settable with a default of 25ms.
3. Out of order packets, via a threshold

An ACK is supposed to be sent when any of the above conditions are
met. The same is true when using the ACK_FREQUENCY frame, except that
the conditions can change during a connection. The packet tolerance
and max ACK delay are dynamic instead of static, so the logic should
be identical except for allowing these values to change. The out of
order packets behavior is also controllable in a binary fashion,
effectively removing the condition entirely.
> On Wed, Apr 7, 2021 at 9:56 AM Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> wrote:
>
> Hi,
>

Matt Joras

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 8 Apr 2021 08:44:39 +0000

Hi Matt,

your description below does not mention min_ack_delay and that's the part I was wondering about. The implementation as you explained below is also what I would expect but it less clear to me what to do with the values provided by min_ack_delay.

Mirja

On 07.04.21, 21:00, "Matt Joras" <[email-masked]> wrote:

    Hi Mirja,

    >
    > Mirja
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > 2) I filed https://protect2.fireeye.com/v1/url?k=826ab963-ddf18063-826af9f8-86fc6812c361-c26453d8be9cda19&q=1&e=28123d83-0cab-4534-b339-c4c176ece256&u=https%3A%2F%2Fgithub.com%2Fjanaiyengar%2Fack-frequency%2Fissues%2F48 for this.
    >
    >
    >
    > Thanks for reading, Ian
    >
    >
    >

    Matt Joras

---

From: Matt Joras <[email-masked]>
Date: Thu, 8 Apr 2021 07:02:12 -0700

Hi Mirja,

Sorry I must have misinterpreted your reply. I interpreted the
min_ack_delay to be nothing more than the lower bound a receiver is willing
to set its max_ack_delay to be. I.e. it's telling its peer to not send
ACK_FREQUENCY frames with an update max ACK delay value lower than it
specifies. In a sense it's a "min update max ACK delay", which is rather
wordy but more precise. Perhaps we should try to clarify the name or the
text describing it.

Thanks,
Matt

On Thu, Apr 8, 2021, 1:44 AM Mirja Kuehlewind <[email-masked]>
wrote:

> Hi Matt,
>
> your description below does not mention min_ack_delay and that's the part
> I was wondering about. The implementation as you explained below is also
> what I would expect but it less clear to me what to do with the values
> provided by min_ack_delay.
>
> Mirja
>
>
>     > 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"
>     > 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.
>     >
>
>     > 2) I filed
> https://protect2.fireeye.com/v1/url?k=826ab963-ddf18063-826af9f8-86fc6812c361-c26453d8be9cda19&q=1&e=28123d83-0cab-4534-b339-c4c176ece256&u=https%3A%2F%2Fgithub.com%2Fjanaiyengar%2Fack-frequency%2Fissues%2F48
> for this.
>     >
>     >
>     >
>     > Thanks for reading, Ian
>     >
>     >
>     >
>     > 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
>     > (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-masked] on behalf of [email-masked]> wrote:
>     >
>     >     Hello all,
>     >
>     >     [1]
> https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/
>     >
>
>     Matt Joras
>
>