Re: Two Notable Ack Frequency Issues

[Ian Swett <[e-mail]>]

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 <[e-mail]> wrote:

> 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).
>
>