Re: Two Notable Ack Frequency Issues

[Ian Swett <[e-mail]>]

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