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

[Neal Cardwell <[e-mail]>]

On Fri, May 1, 2020 at 6:23 AM Carles Gomez Montenegro
<[e-mail]> wrote:
>
> 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?

Among the solutions outlined in
  https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00
my first preference would be the AKP option, since that approach
avoids burning a precious flag bit.

The AKP option may be stripped by some middleboxes, but (a) as a
performance optimization, that should be acceptable, and (b) for the
datacenter case (where cwnd=1 is a motivating use case) this should
not be a concern.

IMHO a flag bit makes sense for a small signal that a sender might
want to send frequently or at a high rate, but senders should not be
trying to force immediate ACKs frequently.

best,
neal