Re: [tcpm] More motivating scenarios for tcpm-ack-pull

[Jonathan Morton <[e-mail]>]

> On 7 Dec, 2019, at 1:30 pm, Carles Gomez Montenegro <[e-mail]> wrote:
> 
> A concern with these techniques is that they are limited to some extent.
> For example, some applications produce small segments with the PSH flag
> set and benefit from Delayed ACKs (e.g. to piggyback ACKs and replies). In
> those cases, even regardless of the CWR flag, triggering immediate ACKs
> will avoid achieving performance benefits of Delayed ACKs.
> 
> In contrast, a dedicated resource (e.g. a TCP header reserved bit, as we
> propose in the draft) will not suffer such limitations. However, that
> resource needs to be allocated.
> 
> Summarizing, there may be two approaches to enable ACK Pull:
> 
> 1.- Overloading semantics of existing TCP header fields.
> 2.- Dedicating a resource.
> 
> Then the question is, considering pros and cons of both approaches: which
> one do we prefer?

I note that the semantics of the AKP flag differ subtly from that of PSH, in that the former says "I want an ack immediately", while the latter says "I have temporarily run out of data to send, so the receiving application's buffer should be flushed now".  It would be just as easy to modify existing receivers to treat PSH as an immediate ack request as to implement handling of AKP, so this simple use doesn't seem very compelling for allocating a scarce bit.

One potentially interesting application that was suggested to me, and which could legitimately motivate the use of a new reserved flag bit, was to provide a hint as to the correct Delayed Ack ratio, for use as a congestion control mechanism for acks.  Presently an ack stream can be anti-responsive, in that dropping acks from a heavily congested reverse path can actually increase the ack arrival rate, by improving the throughput of an uncongested forward path that was limited by ack-clocking.  AckCC exists as an RFC to address this problem - and would tend to benefit from Generalised ECN - but its reliance on a TCP option is less than optimal, given the traversal problems often cited.

A way that such a hint could work is by spacing AKP flags at the desired ack ratio.  A receiver observing AKP flags could then infer that the usual Delayed Ack rule requiring an ack for every two MSS received is suspended, and thus only send acks when AKP is set, the Delayed Ack timer expires, or some other forcing condition occurs.

It might be wise to restore normal Delayed Ack rules if the AKP flags stop indicating a reasonable ratio, for example if the Delayed Ack timer expires twice without an AKP flag arriving.  A maximum ratio could be specified as a sanity check, eg. 1:64, at which the receiver generates an ack even if an AKP hasn't arrived yet.

The above hinting semantics would remain compatible with other use cases mentioned, as AKP still forces an ack.  However this is also a theoretical disadvantage because the segments marked with AKP generally won't coincide with the trailing end of bursts caused, for example, by link-layer aggregation or IRQ "optimisation" in NICs.  Those trailing segments are where you would optimally want to trigger an ack, but as currently specified, AKP removes the receiver's discretion to synchronise a sparse Delayed Ack ratio with those segments.

This could be addressed by pairing AKP with PSH.  Both flags set together would require an immediate ack of that particular segment, with the implication both that an ack is expected promptly and that no more data is immediately forthcoming.  PSH by itself would continue to permit a degree of latitude with respect to ack timing, and merely indicates that prompt delivery to the application is required.  AKP by itself then requests a prompt ack, but one that may reflect following segments that are already in receive buffers and will be processed immediately after this one, as well as the hinting described above.

I think that's a reasonable amount of new functionality to introduce for the cost of one bit.  The above suggestion addresses both the original problem and another long-standing one, with minimal newly allocated resources and relatively little risk of traversal problems.  And (importantly) TCP doesn't break if receivers ignore or fail to understand it.

 - Jonathan Morton