Re: [tcpm] Fwd: New Version Notification for draft-yang-tcpm-ets-00.txt

["Scheffenegger, Richard" <[e-mail]>]

Am 23.11.2020 um 02:47 schrieb Kevin Yang:
>> The high level approach there was to use the unused TSecr field (should
>> be 0 for 7323/1323), and overlay (xor) in the SYN/ACK's TSopt ecr field
>> the client's TSopt val with the servers 32-bit negotiation field... As
>> the client can retain knowledge of the initial TSopt value (there should
>> be a randomized initial value), the client can extract the server side
>> options by xor'ing it's known initial value when the SYN/ACK is
>> received. Or fall back to default 7323 operation, if the result of the
>> XOR is zero...
>>
>
> I agree that the TSecr in <SYN> might be used for other purposes. But I'm
> not sure if we can alter the TSecr in <SYN,ACK> by XOR other info.
> One specific example I came up with is that a sender may send out many
> SYNs because of timeout,
> then when it receives a <SYN,ACK>, it does not know which TSval should
> be used for xor op.

(E)TS opt is not necessarily the old differentiation between subsequent
SYN packets; extending some reserved bits (during the SYN handshake) may
be another easy way to have sufficient differentiation available.

E.g. The EcrDel value may be restricted to no less than 4 or 8 usec (any
lower value rounded up), yielding sufficient bits which would expected
to be zero in the SYN,ACK; The TSval offset can then be selected by the
sender in such a way, to change at these locations for each
retransmission of the SYN, allowing the sender to disambiguate which SYN
a particular SYN,ACK pairs up with...



>> It could be used almost as a drop-in use of timestamp-negotiation, as
>> long as it can be guaranteed, that at least one bit is set in the 32bit
>> field (e.g. setting the reserved bit to 1).
>
> In this way we need to add another "ETSval'' in usec if we use the
> RFC7323/1323 TSopt,
> the reason is explained above.

As long as some more coarse time resolution is acceptable during the
(special case handling) 3WHS, all you need is a few bits to disambiguate
retransmitted SYN packets. We did spent some thought on the
retransmitted SYN problem during the TS-nego design phase. A single
reserved bit is not sufficient, though;

>
>> EcrDelUnit: I think the codepoint assignment could be improved (but this
>> is really nit-picking; just that a broken implementation may send out
>> TSopt with len=12, but initialized-to-zero superflous bytes...
>> 0: invalid
>> 1: milliseconds [2^20 nanoseconds?]
>> 2: microseconds [2^10 nanoseconds?]
>> 3: reserved (nanoseconds)
>
> Thanks for the nice suggestion. I agree we probably should have
> all-zero codepoint to be
> "no information". For 2^k nanosec unit, I guess that is for bit-op
> convenience and performance?

Yes, simple binary shift operations instead of multiply/divide, and
internally representing timestamp values in nanoseconds
(timespec/tv_nsec). The error when using timeval/tv_usec may even be
small enough to not matter in many environments (eg. simply use a
"microsecond 2^10" value directly, without adjusting for the 2.4% error,
as you are interested in deltas on short timescales, not across long
timespans?