From nobody Sat Nov 14 11:36:12 2020 Return-Path: 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 3EE163A1297 for ; Sat, 14 Nov 2020 11:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.6 X-Spam-Level: X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 34IMuKCKCfUi for ; Sat, 14 Nov 2020 11:36:06 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 27C103A1296 for ; Sat, 14 Nov 2020 11:36:05 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id p8so14071402wrx.5 for ; Sat, 14 Nov 2020 11:36:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3JrDsbNXwec2/YXbLXxtiz+z8hE5EAkv8s/vTGq70hw=; b=VsNgbyZtZnUKmTVIXkIKl/i9efJRFRt32VG6Lx0jTv3EBPtnzxU57ly00Rit8Sqzsp gibpv/3/8aCg74Al3xNSqRcknA/xR/4OJ8ruGzz6kId/WBzKoRzUxgvRprgEBKnIQTD1 q+BYn60Qk4N8Bon3UV93ONIAEtgnZ66UcHxOLKsbqsUJtigq0tMi/TmMKvVTBhrOKrsw KIEM79hvAMTWiUlEWPGw63MZO8JveFjkJgl4izEw91hY0XZVyGKVDultQZACfFggjcoA vCRvFXuuLXYmQE/BJsGhLTH006PpxP9NFrbky9ykyaQqjjZk4PJycJX2UGfY9IgYo8Ij KPUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3JrDsbNXwec2/YXbLXxtiz+z8hE5EAkv8s/vTGq70hw=; b=nckLm6zrAMX4V4ScSlNrrEjGhP07HMZorQ3uZJNyDNeo/pCRdIgtCV0WzIB9r4DEXJ al4IttiU51JTycPfR/Wwr+nrZUN4kKo8ujVhFbq1kAOySC4OYiPyN1UgDz7G98zbWeBn L4IiL/JaFgKGeNCoaQvlFrqIHVDYiQ2WggdGOPLEjU+2Rq92nte1C6uTGv2DkHra2I2s d/NHz9OedkgQhQyRtiUdzSwzzS/UuziAD00AbvNmzi/GgHijsViVXvghqtwuwxG5Szan 8NksNAwJ4ZnsHXNRgLOLyDx0NuJTWiXOX4z4S22Z4zekoqFYPrAOeUIlm3MYbEeQEYMT mHsQ== X-Gm-Message-State: AOAM532tYTR3coYk6FLqVs7nPFzF2BosyFtSqT2s/47FuoKDMp2duJB+ rMr9QGPEvw2oVu3J/LVzxAF/MTGGQgeVOQ02UmStjQ== X-Google-Smtp-Source: ABdhPJwvQVIGSfayewhQNViQwjAArKvTYi7URGXs2R6xJNvJ6hJkzEEtHjQGV9K3mw98PkNc0ifSO8h4ZLuxDf71DAI= X-Received: by 2002:adf:ee12:: with SMTP id y18mr10483351wrn.231.1605382564159; Sat, 14 Nov 2020 11:36:04 -0800 (PST) MIME-Version: 1.0 References: <160435977209.20839.4083263519198538783@ietfa.amsl.com> In-Reply-To: From: Yuchung Cheng Date: Sat, 14 Nov 2020 11:35:27 -0800 Message-ID: To: Kevin Yang Cc: Yoshifumi Nishida , "tcpm@ietf.org Extensions" , Eric Dumazet , iccrg IRTF list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [tcpm] Fwd: New Version Notification for draft-yang-tcpm-ets-00.txt X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2020 19:36:09 -0000 On Sat, Nov 14, 2020 at 8:45 AM Kevin Yang 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 stan= dard track. > > 2: I think we should only update TS.recent when we assume the incoming se= gment is valid. > Otherwise, if the incoming is a real old one, we discard it but updat= e TS.recent; > then a new segment arrives, we may reject this new seg because TS.rec= ent > 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 wr= ote: >> >> Hi, >> Thanks for preparing the draft. I basically like the idea in the docs an= d have several comments. >> >> 1: I am wondering if we really need to have 32 bits TSval and TSecr in E= TS 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 ET= S receiver MUST skip the PAWS check" >> -> This is one possible approach, but just skipping PAWS doesn't sou= nd 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 an= d accepted. >> I think this is a bit more conservative. >> >> 3: It is not very clear for me how measuring NetworkRTT can contribute t= o improving RTO. >> Or, are there some other ways to utilize NetworkRTT? >> >> 4: Just out of curiosity, is intended status standard track or experimen= tal? ExID is usually used for exp or info docs. >> >> Thanks, >> -- >> Yoshi >> >> On Mon, Nov 2, 2020 at 4:26 PM Yuchung Cheng wrote: >>> >>> Hi tcpm & iccrg, >>> >>> We are proposing a new TCP timestamp option to measure the network dela= y more precisely (e.g. excluding delayed ACK effects) for congestion contro= l, 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: >>> Date: Mon, Nov 2, 2020 at 3:29 PM >>> Subject: New Version Notification for draft-yang-tcpm-ets-00.txt >>> To: Eric Dumazet , Yuchung Cheng , Neal Cardwell , Kevin Yang (Yudong) >>> >>> >>> >>> A new version of I-D, draft-yang-tcpm-ets-00.txt >>> has been successfully submitted by Kevin (Yudong) Yang and posted to th= e >>> 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-e= ts >>> 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 th= e >>> 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 kin= d >>> and length fields. >>> >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of submi= ssion >>> 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