[tcpm] Sender control of Delayed ACKs (was Re: More motivating scenarios for tcpm-ack-pull)

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

Hi Bob,

Thanks a lot once again for all your comments!

As you may have seen, we just published a -01, with the aim to address
your comments.

Please find below our inline responses:

> Carles & Jon,
>
> Yes, if the tcpm WG was prepared to consider adopting this, I'd support
> it.
>
> A few comments:
>
> I'm not sure I would limit it to "suppression" of delayed ACKs, and I
> don't just mean it should include releasing suppression. In many
> circumstances the sender would be happy with less frequent ACKs than the
> receiver is generating. E.g. with high performance data transfers, 1/16
> would often be fine when there are hundreds of packets in flight. But,
> because the receiver can't be sure whether the sender would suffer one
> of the downsides to delaying ACKs, it maintains a conservatively low
> delayed ACK ratio.
>
> So perhaps a better scope (and title) would be "Sender control of
> Delayed ACKs in TCP"?
>
> I've added 'in TCP', because I think it's useful to make the scope
> concrete. But I think this doc could also be useful for other transport
> protocols, particularly QUIC.

Agreed!

We have updated accordingly the document (including the title and abstract).

> S3.1 & S3.2 Slow start & High bit rate environments and short data
> segments
>
>     However, use of Delayed ACKs reduces the amount
>     of ACKs received by the sender, thus reducing the rate of cwnd
>     growth, increasing transfer time and reducing throughput, when
>     compared with sending an ACK for each incoming data segment.
>
> I think ABC (appropriate byte counting) allows the sender to
> unilaterally address that concern without needing ACK Pull [RFC3465].

Thanks for the comment. Version -01 now reflects that ABC could be used to
address the concern, while also mentioning that it remains as an
experimental mechanism, not fully included in RFC 5681.

> The reference to 'more rapidly get up to speed during slow-start without
> overshoot' is a bit opaque. Rather than "describing by reference", it
> needs to describe the lack of ability to send patterns of packets (e.g.
> chirps) and be able to time the gaps between the ACKs. At minimum, the
> citation should refer to Appendix B.4, which was the mechanism proposed
> to do ACK pull at the time.

Agreed. We have added a more explicit description in -01, and we also
refer to Appendix B.4.

> S.3.4 Beyond classic ACK transmission behavior
>
> It ought to mention that many link technologies (Satellite, DOCSIS, LTE,
> WiFi, ...?) do TCP ACK thinning 'cos TCP doesn't do it itself, but it
> improves performance (when the ACK stream becomes the bottleneck for the
> forward path, because many reverse paths have pathetic bandwidth, esp.
> if a parallel upload is going on).
>
> See "ACK Scaling and Performance on AsymmetricPaths"
> https://erg.abdn.ac.uk/~downloads/ackscaling.pdf

Agreed. Added in -01. And thanks for the pointer!

> 4.2. Per-segment granularity
>
> Between per-segment and permanent, there's per-connection suppression.
> I'm not saying that would be any use, I'm just saying it doesn't have to
> be permanent.

Agreed! Added in -01.

> 4.4 Support for enabling generic ACK ratios
>
> This reminds me of a subtle additional requirement. When you move from
> ACK pull to controlling the ACK ratio, there's an important distinction
> between a sender's packet stopping the receiver delaying the ACK for
> /that/ packet (as in ACK pull), vs. setting the receiver's Delayed ACK
> policy for /that and subsequent/ packets.
>
> This raises the question, should the mechanism use soft state (repeated
> in every packet), or connection state (remembered by the receiver)?
> Which is hinted at in your section on "safe return to normal operation".x

We have added text in section 4.4, with the aim to incorporate your
comments above.

> 4.10+ Extra requirement: Who's in control?
>
> The receiver cannot be expected to control ACKs in any way the sender
> wants, which it will not always be able to honour anyway. So the
> semantics have to be of a hint, not a request or a command. Then there's
> the question of whether the receiver just does what it wants, or whether
> it ought to tell the sender it's not doing what it was asked.
>
> It might seem that the the receiver silently not doing what it's told is
> the simple case. However,  it adds complexity to anything trying to rely
> on the behaviour (e.g. the slow start examples).

We have added the new requirement, and have edited its content, based on
your input.

> A good first draft.
> Thank you.

Once again, thanks a lot for your comments!

Best regards,

Carles


> Bob