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

On Sat, Nov 14, 2020 at 8:45 AM Kevin Yang
<yyd=40google.com@dmarc.ietf.org> 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 <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