Re: Two Notable Ack Frequency Issues

[Christian Huitema <[e-mail]>]

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

On 9/12/2021 4:59 PM, Martin Thomson 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.
>
> On Sun, Sep 12, 2021, at 09:50, Ian Swett 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