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

Hi Richard,

Thanks a lot for your detailed explanation, pointers and comments.

Please find below my inline responses:

> Hi,
>
>
> as many here know, I'm very much interested in transactional data
> exchange across TCP sessions, rather than the more common architectural
> approach of assuming unlimited data to transmit unidirectional.
>
> One of the issues in that space is, that these application limited
> sessions can very frequently run out of data, and expirience idle periods.
>
> 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
>
> There are also numerous advisories, suggesting to disable delayed ACK
> completely when latency and/or timely bandwidth recovery under
> adversarial conditions is a major driver (e.g.
> https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/performance/esxi7-nfs-read-perf.pdf
> for one that was just published very recently).

This is, all, very useful feedback!

We plan to document the "ACK Pull" approach described above in our draft,
and the associated rationale.

Also, in our draft we currently mention that completely disabling delayed
ACKs might not be a good solution, but as you mentioned, there may be
environments where it may make sense to do so. We will add a note on this
as well.

> To summarize: While I agree that under steady load conditions, there are
> probably some benefits to be had by TCP itself thinning out ACKs, and
> address certain environment (e.g. asymetric link bandwidth), there are
> also conditions, where a timely ACK is crucial in maintaining low
> latency and timely bandwidth recovery. Short of having a mechansim do
> explicitly do this, at least for the latter issue, TLP (or TLP-like)
> methods are the only ones to currently address that - but the duplicate
> unconditional transmission of a (small) data packet does have additional
> cost associated with it.

Thanks for the assessment of the need for ACK thinning and ACK Pull
(depending on the considered scenario).

Cheers,

Carles

> Best regards,
>     Richard
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>