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

[[e-mail]]

> On 6. Jul 2022, at 19:16, Carles Gomez Montenegro <[e-mail]> wrote:
> 
> Hi Michael,
> 
> Many thanks for your response!
> 
> Please find below my inline comments:
> 
> <snip>
> 
>>> Are there other opinions?
> 
>> Hi Carles,
>> 
>> I would like to give some feedback as an individual.
>> 
>> This feedback is based on using your draft in one of my courses
>> at university resulting in a prototype implementation for FreeBSD
>> and packetdrill.
> 
> This is great news!
> Your implementation-based feedback is highly appreciated.
> 
>> Here are some points:
>> 
>> 1. You might want to say which kind (253 or 254) is used on the
>>   sender side and on the receiver side. The prototype accepts
>>   both on the receiver side and uses only one on the sender side.
>>   Which one is used on the sender side is compiled into the code.
> 
> Yes, there is a TBD currently in the draft (-04). For -05, our current
> proposal is to use 254.
Great, thanks for the information.
> 
>> 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.
> 
>> 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.
> 
> 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?

Best regards
Michael
> 
> Cheers,
> 
> Carles
> 
> 
>> Best regards
>> Michael
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm