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

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.

Kevin

On Sat, Nov 14, 2020 at 7:13 AM Yoshifumi Nishida <nsd.ietf@gmail.com>
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=
> 40google.com@dmarc.ietf.org> 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: <internet-drafts@ietf.org>
>> Date: Mon, Nov 2, 2020 at 3:29 PM
>> Subject: New Version Notification for draft-yang-tcpm-ets-00.txt
>> To: Eric Dumazet <edumazet@google.com>, Yuchung Cheng <ycheng@google.com>,
>> Neal Cardwell <ncardwell@google.com>, Kevin Yang (Yudong) <yyd@google.com
>> >
>>
>>
>>
>> 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
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
>>
>