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

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

Hi Michael,

Thanks for your message!

Please find below my inline responses:

> Hi Carles,
>
> I wonder if it is possible to save one byte of space in the option
> proposed in draft-gomez-tcpm-ack-rate-request-02.
>
> As far as I understand the proposal, the "N" field is only used if the "R"
> field is 0. So, no matter whether R is set to 0 or >0, almost one byte of
> the TCP option just consists of zero bits. If that was true, it might be
> inefficient to transfer a large number of zero bits in the TCP header. TCP
> option space is rather scarce and should not be wasted.
>
> Wouldn't be one byte less be sufficient?

Agreed, and while in -02 we started reducing the size of some fields,
there was probably more room as you show below.

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

> (And, if significantly large values were needed for "R" and "N", one could
> use another encoding instead of a raw binary number, such as encoding an
> exponent - then 6 bit would be a lot).

Agreed!

> Or do I just miss something basic and need more coffee?

No, it seems you had a suitable amount of coffee. :-)

> Thanks

Thanks to you!

Carles

> Michael