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

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

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

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

Agreed!

Thanks,

Carles


>  - Jonathan Morton