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

[Kevin Yang <[e-mail]>]

Thank you Bob and Richard, for the nice feedback!

To Bob's feedback:
>You could define your new option solely with the last two negotiation fields
>Because the existing timestamp fields are already defined as opaque...
That's a good point. We actually did consider this in our early
iterations among the authors.
Some drawbacks from relying on TSopt:

1. It has 2 more bytes for kind and len. As you pointed out, it might
be a way to save
on established segments, but not on SYNs.

2. In addition to TSval (in old TSopt), the new ETSopt needs to
include another timestamp
to be the "ETSval" in usec. We can not fill a usec value in TSval(of
old TSopt). Otherwise,
because the passive side may not support this new protocol, it treats
TSval in msec and may trigger
false positive drops by PAWS on the passive side.

I reply Richard's feedback inline below:

On Tue, Nov 17, 2020 at 8:19 AM Scheffenegger, Richard <[e-mail]> wrote:
>
> Just to capture what Bob and I tried to convey:
>
> There may be a way to extend TSOpt in a backwards-compatible way,
> without increasing the size of the option during the SYN handshake, nor
> with the need to have both 7323 TSopt and ETSopt present simultaneously
> in the SYN and SYN/ACK.
>
> Please have a look at
> https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05
>
> Which was the signaling / handshake part to
>
> https://tools.ietf.org/html/draft-trammell-tcpm-timestamp-interval-01
>
> As the latter part didn't get much traction (to signal the TS
> granularity and even accuracy), these two didn't move forward.
>
>
> As the SYN TSopt ecr value is currently unused, and the client knows the
> initial value for TSval (which should be reflected in the SYN/ACK from
> the server), you can use 32 bits there for a feature declaration and
> negotiation.
>
> 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.

>
> The major issue would be that TSopt with a length != 10 may be
> removed/blocked by certain middleboxes, but a new TCP option has similar
> deployment issues.
>
> As Bob mentioned in another thread just now, TCP SYN option space is a
> very scarce resource, and making efficient use of it should matter...
>
>
> Other comments: Graph1 (page 4) has "TSval=X" rather than "ETSval=X".
> Unless you plan to reuse the TSopt in an extensible way (with the same
> codepoint, but differentiated by the length of the option), that may
> need to be addressed to disambiguate things; You may also want to have
> both ETSopt and TSopt in the SYN present, for backwards compatibility if
> a separate codepoint is used.

Good point, we should revise it to ETSval for disambiguation.

> If you want to make use of the timestamp-negotiation design, all of the
> extra data shown on page 6 can be stuffed into the TSecr or ETSecr
> field, alleviating the need of 4 additional SYN option bytes.
>
> 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.

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

>
> MaxAckDel: 16 bits/microseconds gives a maximum of 65.5 ms; some (older)
> stacks are using values as high as 200ms; If such a stack is updated, it
> is a good reason to reduce the DelAck value used in that stack, so this
> range appears properly selected (FreeBSD recently reduced from 100ms to
> 40ms).
>
>
>
> Best regards,
>     Richard
>
>
> Am 14.11.2020 um 20:35 schrieb Yuchung Cheng:
> > On Sat, Nov 14, 2020 at 8:45 AM Kevin Yang
> > <yyd=[e-mail]> wrote:
> >>
> >> Thank you Yoshi, very good questions.
> >>
> >> 1: Our goal is to substitute the TSopt. So we design this new ETSopt not to depend on TSopt.
> >>      I guess this also answers your question 4, the intent is for the standard track.
> >>
> >> 2: I think we should only update TS.recent when we assume the incoming segment is valid.
> >>      Otherwise, if the incoming is a real old one, we discard it but update TS.recent;
> >>      then a new segment arrives, we may reject this new seg because TS.recent > seg.TSval.
> >>
> >> 3: Your understanding is correct, and in the draft we are not suggesting to use NetworkRTT
> >>      measurements for RTO calculation.
> >>
> >> 4: answered by 1.
> > We'll clarify better in the upcoming draft revision: the draft
> > intends to transition from exp-id to  an official option kind number
> > from IANA upon becoming
> > an RFC. But we're following the advice of
> > https://tools.ietf.org/html/rfc6994 to allow larger scale experiments
> > for hosts not completely under control of a single entity/network. For
> > example guest VM TCP communications inside Cloud Data-center networks.
> >
> >
> >>
> >> Kevin
> >>
> >> On Sat, Nov 14, 2020 at 7:13 AM Yoshifumi Nishida <[e-mail]> wrote:
> >>>
> >>> Hi,
> >>> Thanks for preparing the draft. I basically like the idea in the docs and have several comments.
> >>>
> >>> 1: I am wondering if we really need to have 32 bits TSval and TSecr in ETS option in SYN when TSopt is also sent?
> >>>      For example, If TSopt has 1 ms granularity, I think ETS option will need to carry only small fractions of timestamp.
> >>>
> >>> 2: "To prevent a false positive PAWS rejection of a valid segment, an ETS receiver MUST skip the PAWS check"
> >>>      -> This is one possible approach, but just skipping PAWS doesn't sound very good to me.
> >>>           How about discarding the segment while updating TS.recent as an alternative? If the segment is not an old one, it will be retransmitted and accepted.
> >>>           I think this is a bit more conservative.
> >>>
> >>> 3: It is not very clear for me how measuring NetworkRTT can contribute to improving RTO.
> >>>      Or, are there some other ways to utilize NetworkRTT?
> >>>
> >>> 4: Just out of curiosity, is intended status standard track or experimental? ExID is usually used for exp or info docs.
> >>>
> >>> Thanks,
> >>> --
> >>> Yoshi
> >>>
> >>> On Mon, Nov 2, 2020 at 4:26 PM Yuchung Cheng <ycheng=[e-mail]> wrote:
> >>>>
> >>>> Hi tcpm & iccrg,
> >>>>
> >>>> We are proposing a new TCP timestamp option to measure the network delay more precisely (e.g. excluding delayed ACK effects) for congestion control, e.g. Swift published SIGCOMM 2020. The precision of the measurements can potentially be further enhanced by NIC hardware timestamps. We are working on a reference implementation for Linux as well.
> >>>>
> >>>> We'll also present it in the upcoming tcpm meeting. Feedbacks are very welcome.
> >>>>
> >>>> ---------- Forwarded message ---------
> >>>> From: <[e-mail]>
> >>>> Date: Mon, Nov 2, 2020 at 3:29 PM
> >>>> Subject: New Version Notification for draft-yang-tcpm-ets-00.txt
> >>>> To: Eric Dumazet <[e-mail]>, Yuchung Cheng <[e-mail]>, Neal Cardwell <[e-mail]>, Kevin Yang (Yudong) <[e-mail]>
> >>>>
> >>>>
> >>>>
> >>>> A new version of I-D, draft-yang-tcpm-ets-00.txt
> >>>> has been successfully submitted by Kevin (Yudong) Yang and posted to the
> >>>> IETF repository.
> >>>>
> >>>> Name:           draft-yang-tcpm-ets
> >>>> Revision:       00
> >>>> Title:          TCP ETS: Extensible Timestamp Options
> >>>> Document date:  2020-11-02
> >>>> Group:          Individual Submission
> >>>> Pages:          13
> >>>> URL:            https://www.ietf.org/archive/id/draft-yang-tcpm-ets-00.txt
> >>>> Status:         https://datatracker.ietf.org/doc/draft-yang-tcpm-ets/
> >>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-yang-tcpm-ets
> >>>> Htmlized:       https://tools.ietf.org/html/draft-yang-tcpm-ets-00
> >>>>
> >>>>
> >>>> Abstract:
> >>>>     This document presents ETS: an Extensible TimeStamps option for TCP.
> >>>>     It allows hosts to use microseconds as the unit for timestamps to
> >>>>     improve the precision of timestamps, and advertise the maximum ACK
> >>>>     delay for its own delayed ACK mechanism.  Furthermore, it extends the
> >>>>     information provided in the [RFC7323] TCP Timestamps Option by
> >>>>     including the receiver delay in the TSecr echoing, so that the
> >>>>     receiver of the ACK is able to more accurately estimate the portion
> >>>>     of the RTT that resulted from time traveling through the network.
> >>>>     The ETS option format is extensible, so that future extensions can
> >>>>     add further information without the overhead of extra TCP option kind
> >>>>     and length fields.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Please note that it may take a couple of minutes from the time of submission
> >>>> until the htmlized version and diff are available at tools.ietf.org.
> >>>>
> >>>> The IETF Secretariat
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> tcpm mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/tcpm
> >
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> >