Re: [tcpm] Disabling PAWS when possible

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 17 July 2018 15:30 UTC

Return-Path: <rs.ietf@gmx.at>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04917130E9E for <tcpm@ietfa.amsl.com>; Tue, 17 Jul 2018 08:30:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RLoiPotvOefR for <tcpm@ietfa.amsl.com>; Tue, 17 Jul 2018 08:30:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC708130ED2 for <tcpm@ietf.org>; Tue, 17 Jul 2018 08:30:29 -0700 (PDT)
Received: from [10.249.64.239] ([217.70.210.5]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lb5Tp-1gLgRa27yL-00kidX; Tue, 17 Jul 2018 17:30:15 +0200
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, ncardwell@google.com, ietf@trammell.ch
References: <CAO249yccvy3c2ytrwOFBAg88X3V4ubbUVzr_Ag3PnrJQOFmckg@mail.gmail.com> <CADVnQynPKzxeFHf_DrGCbQrqcv6U4r=p_3RGXyPfooMzQNQ=cg@mail.gmail.com> <CAO249yfD6na651CSWkzjYRFaEAft9MNyUgjf+X4JNHYJbTCvJw@mail.gmail.com> <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> <CAO249yeQkEy7f6r1LKsajUrHs=Bedy5rO-s3V3WorYAJYLT9Vw@mail.gmail.com>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <b79cea56-fa91-8627-014b-a1c947320415@gmx.at>
Date: Tue, 17 Jul 2018 17:30:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <CAO249yeQkEy7f6r1LKsajUrHs=Bedy5rO-s3V3WorYAJYLT9Vw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:tkE/FHVOhgr11MVOexxshNGHcNpY/+eGSVsg2W4GgQzo/M6oEWl SqHL8UaHNcK8Q3AP682I3KHRw+8r3Bj0ag9d9Co1LVs18Klvt9UZg6Oz2EX+dmaKXj5c7wH e2SilvGs/5amv+LgNjPtX97mfjj6KYM+bzGqI2M6W0DIJQOwlm6Cf1AqDcGewzMVZXv9NSi /3WCffjQIoL0lQ8v1HpaQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:cDr1PaQQTUs=:RBr1htEz6MZ+h/snrt7z3r dVRsf2eHVCduo3J0ZFsUBZCOIhEXQgXb+CECoGI4RHCEmTBghiEcm9rdEWtH89w4WVOZ4NO5Q 8bCMVW2hia7wEWDu57bGEYCwjSjekWaB6iqJwi36th0SR+09lRR0ha0l7GeiH2ir1h1MERKzj EF5wCt0Z2+BLkIImO8fhl7jeHcW6uMYSEaEzDoU7vgHCgm5HDNkL+P3+/LnsXvsAeFY+x7r/q 94mlk2A9Bq4WoSH/mqO2RubDKmIRJ6f/3U/Fu2cO7ZLrQpQt4FhzlicjzYOf9+AQ7mCxO4Epo jIkGZgG0nMKufTAYjxmELsw5zImSgxcvgHXzwI99fZ5N2FepmKlAAfsilQ0mBf4NnjkdNskFI REJatXxiEoSzzKUzieerwqLEgiofaqvwwQSEW9ZerfsGQ1BhP+BFGlLGiPXAbH61c9XjY1van Xa1TCweVcmLaEv2gSvY2XjuFxLVyaNEcAhyjxmWjPQ5tni4NsRqbvIrWrsJHH4jMH8ujFlDp7 83/Iih/rYWZhKMzCAz6K0aETroYpNjIWZmCpd3GQQzOYWxmimLVyog/gdwK3py5ha833ZALSb Ay3ImtVAv281iu3zHSgAEYmmqt2qVewVKxIyeNC1qvaJ+91JEZtIinILTwWv/oVRG2Qa1iyoW Jx3I91IUXz1T65qai/o4/gUL76wP0ON6mLW5BgCZBDfNKB4bkiLFts39Ea0QIK2KvCKoScLi7 AGpts9iD3kSz4Aw1pc2s/crpLoSJlXeAahN5oVINIrMD+24itUKvmtarN46dooX1QlSqIZ6U/ WEhI5ba
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/NqyVMd0emvpyYqEp4sW-wImdDPg>
Subject: Re: [tcpm] Disabling PAWS when possible
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Jul 2018 15:30:35 -0000

Yoshi, Neil, Brian,


As pointed out by Brian - it really sounds like the time has come to 
revive the old TS nego draft, put in the semantic changes (Randall), 
disable PAWS (usec resolution) - perhaps not explicitly declare the used 
clock granularity though.

I'd be happy to work on that again.

Richard





Am 27.06.2018 um 06:05 schrieb Yoshifumi Nishida:
> Hi Richard,
> 
> On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard <rs.ietf@gmx.at 
> <mailto:rs.ietf@gmx.at>> wrote:
> 
>     Hi Yoshifumi, Neal,
> 
> 
>     Am 23.06.2018 um 01:23 schrieb Yoshifumi Nishida:
> 
>         My intention is to relax the requirement "The TSopt MUST be sent
>         in every non-<RST> segment for the duration of the connection"
>         in RFC7323
>         so that TSopt can be sent at arbitrary intervals. Arbitrary
>         intervals can contain infinite interval, but you can only do so
>         when you really want, otherwise you shouldn't.
>         So, disabling TS entirely is just an option.
> 
> 
>            >  From my perspective, one huge advantage from disabling
>         PAWS is that it
>            >  enables the timestamps to be an opaque identifier, so that
>         the sender
>            >  can use them in any way it chooses. In particular, it
>         would allow the
>            >  sender to use microsecond timestamps, without worrying
>         about the
>            >  remote side dropping packets due to PAWS checks. This was
>         the main
>            >  challenge we found in implementing microsecond TCP
>         timestamps inside
>            >  Google datacenters, as we discussed at TCPM a while back
>         (slide 6):
> 
>     [...]
> 
>     >   >  My main comment would be, if some proposal is going to
>     >   >  standardize a negotiation scheme for using timestamps but
>     >   >  disabling PAWS, IMHO there could be huge value in having that
>     >   >  negotiation mechanism optionally specify the semantics of a
>     >   >  sender's timestamp values, so that congestion control and
>     >   >  passive monitoring tools could make use of the timestamps
>     >   >  for bandwidth and latency measurements. This could be
>     >   >  something as simple as 2 bits, e.g.:
>     >   >
>     >   >  bits : meaning
>     >   >   00: traditional RFC 7323 timestamps: use PAWS
>     >   >   01: microsecond timestamps, disable PAWS
>     >   >   10: millisecond timestamps, disable PAWS
>     >   >   11: values with other semantics, disable PAWS
> 
> 
>     TSopt is today semi-opaque - a receiver can not rely on timestamps
>     to have a specific granularity or monotonicity today.
> 
>     It seems to me, that two paths should be discussed here: making
>     TSopt completely opaque - that is, disallowing the receiver to make
>     any use of it, only allowing it to be a signal from the sender in
>     the past (1RTT) to the sender in the future.
> 
>     Or making it more transparent, but disabling PAWS - meaning that the
>     content of TSopt can actually be interpreted by a receiver,
>     potentially allowing additional capabilities (one-way delay
>     variation measurement, "TCP Chirp", springs to mind).
> 
> 
>     Provided the clock granularity is fine enough, both points (unique
>     packet identifier, and allowing fine-grained timing data to be
>     extracted) could be done.
> 
>     Some of these functionalities were touched upon in this draft some
>     time ago:
>     https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05
>     <https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05>
> 
> 
> Yep, signaling mechanism to change the semantics of TS is an interesting 
> point for discussions.
> We can extend TS option like you proposed in the draft or integrating 
> into existing negotiation mechanisms or developing a new option.
> Developing a new option seems to be a straightforward approach, but it 
> will consume extra option space and may be discarded by middleboxes.
> 
> BTW, the draft above is cited in the draft as a good starting point of 
> discussion.
> --
> Yoshi
>