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

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

Hi Jonathan,

Many thanks for your message, and apologies for such a long delay in my
response.

Please find below my inline comments:

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

Thank you very much for providing such detailed explanations.

In our last update [1], we have added a new section (Section 5) that
describes reasons why the requested ACK rate might change over the
lifetime of a TCP connection. We have tried to capture your input above in
this new section.

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

Agreed.

We added a reference to RFC 2581, which states the following:

  “A TCP receiver SHOULD send an immediate duplicate ACK when an out-
   of-order segment arrives.”

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

Agreed.

Pending the discussion of how we represent the value of R in the TARR
option format, we now state in -03 that R=0 is not allowed. A TARR option
with R=1 requests immediate ACKs from the receiver.

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

Agreed as well. After some consideration, we found that N actually
duplicates functionality, as you suggested. In consequence, in -03 we
removed the N field from the TARR option, and we understand that it is
possible to produce the same effect by just using the R field.

Cheers,

Carles


>  - Jonathan Morton


[1]
https://datatracker.ietf.org/doc/html/draft-gomez-tcpm-ack-rate-request-03