Re: [tcpm] On Sender Control of Delayed Acks in TCP

[Carles Gomez Montenegro <[e-mail]>]

Hi Neil,

Thanks a lot for your comments!

Please find below my inline responses:

> On Wed, Apr 29, 2020 at 1:03 PM Scheffenegger, Richard <[e-mail]>
> wrote:
>> Eliciting an ACK under certain circumstances, for a timely continuation
>> of the data transmission / growth of the congestion window is a known
>> method to reduce network delay.
>>
>> E.g. Linux has been using the CWR flag for the purpose of sending out an
>> immediate ACK by the receiver, since there is an increased chance of a
>> very small cwnd when the sender had just reduced it's congestion window.
>>
>> https://lore.kernel.org/patchwork/patch/970486/
>>
>> and we also found latency improvements doing this when running
>> ECN-enabled sessions
>>
>> https://reviews.freebsd.org/D22670
>
> Yes, agreed.
>
> IMHO an explicit ACK-pull mechanism would be very nice for the cwnd<=1
> case.

(While this question is about the solution space, I'm anyway curious...)
In the context of datacenter networks, would you have any suggestion or
preference regarding the solutions that have been mentioned so far?

Or perhaps any particular requirement for a potential solution?

> In datacenter networks the BDPs tend to be so small, and the numbers
> of flows can be so large, that it's not unusual for a flow's fair
> share of the BDP to be one packet or less. If the flows want to
> maintain low queuing delays, then ideally they would be able to reduce
> their cwnd to 1 packet (or effectively even lower, with pacing). But
> the current behavior of TCP delayed ACKs often causes terrible delays
> with a cwnd of 1.

This is very useful input to expand the current section 3.2 of our
requirements draft, which focuses on high bit rate environments.

> The Linux TCP approach of sending an immediate ACK upon receiving a
> packet with CWR set (see Richard's link above) helps a lot with this
> case. But that's a non-standard heuristic, and doesn't help for
> senders that have a congestion control that does not use ECN CWR
> signals (e.g. Accurate ECN). Unless I'm missing something, it seems
> like endpoints using Accurate ECN are going to run into this same
> latency issue. To avoid this, I guess they may want to either use a
> cwnd >= 2, or make use of some new explicit ACK-pull mechanism.

Agreed.

Once again, thanks for your comments!

Carles



> best,
> neal
>