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

[Neal Cardwell <[e-mail]>]

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.

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.

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.

best,
neal