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

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 21 Mar 2022 19:03:07 +0100

Hi again, Jonathan,

Please find below my inline response:

>> On 12 Mar, 2021, at 12:00 pm, Carles Gomez Montenegro
>> <[email-masked]> 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.
>
> 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.

Many thanks for your feedback!

At this moment, we are considering two possible approaches in Section 4 [1]:

- OPTION 1, which corresponds to the straightforward encoding with a
maximum supported value of R=63.

- OPTION 2, suggested by Bob, which also captures the idea of better
granularity for low R values, but allows encoding a maximum value of R
equal to 1024.

>  - Jonathan Morton

Cheers,

Carles

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

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Mon, 21 Mar 2022 19:24:00 +0100

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:
>>
>>>>>      |     Kind      |     Length    |              ExID
>>>>> |
>> 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).

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