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

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
>>> <carlesgo@entel.upc.edu> 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.

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

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

Bob

> Agreed!
>
> Thanks,
>
> Carles
>
>
>>   - Jonathan Morton
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

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