I agree with Gorry, but I would also strengthen the requirements in Section 6.1 to use SHOULD/RECOMMEND for the receiver behaviour. The text is fine, but it uses RFC 6919 rather than RFC 2119.
On Thu, Nov 2, 2023, at 22:59, Gorry Fairhurst wrote: > Thanks for completing this work. I’ve just read the latest version of > draft-ietf-quic-ack-frequency as a part of the WGLC, and also checked > the issues and the diff. Overall, this draft seems a consistent and > complete document that I think will be useful to publish as a RFC. > > I have one request: > > In reviewing the issues I see the editors decided to not add any > recommendation for how often an ACK needs to be sent. I still think this > is a serious omission that the WG ought to address. In section 8.1, para > 2, the text says a “sender **CAN** cause a receiver to send ACKs at > least once per RTT”….(see #168). The editors argued (in #211) that this > document can be impartial on whether this is important, but I think we > do need to review that: People reviewing specifications in the IETF are > often reminded that a protocol ought to provide at least one feedback > packet per RTT to close the control loop when intended for Internet > deployment, yet this document seeks to relax the ACK procedure for QUIC > (which I fully agree with), but does not provide this guidance, which I > would have thought was essential to be published as a PS. > > My request is to RECOMMEND at least 1 ACK/RTT when sending data, to > provide prompt feedback and refer to RFC 8961. > > RFC 8961 is BCP and says, for instance: > Timer “observations SHOULD be taken and incorporated into the RTO at > least once per RTT or as frequently as data is exchanged in cases where > that happens less frequently than once per RTT.” > > Can we please provide this guidance and add a reference to this guidance? > > Best wishes, > > Gorry
