Re: [tcpm] [EXTERNAL] Re: Seeking WG opinions on ACKing ACKs with good cause (was: Possible error in accurate-ecn)

[Jonathan Morton <[e-mail]>]

> On 30 Mar, 2021, at 10:18 pm, Vidhi Goel <[e-mail]> wrote:
> 
>>>> How is the sender of the pure ACKs supposed to react upon receiving the feedback that ACKs themselves are causing congestion? Option B conveys this additional information but how is it supposed to be used? Can a pure receiver get into such a state and does it need to start throttling ACKs?
>>> 
>>> This was discussed briefly during the WG. The receiver will act by reducing the ssthresh and cwnd (if it is not already minimum). This wouldn’t impact the receiver’s ACKing, but it would have an impact when the receiver starts sending data.
>> 
>> The information could also be used to tune the Delayed Ack ratio, via (for example) Gomez' Ack Rate Request option.  That *would* have a congestion control effect on ack traffic.
> 
> I don’t think we should change the ACK ratio, at the very least, we shouldn’t reduce it. ACKs are used to convey crucial information to the sender esp. when there is a congestion.

That really depends which direction the congestion is in.  No doubt plenty of acks are helpful when the forward path is congested.

But we are talking here about congestion being reported, by the network, to be on the path carrying the ack stream.  This means that either the network is on the point of *dropping* acks (and would already have done so, if they weren't marked ECT), which effectively changes the ack ratio without the endpoints' consent - OR the ack stream is now the limiting factor, via the ack clock mechanism, for the forward-path data throughput, so reducing the number of acks being generated would allow an increase in goodput.  In both cases, a mechanism for the sender to adjust the ack ratio of the receiver makes sense.

We can defer detailed discussion of the advantages or otherwise to threads on Ack Rate Request.

 - Jonathan Morton