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

[Kevin Yang <[e-mail]>]

Thank you Richard,

To make less confusion, the new proposed ETSopt is targeting a different
option kind, i.e. not reusing RFC7323 TSopt, so please allow me to use
ETSval and ETSecr to refer to the timestamps in ETS option.

For saving more space in <SYN> and <SYN,ACK> by reusing the ETSecr, I generally
like this idea about XOR ETSecr with other fields. But considered the
complexity it adds to the protocol and implementation, I'm on the fence and
waiting for more inputs from others.

To help others understand the problem, I summarize it in the following:

The idea is to XOR ETSecr with EcrDel and MaxACKDel fields in <SYN> and
<SYN,ACK> to save the 32 bits space used by EcrDel.

The ETSecr is all-zero in <SYN>, so we can XOR them to save 32 bits without
problem. But to XOR ETSecr with the other fields in <SYN,ACK>, we need to
prevent <SYN,ACK> mis-paired with retransmitted <SYN>s.

One way to solve the problem is to:
1. In <SYN,ACK>, make S (e.g. S=3) bits of either in EcrDel or MaxACKDel to
be 0, sacrifice a little accuracy, e.g. roundup to neaest multiple of 8.

2. Need to rearrange the position of EcrDel or MaxACKDel so that those S bits
coincide with the least significant of ETSecr. So the S bits of ETSecr
remain the same in <SYN,ACK>.

3. In <SYN> and retransmitted <SYN>, the sender makes each retransmitted <SYN>
have ETSval's last S bits that are different from before.

4. When the sender receives the <SYN,ACK>, it knows which <SYN> to pair using
the last S bit of ETSecr.


About the 2^10 nanosecond unit, I'm thinking that might not make it easier for
computation EcrDel = LatestACKDel + TSecrAge (page 7), since both component
are not directly compute from nanosecond: TSecrAge is the difference of two TS
clock (in microsecond), LatestACKDel can be computed from tp->tcp_mstamp in
Linux which is also in microsecond. So if EcrDel can be represented in
microsecond, there should be no div operation needed. Also, it is more natural
to keep EcrDel with the same microsecond(10^3 nanosecond) format as ETSval
and ETSecr.

Best,
Kevin


On Tue, Nov 24, 2020 at 8:22 AM Scheffenegger, Richard <[e-mail]> wrote:
>
>
>
> 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?