Re: [tcpm] some comments on draft-gomez-tcpm-ack-rate-request-02.

[Jonathan Morton <[e-mail]>]

>>    For example, one of my naive questions is how often we want to change the frequency of ACKs.
>>    In 'small' or 'large' scenarios in the draft, it seems to me that it might be sufficient to use the same ACK frequency during the connection.
>>    It would be good if the draft describes the needs of changing frequency.
> 
> Agreed, we will add some guidance in this regard.
> 
> Yes, in many scenarios it may make sense to just set the ACK frequency
> once during the connection.
> 
> We'll think further about whether there could be particular scenarios
> where the ACK frequency might need to be changed during the connection
> lifetime.

It seems to me that the ack frequency could depend mostly on the cwnd value used by the sender, which can change over the connection's lifetime for many reasons, and is generally not directly known by the receiver (though it might be inferred by estimated RTT, segment size, and observed delivery rate).

In particular, cwnd will start at a low value and grow rapidly during the slow-start phase, then settle into a reasonably consistent range for the congestion-avoidance phase - assuming the underlying BDP remains constant.  Shifts in routing, or the addition or removal of significant load from the path the flow shares, may change the underlying BDP significantly; the cwnd should be expected to change accordingly, and this may prompt a change in ack rate.

So we should expect some changes to the ack rate to be requested over the lifetime of the connection, but very frequent updates seem unlikely if the ack rate is derived from the cwnd.  This does not seem difficult to me.

Conversely, the ack frequency may be controlled by "ack congestion control", alone or in combination with a derivation from the cwnd.  That is, the sender may notice that acks it receives cover more segments than the ack rate requested, indicating ack decimation en route, and decide to reduce the ack frequency to reduce network load up to the ack decimation point.  Future updates may also permit CE marks to appear on pure acks.  This might involve more frequent ack rate updates, perhaps once an RTT, as the algorithm adjusts and probes around an operating point.

> Well, yes, the phrase "as long as packet reordering does not occur" might
> not be clear enough here. The intent was to say that one ACK will be sent
> every R full-sized received data segments, but if there is reordering,
> then a different amount/rate of ACKs may be sent for a while.

Isn't this sort of thing covered by existing Delayed Ack specifications?  They are just cases in which an immediate ack is called for, overriding the Delayed Ack algorithm and resetting the counter and timer associated with it.  You should just be able to make a normative reference to that.

>>   Also, since N looks finite number, I'm wondering how to set R=0 for the
>> entire connection. Or, we shouldn't do such a thing?
> 
> Good point!
> 
> Perhaps we can define a special value for N meaning "infinity".

An R value of 1 or 0 should produce a similar effect, should it not?  I think this falls into the category of choosing the ack frequency based on the sender's cwnd, which for the resource-constrained sender is a permanently small value.  I think it's important to describe with precision what the meanings of R=1 and R=0 are in any case; it's one of those pesky little corner cases.

Conversely, the N field would be most useful for advanced congestion control algorithms which have a need to probe latency statistics at high fidelity, but only for a short period at a time.  We shouldn't use the N field to duplicate functionality that can adequately be described by the R field.

 - Jonathan Morton