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

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

Hi again, Jonathan,

Please find below my inline response:

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