Re: [tcpm] TARR - the two options for R

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

Hi Michael,

>>> 2. Regarding the encoding of R: I prefer option 1.
>>>   This allows to use the value of 0 to be used to signal that
>>>   an ACK for this segment should be sent immediately, but no
>>>   persistent change of the ACK ratio should be performed.
>>
>> I see. In this case, R=0 would be a special case (i.e., an exception),
>> since by default the ACK rate would be the one requested with values of
>> R
>> different from zero.
> Yes, two semantics:
> If R=0, just send an ACK immediately, don't change the rate.
> If R>0, change the rate.
>
> For SCTP we have a feature to request an immediate ACK: RFC 7053,
> now incorporated into RFC 9260, which is the current specification of
> the base protocol.

Perfect, thanks!

>>> 3. If the range 1 - 127 is considered too small, one might consider
>>>   using two bytes for the option value. Currently, the length of
>>>   the option is odd, and therefore TCP implementations might add
>>>   some padding (NOP) anyway, since other options used after the
>>>   connection establishment like the timestamp or the sack option
>>>   have an even length.
>>
>> If some padding would typically be added by implementations to produce
>> an
>> even option length, then we can use your suggestion and define a
>> two-byte
>> field for R (perhaps keeping some reserved bit(s)).
>>
>> With this approach -let's call it OPTION 3-, we could use a simple
>> binary
>> encoding for R. Probably, one detail to figure out (and, probably,
>> discuss) then would be which would be the maximum value for R...
> Yepp.
>>
>> Any further thoughts?
>>
>>> 4. If SYN cookies are used and one is not willing to not spend another
>>>   bit for representing TARR support, you might want to specify that the
>>>   client sends the TARR option on the ACK of the three way handshake.
>>>   That way a server willing to support the TARR option can "learn"
>>>   from the client that it is OK to send the TARR option by observing
>>>   that the client sends it. It can also be learned later...
>>
>> If I recall correctly, Bob suggested this same idea. In IETF 113, Martin
>> asked if sending the TARR option in this way (on the ACK), and thus not
>> reliably, could be a concern.
>>
>> If there is lack of SYN space, perhaps one approach could be to learn it
>> later as you suggest, and/or to allow sending the TARR option on the ACK
>> but explaining the mentioned caveat...
> Clarification: This is not about the option space in the SYN segments.
> It is a about a server not allocating any state when receiving the initial
> SYN segment. The server puts all information it needs in the ISS.
> See https://cgit.freebsd.org/src/tree/sys/netinet/tcp_syncache.c#n2162
> how the encoding works. If you want to encode TARR supported/no supported
> you would need 1 more bit, which means using a 23 bit MAC.
>
> Assuming that the client is initially in slow start, you want a rate of
> one in slow start, the client might send a TARR option with R=1 with
> the ACK anyway. Just noting that a server might need to wait until
> it received a TARR option before sending one might be worth noting.

Thanks for the detailed explanation.

Sure, we will incorporate your comment in -05.

>> Once again, many thanks for your input and for the prototype
>> implementation work!
> Do you want to present the current state at the next meeting?

Yes!

We plan to request a presentation slot, at least for the current version
of the draft (-04), but most likely for -05, which we plan to submit
before the cutoff date.

Thanks,

Carles

> Best regards
> Michael