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 protected]> 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 > >
