Subject: RE: Comments on draft-fairhurst-quic-ack-scaling-02

From: "Border, John" <[email-masked]>
Date: Thu, 16 Apr 2020 16:25:44 +0000

I think the extension is definitely needed.  But, I also think the core spec should use a better default value.

From: QUIC <[email-masked]> On Behalf Of Matt Joras
Sent: Friday, March 27, 2020 7:36 PM
To: Ian Swett <ianswett=[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; Kuhn Nicolas <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Comments on draft-fairhurst-quic-ack-scaling-02

**EXTERNAL EMAIL**

On Fri, Mar 27, 2020 at 7:59 AM Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Mar 27, 2020 at 10:23 AM Gorry Fairhurst <[email-masked]<mailto:[email-masked]>> wrote:

If we were going to do something in the core draft, I think it should be similar to draft-iyengar-quic-delayed-ack<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-iyengar-quic-delayed-ack__;!!Emaut56SYw!mah79ur0v_uaikXXpGT_UgDKLEojo1Q4nga9wkw3BAkXlYYAIt4r5J7zgPfqCWdG8Q$>, which provides a robust solution to a wider set of problems,
No it does not. It provides a solution to other problems. This is a good extension, but it is not the same issue.

I disagree.  Can you clarify a problem solved by your draft that cannot be solved by the extension?  A sender can send an ACK_FREQUENCY frame when exiting slow start to inform the peer of a new value for the number of packets before an immediate ACK and a new max_ack_delay, which could be 1/4 RTT and 10 packets if that was compatible with the sender's congestion controller.

I just read through draft-fairhurst-quic-ack-scaling, and I agree with Ian here. While the ack-scaling draft provides a lot of great background information and justification, its ultimate recommendation could be viewed simply as an application of the ACK_FREQUENCY extension. I.e. it is one such acknowledgment policy that can be chosen by implementers and accomplished by means of the ACK_FREQUENCY frame. In fact I would go so far to say that the ack-scaling draft would be more useful if framed entirely supposing the existence of the ACK_FREQUENCY frame -- I think it is useful to have codified recommendations implementers can choose from, and draft-fairhurst-quic-ack-scaling could simply be one such policy.
In Zurich indeed it didn't seem there was a lot of appetite for adopting the ACK_FREQUENCY mechanics into the core transport, but similarly I don't think there is abundant appetite for adopting changes to the existing acknowledgment text. We can certainly revisit this, but if we were to then I would be in favor of keeping the default policy and introducing the mechanics of ACK_FREQUENCY, rather than adopting the ack-scaling recommendation as the default. I say this as an implementer who has that exact policy deployed rather than the default on in the transport text.

For reference, the latest text of the draft defining ACK_FREQUENCY is here: https://janaiyengar.github.io/ack-frequency/draft-iyengar-quic-delayed-ack.html<https://urldefense.com/v3/__https:/janaiyengar.github.io/ack-frequency/draft-iyengar-quic-delayed-ack.html__;!!Emaut56SYw!mah79ur0v_uaikXXpGT_UgDKLEojo1Q4nga9wkw3BAkXlYYAIt4r5J7zgPcz0T2ZJw$>.
Matt Joras