Subject: Two Notable Ack Frequency Issues

From: Ian Swett <[email-masked]>
Date: Sat, 11 Sep 2021 19:50:16 -0400

Most of the outstanding design issues were discussed at the last IETF
meeting and had clear resolutions.  As such, I think we're close to being
ready to ship this draft.

One issue not discussed(#48
<https://github.com/quicwg/ack-frequency/issues/48>) regarding ECN CE and a
new issue(#65 <https://github.com/quicwg/ack-frequency/issues/65>) adding a
NO_ACK frame are notable changes and have not received wide discussion, so
I wanted to publicize them here before merging any changes.

I think both changes are heading in the right direction, and both have PRs
you can comment on.

I'd like to merge these in a week or so if there's no pushback, so please
take a look when you have time.

Thanks, Ian

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 13 Sep 2021 09:59:52 +1000

The first seems benign.

The second is pure scope creep and I'm opposed to adding it (as I am opposed to IMMEDIATE_ACK, which has not been discussed on the list thus far from what I can see, though that is less objectionable).  The discussion that is available really doesn't motivate it more than "that might be nice".  I would have expected a lot more discussion about what this is supposed to achieve, how an endpoint might decide that it is necessary to use the feature, under what conditions it might be inadvisable, precedence (NO_ACK > IMMEDIATE_ACK: why?), and probably some other stuff I haven't thought of yet.

On Sun, Sep 12, 2021, at 09:50, Ian Swett wrote:
> meeting and had clear resolutions.  As such, I think we're close to 
> being ready to ship this draft.
> 
> <https://github.com/quicwg/ack-frequency/issues/48>) regarding ECN CE 
> and a new issue(#65 
> <https://github.com/quicwg/ack-frequency/issues/65>) adding a NO_ACK 
> frame are notable changes and have not received wide discussion, so I 
> wanted to publicize them here before merging any changes.
> 
> I think both changes are heading in the right direction, and both have 
> PRs you can comment on.
> 
> I'd like to merge these in a week or so if there's no pushback, so 
> please take a look when you have time.
> 
> Thanks, Ian

---

From: Vidhi Goel <[email-masked]>
Date: Sun, 12 Sep 2021 17:15:30 -0700

Hi Ian,

> One issue not discussed(#48 <https://github.com/quicwg/ack-frequency/issues/48>) regarding ECN CE
Left a comment on this PR - https://github.com/quicwg/ack-frequency/pull/68 <https://github.com/quicwg/ack-frequency/pull/68>

Vidhi

> On Sep 11, 2021, at 4:50 PM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> Most of the outstanding design issues were discussed at the last IETF meeting and had clear resolutions.  As such, I think we're close to being ready to ship this draft.
> 
> One issue not discussed(#48 <https://github.com/quicwg/ack-frequency/issues/48>) regarding ECN CE and a new issue(#65 <https://github.com/quicwg/ack-frequency/issues/65>) adding a NO_ACK frame are notable changes and have not received wide discussion, so I wanted to publicize them here before merging any changes.
> 
> I think both changes are heading in the right direction, and both have PRs you can comment on.
> 
> I'd like to merge these in a week or so if there's no pushback, so please take a look when you have time.
> 
> Thanks, Ian

---

From: Christian Huitema <[email-masked]>
Date: Sun, 12 Sep 2021 17:28:04 -0700

I left a comment on the NO_ACK issue and PR.

I don't think this solves a real issue, and I do think it could turn out 
to be an interesting footgun, as in "packet 1, don't ack; packet 2, do 
ack; oops, packet 2 was lost, let's repeat both 1 and 2." Also, if a 
packet carried both "immediate ack" and "don't ack", my preference would 
be to return a protocol error, not try to second guess a meaning. Plus, 
suppose an implementation just ignores the "don't ack" frames. What is 
the effect on the protocol?

-- Christian Huitema

---

From: Matt Joras <[email-masked]>
Date: Sun, 12 Sep 2021 17:50:30 -0700

Speaking as an individual. There may not have been any list discussion
about IMMEDIATE_ACK, but the idea (without that particular label) has been
discussed since we were still meeting in person. It is a relatively
straightforward idea which has also been explored for TCP[1]. It makes a
lot of sense to have this mechanism in the same document which introduces a
mechanism to control ACK frequency, as it allows the sender to potentially
mitigate some of the issues with reducing ACK frequency.

As for NO_ACK, I think it is best considered in the context of the related
issue[2] in the DATAGRAM draft. That is the driving usecase for the frame
at the moment, AFAIK. There are obviously a lot of considerations when
effectively disabling ACKs in QUIC, but these considerations are
considerably diminished when used with non-retransmitted application data
like DATAGRAMs (which may well be using application-layer congestion
control instead of QUIC congestion control as well). As I mentioned on the
issue, I am supportive of the feature for the simple reason that it will
enable existing UDP datagram applications to transition to QUIC datagrams
with minimal changes to the amount of data on the wire. This problem could
be solved with a DATAGRAM_NO_ACK frame introduced by a new draft, but that
has other considerations. I don't feel strongly that this needs to be in
this document, but clearly there is a need for a mechanism to selectively
limit ACKs.

[1] https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-pull-01
[2] https://github.com/quicwg/datagram/issues/42

On Sun, Sep 12, 2021 at 5:00 PM Martin Thomson <[email-masked]> wrote:

> The first seems benign.
>
> The second is pure scope creep and I'm opposed to adding it (as I am
> opposed to IMMEDIATE_ACK, which has not been discussed on the list thus far
> from what I can see, though that is less objectionable).  The discussion
> that is available really doesn't motivate it more than "that might be
> nice".  I would have expected a lot more discussion about what this is
> supposed to achieve, how an endpoint might decide that it is necessary to
> use the feature, under what conditions it might be inadvisable, precedence
> (NO_ACK > IMMEDIATE_ACK: why?), and probably some other stuff I haven't
> thought of yet.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 13 Sep 2021 10:58:42 +1000

On Mon, Sep 13, 2021, at 10:50, Matt Joras wrote:
> As for NO_ACK, I think it is best considered in the context of the 
> related issue[2] in the DATAGRAM draft. 

Tommy already said it:

"Yes, I think having a new document with a problem statement and proposal would be best here."

---

From: Roberto Peon <[email-masked]>
Date: Mon, 13 Sep 2021 19:33:29 +0000

Without ACKs, it seems difficult to do flow control and/or congestion control.
I'd be quite opposed to ditching ACKs unless it was extremely clear how to achieve a stable internet without it.
This is worthy of a fair bit of discussion that I've yet to see here.
-=R

On 9/12/21, 5:59 PM, "QUIC on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    Tommy already said it:

---

From: Ian Swett <[email-masked]>
Date: Mon, 13 Sep 2021 22:04:01 -0400

Thanks for all the feedback, I've substantially changed my PR on NO_ACK to
be DELAY_ACK.  I already have a use case for DELAY_ACK, so I think it's
potentially quite useful.  I'd also like to change how peers ACK(or rather
do not ACK) PADDING only packets, but I have not done that in this
<https://github.com/quicwg/ack-frequency/pull/67> PR.

I also left a recent comment
<https://github.com/quicwg/ack-frequency/issues/48#issuecomment-918692616> on
the ECN issue, since I'm not 100% sure all endpoints that use ECN will want
the Accurate ECN response.  I'm not sure we're in a good place to redesign
ECN response, but I suggested what I thought were the 3 most
straightforward options.

On IMMEDIATE_ACK, it both solves a clear problem(PN skipping no longer
elicits an immediate ACK when 'Ignore Order' is true) as well as following
in the footsteps of the TCP drafts.  Additionally, it was discussed at the
last IETF, and the only outstanding question I am aware of from that
discussion was what to name the frame (
https://github.com/quicwg/ack-frequency/issues/34#issuecomment-890272310).
Slides 7 to 11
<https://github.com/quicwg/wg-materials/blob/main/ietf111/ack-frequency.pdf>
are
the relevant slides.

>From the minutes on IMMEDIATE_ACK, the last two points are:

*Matt:* seems like most people are in favor of option 2, 1-byte frame (or
semi-PING frame, see jabber). Doing option 1 (header bit) is probably not
realistic.
*Jana:* will go ahead with option 2. If strong disagreement, please comment
on issue <https://github.com/quicwg/ack-frequency/issues/34>.

Thanks, Ian

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 14 Sep 2021 13:41:02 +1000

On Tue, Sep 14, 2021, at 12:04, Ian Swett wrote:
> I've substantially changed my PR on NO_ACK to be DELAY_ACK.

I'm not sure that I understand this change.  The PR reads:

> The DELAY_ACK Frame causes the receiver to send an immediate acknowledgement,

Is that missing a negation somewhere?

If I'm guessing correctly, what you want to say is that this packet should start the delayed acknowledgment timer if it is not already started, but not be cause for an immediate acknowledgment.  That is, no immediate acknowledgment is generated even if this packet causes the number of unacknowledged packets to hit the Ack-Eliciting Threshold or it appears out of order and Ignore Order is not enabled.

This effectively disables both the Ack-Eliciting Threshold and a setting of Ignore Order = 0.  Only the timer remains.  That might be safer than completely disabling acknowledgment, but I think my previous position stands on this.

> On IMMEDIATE_ACK, it both solves a clear problem

I can see how IMMEDIATE_ACK works (I had forgotten previous discussions and the linked discussion is a little thin).  I'm OK with defining a frame for this purpose.

FWIW, this is better than packet number skipping (which was always a kludge).

---

From: Ian Swett <[email-masked]>
Date: Tue, 14 Sep 2021 13:39:07 -0400

Thanks for the continued feedback.  I'm going to abandon DELAY_ACK for now
and let it or a similar mechanism go into a separate draft at some point in
the future.

I'll focus on the ECN issue and PR, in hopes of getting that into good
shape.

Thanks, Ian

On Mon, Sep 13, 2021 at 11:41 PM Martin Thomson <[email-masked]> wrote:

> If I'm guessing correctly, what you want to say is that this packet should
> start the delayed acknowledgment timer if it is not already started, but
> not be cause for an immediate acknowledgment.  That is, no immediate
> acknowledgment is generated even if this packet causes the number of
> unacknowledged packets to hit the Ack-Eliciting Threshold or it appears out
> of order and Ignore Order is not enabled.
>
> This effectively disables both the Ack-Eliciting Threshold and a setting
> of Ignore Order = 0.  Only the timer remains.  That might be safer than
> completely disabling acknowledgment, but I think my previous position
> stands on this.
>
> I can see how IMMEDIATE_ACK works (I had forgotten previous discussions
> and the linked discussion is a little thin).  I'm OK with defining a frame
> for this purpose.
>