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

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

Hi Jonathan,

(Sorry for the late response.)

Thanks a lot for your detailed response, which helped shape our latest
draft [1] in several ways.

While we focus on analyzing the problem space and its requirements, it
will be good to keep an eye on potential solutions as well, including the
one you describe below. In particular, I found the idea of spacing AKP
flags (or something similar) in order to control the desired ACK ratio to
be very interesting!

Thanks again!

Cheers,

Carles

[1] https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00.
Comments are very much welcome!


> 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