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

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 11 Mar 2021 14:30:15 +0000

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?

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

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

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

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

Thanks

Michael

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 12 Mar 2021 11:00:17 +0100

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

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

> 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

---

From: Jonathan Morton <[email-masked]>
Date: Fri, 12 Mar 2021 14:03:17 +0200

> On 12 Mar, 2021, at 12:00 pm, Carles Gomez Montenegro <[email-masked]> wrote:
> 
>> Example:
>> 
>>      0                   1                   2                   3

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.

 - Jonathan Morton

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Fri, 12 Mar 2021 13:27:00 +0100

Hi Jonathan,

Thank you for your quick response!

> 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

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 14 Mar 2021 22:14:13 +0000

Carles,

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

>> considered a Good Thing and weighed against the benefits of any

[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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

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