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

From: Kuhn Nicolas <[email-masked]>
Date: Fri, 27 Mar 2020 09:52:48 +0000

Hi,

I understand that the current spec does not impose congestion control parameters.
That being said, some default parameters/algorithm should be included in the standard because TCP end-to-end is not QUIC end-to-end.
There are some strange wireless links out there and QUIC congestion control may deserve some more specified values in the standard.

I am not sure whether the proposal in "draft-fairhurst-quic-ack-scaling-02" is the best solution, but this approach clearly help asymmetric wireless networks and does not impact much symmetrical ones.
What does the group think about including this in the standard ?

Cheers,

Nicolas

---

From: Ian Swett <[email-masked]>
Date: Fri, 27 Mar 2020 07:02:44 -0400

I agree there are potential issues here, but I don't think
"draft-fairhurst-quic-ack-scaling-02" is something we should include in the
core drafts.  I did add some editorial text about why every other packet is
a SHOULD, not a MUST in #3518
<https://github.com/quicwg/base-drafts/pull/3518>.  See Issue(#3529
<https://github.com/quicwg/base-drafts/issues/3529>) for more discussion.

If we were going to do something in the core draft, I think it should be
similar to draft-iyengar-quic-delayed-ack
<https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack>, which
provides a robust solution to a wider set of problems, including how to
decrease max_ack_delay post handshake for very short RTT flows(ie:
datacenter networking).  However, the mood at the Zurich interim was
against making any unnecessary changes to the core spec at this stage in
the process, and this wasn't seen as necessary.

Ian

On Fri, Mar 27, 2020 at 5:53 AM Kuhn Nicolas <[email-masked]> wrote:

> That being said, some default parameters/algorithm should be included in
> the standard because TCP end-to-end is not QUIC end-to-end.
>
> There are some strange wireless links out there and QUIC congestion
> control may deserve some more specified values in the standard.
>
>
>
> I am not sure whether the proposal in
> “draft-fairhurst-quic-ack-scaling-02” is the best solution, but this
> approach clearly help asymmetric wireless networks and does not impact much
> symmetrical ones.
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 27 Mar 2020 14:22:51 +0000

See below,

On 27/03/2020 11:02, Ian Swett wrote:
> "draft-fairhurst-quic-ack-scaling-02" is something we should include 
> in the core drafts.
> I did add some editorial text about why every other packet is a 
> SHOULD, not a MUST in #3518 
> <https://github.com/quicwg/base-drafts/pull/3518>.
Why? This is about "bandwidth constrained", but this isn't at all clear 
how a receiver would know that it's return path was "constrained" in 
resource or bandwidth, that's why the core spec needs to choose an 
appropriate number.
> See Issue(#3529 <https://github.com/quicwg/base-drafts/issues/3529>) 
> for more discussion..
>
I don't understand #3529, since QUIC ACK traffic, actually does consume 
more capacity than TCP ACK traffic.

> If we were going to do something in the core draft, I think it should 
> be similar to draft-iyengar-quic-delayed-ack 
> 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.
> including how to decrease max_ack_delay post handshake for very short 
> RTT flows(ie: datacenter networking).  However, the mood at the 
> Zurich interim was against making any unnecessary changes to the core 
> spec at this stage in the process, and this wasn't seen as necessary.
>
I saw draft-iyengar-quic-delayed-ack discussed in the Zurich Interim, 
(draft-fairhurst-quic-ack-scaling was not, likely the remote audio was 
so troubled nobody heard and nobody discussed). The WG does need to look 
at return path issues - I suggest we collect data and we use that as the 
basis of discussion. I think we can get data ready for a couple of weeks 
from the implementations we use.

The changes proposed do not appear to require many lines of change, and 
may be fairly minor changes in implementations that implement the rest 
of the QUIC spec.

Gorry

> Ian
>
> On Fri, Mar 27, 2020 at 5:53 AM Kuhn Nicolas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     That being said, some default parameters/algorithm should be
>     included in the standard because TCP end-to-end is not QUIC
>     end-to-end.
>
>     There are some strange wireless links out there and QUIC
>     congestion control may deserve some more specified values in the
>     standard.
>
>     “draft-fairhurst-quic-ack-scaling-02” is the best solution, but
>     this approach clearly help asymmetric wireless networks and does
>     not impact much symmetrical ones.
>

---

From: Ian Swett <[email-masked]>
Date: Fri, 27 Mar 2020 10:57:32 -0400

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

> core drafts.
> I did add some editorial text about why every other packet is a SHOULD,
> not a MUST in #3518 <https://github.com/quicwg/base-drafts/pull/3518>.
>
> See Issue(#3529 <https://github.com/quicwg/base-drafts/issues/3529>) for
> more discussion..
>

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.

> including how to decrease max_ack_delay post handshake for very short RTT
> flows(ie: datacenter networking).  However, the mood at the Zurich interim
> was against making any unnecessary changes to the core spec at this stage
> in the process, and this wasn't seen as necessary.
>
> (draft-fairhurst-quic-ack-scaling was not, likely the remote audio was so
> troubled nobody heard and nobody discussed). The WG does need to look at
> return path issues - I suggest we collect data and we use that as the basis
> of discussion. I think we can get data ready for a couple of weeks from the
> implementations we use.
>
> may be fairly minor changes in implementations that implement the rest of
> the QUIC spec.
>
> Gorry
>
> Ian
>

---

From: Matt Joras <[email-masked]>
Date: Fri, 27 Mar 2020 16:35:30 -0700

> RTT and 10 packets if that was compatible with the sender's congestion

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
.

Matt Joras

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 29 Mar 2020 09:39:42 +0100

On 27/03/2020 23:35, Matt Joras wrote:
>
>
> 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://tools.ietf.org/html/draft-iyengar-quic-delayed-ack>,
>>         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 
> 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.
>
Clearly QUIC needs to say a default. I'm curious why choose a default 
Packet Tolerance (aka ACK Ratio) of 1:2?

My hope was that the baseline QUIC would have been better than TCP, even 
across paths that had asymmetry - and this would allow QUIC to removed 
any motivation for a need to do special queing/processing for QUIC ACKs.

> https://janaiyengar.github.io/ack-frequency/draft-iyengar-quic-delayed-ack.html.
>
Yes, it's interesting, there are many interesting possibilities here.  
My point, is an endpoint can't just adjust the ACK policy because of an 
asymmetric (radio) link on path. The transport has no way to know this. 
The default needs to be appropriate.
Gorry