Re: Working Group Last Call (WGLC) comments for draft-ietf-quic-ack-frequency.

[Martin Thomson <[e-mail]>]

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