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
