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

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.

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].

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.

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

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.

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

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).

A good first draft.
Thank you.

Bob

On 15/03/2020 09:47, Carles Gomez Montenegro wrote:
> Hi Bob,
>
> Thanks, once again, for your kind suggestions!
>
> We agreed with your proposal below, and we published the initial version
> of a new I-D [1] that has the aim that you described below (i.e.
> requirements analysis plus discussion of suggested solutions).
>
> We hope the document can be useful to analyze the problem space in a more
> comprehensive approach.
>
> Should you have further comments, please do not hesitate to let us know!
>
> Cheers,
>
> Carles
>
> [1] https://tools.ietf.org/html/draft-gomez-tcpm-delack-suppr-reqs-00
>
>
>> Carles,
>>
>> It strikes me that there is a lot of interest in doing something like
>> ACK-pull, but also a lot of disagreement in where to draw the line
>> between what to do and what not to do.
>>
>> Can I suggest that a way to resolve this would be to start with an
>> informational requirements draft, that I am sure would be adopted as WG
>> business immediately given the interest. Whereas any particular choice
>> of mechanism at this stage would probably not get the necessary
>> consensus to be adopted.
>>
>> The requirements draft could discuss solutions, not as a "on this we all
>> agree" protocol, but in terms of their pros and cons, e.g. which
>> mechanisms could satisfy which requirements, so they can be judged
>> relative to each mechanism's complexity / traversibility / usage of bits
>> / etc.
>>
>> I will warn you that a requirements draft could itself add years to the
>> process (the accurate ECN requirements did [RFC7560]). But not if we
>> agree to allow a solution draft to start in parallel once the
>> requirements are starting to converge, rather than waiting for the
>> requirements to go thru the full RFC process.
>>
>>
>> You might prefer to continue evangelising ack-pull as a sufficient
>> solution, so I don't want to say a requirements draft is the only way
>> forward. But you saw my comment earlier - that once you've been through
>> all the years of effort of getting anything changed in TCP, you
>> sometimes feel that you wish you'd been more ambitious than just one bit
>> at the start.
>>
>>
>> Bob
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/