Re: [tcpm] Question on draft-gomez-tcpm-ack-rate-request

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

Hi again, Bob,

Please find below my inline responses:

> Carles,
>
> On 12/03/2021 12:27, Carles Gomez Montenegro wrote:
>> Hi Jonathan,
>>
>> Thank you for your quick response!
>>
>> Please find below my inline responses:
>>
>>>> On 12 Mar, 2021, at 12:00 pm, Carles Gomez Montenegro
>>>> <[e-mail]> wrote:
>>>>
>>>>> Example:
>>>>>
>>>>>       0                   1                   2                   3
>>>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>      |     Kind      |     Length    |              ExID
>>>>> |
>>>>>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>>      |I|X|Value|
>>>>>      +-+-+-+-+-+-+
>>>>>
>>>>> The bit "X"=0 would be equivalent to "R"=0, i.e., immediately request
>>>>> ACKs. In that case, the 6 bit field "Value" could encode the value of
>>>>> "N"
>>>>> described in draft-gomez-tcpm-ack-rate-request-02.
>>>>>
>>>>> The bit "X"=1 would enable delayed ACKs ("R">0) and the 6 bit field
>>>>> "Value" would encode the number that "R" defined in
>>>>> draft-gomez-tcpm-ack-rate-request-02.
>>>>>
>>>>> The "I" bit would be defined as in
>>>>> draft-gomez-tcpm-ack-rate-request-02.
>>>>> (It may make sense to change the order and or naming of the fields,
>>>>> or
>>>>> other details of the encoding - this is just an example.)
>>>> Yes, your proposal above makes sense!
>>>>
>>>>> As far as I can see, there *is* a difference between this encoding
>>>>> and
>>>>> the
>>>>> one in draft-gomez-tcpm-ack-rate-request-02: There is one bit less to
>>>>> encode the value of "R", and two bits less to encode the value of
>>>>> "N".
>>>>> But
>>>>> would that matter? Do we really expect values larger than 63 (or 63)
>>>>> for
>>>>> "R" and "N"?
>>>> Yes, that is a good question, and it would be great to hear what the
>>>> WG
>>>> thinks about that. That is: are there use cases where R or N might
>>>> need
>>>> to
>>>> be greater than 63?
>>> My gut feeling is that values up to 63 are sufficient in both cases.
>> I personally tend to agree... It will be interesting to see if there is
>> any particular use case which might require supporting greater values...
>
> [BB] It all depends how long you want the life of this option to be.
> Let's imagine it becomes common to request a DelACK ratio of cwnd/8.
> Then the option would have to be able to cope with growth in packet
> rates over its lifetime.
>
> Apparently the doubling time of link rate has been about 1.5 years since
> the 1970s (according to Wikipedia's page on Edholm's Law). Let's assume
> growth continues similarly (with no justification other than how else
> can we decide?). I guess it takes about 5 years to get a TCP option
> through the IETF. So to be worth the effort, it's surely got to last at
> least 15-25 years after that, preferably longer. 2^ (30 yr / 1.5 yr) ~=
> 10^6. I.e. TCP might have to handle a window about a million times
> larger than today by the end of life of this option.
>
> If that seems ridiculous, it is. As a sanity check on Edholm's Law, in
> the last 30yrs of TCP (since 1991) that would imply a growth of
> 2^(30/1.5) ~= 10^6 . Given typical TCP windows for Internet access links
> are currently of the order of 100 segments per RTT (30Mb/s with 1500B
> packets over 40ms RTT). Growth of 10^6 to reach only 100 implies TCP's
> window was 0.0001 of a segment in 1991. Clearly daft. What's wrong? Not
> sure. Max packet size has stayed largely unchanged over the public
> Internet., so it's not that. Admittedly doubling time relates to link
> rates, not flow rates. However there's no evidence of more simultaneous
> flows.
>
> Whatever, 63 doesn't seem enough to me.

Thank you so much for such a thoughtful analysis.

We can see that, even if the theoretical growth numbers predicted based on
the Edholm's Law don't seem to match reality, it may be wise to consider a
 maximum value of R covering potential future scenarios (i.e. beyond 63).

>>> It might be possible to contemplate a different encoding which
>>> allocates
>>> more range to one use of the field than the other, but this encoding is
>>> simple enough to be hard to accidentally misinterpret, and that has to
>>> be
>>> considered a Good Thing and weighed against the benefits of any
>>> alternative.
>
> [BB] It certainly seems unnecessary to have as much precision at the
> high end as at the low. No-one will care whether they can set the ack
> ratio to exactly 57 or 56 or 58.
>
> You can divide 6 bits into a 4-bit mantissa (m) and 2-bit exponent (e).
> A couple of schemes come to mind:
> R = (m+1)*2^(2*e)            => min 1; max 1024
> R = (m+1)*2^(4*e)            => min 1; max 65536

Thank you so much for your proposals.

In -03 we are considering your first suggestion above (with max R equal to
1024). It is labelled "OPTION 2".

At this moment, we are keeping also the more simple encoding approach
(with max R equal to 63) in the draft as "OPTION 1" to allow easier
comparison. We plan to ask for feedback about this in the tcpm meeting.

> Note that I don't see the need for R=0 to be special. It means the ack
> ratio is 1. Which is why both formulae above include (m+1).
> I.e. R=0 means ack ratio 1; R=1 means ack ratio 2, and so on (think of R
> as the number of unacked packets between ACKs).

We agree that supporting R=0 is not needed.

Perhaps, once we agree on the encoding for R, we can see whether R or
"R+1" means the ACK rate.

Thanks,

Carles