From nobody Sat Nov 14 04:13:04 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 C41493A156F for ; Sat, 14 Nov 2020 04:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 tT_4FFrFq6Om for ; Sat, 14 Nov 2020 04:13:01 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 E77923A0E61 for ; Sat, 14 Nov 2020 04:13:00 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id 3so9302735qtx.3 for ; Sat, 14 Nov 2020 04:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s2x4/pSBqKS5eLF/cndhmqCnulHgb8TRoQLsJmZ3rWE=; b=oi+alOTCfHG7FCZq6j6CkMsRE7BG6X6PclpmuKc6B+eaQgn6vn7Y8P2vHVAUX8BpQG 6QTM82vS78K/StUctwHJ+Hv05qSeeO2u8tHX5tkFhpvu/MNj/tqxRoSFWe6XwN+Ti26N Jb6st8WLHjx15G5A+ipWA2GppAluhBc8Wbp/0btGkKk7uF5A4a9YK3fs9yhb6y7X0RIf jKn1wSz71hUcaXgf1joq4y/S267/cqqQry1AQ9WRKAkR+vkHnJTYFZDqAK88+U4mw25E JfgUAMLdOObl74SFx6iwH94MkFIBu3wcJmSxCxlz7p9MDtOOh9EgK5kIR5cX2LKRYEmX ql+g== 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; bh=s2x4/pSBqKS5eLF/cndhmqCnulHgb8TRoQLsJmZ3rWE=; b=HbItnaBmv4H45vkFT/RHwRfMmGf/1HPz6iQT/X8dyHHA8+xvDKdQC7WAsbpI57ILFZ BclFi5xNYGhwTwawbAnBj3fXSKcNjqgV/5tbZQvvVqHwd9A6D7eg5G9/3LpWBtux9oij IoOpyF0pXqEVFfxZYeRkSCbS2L5KzaLjBR6NB8DDQZwh8DYDSdLrRneKoWUyM+9mieEJ LT9oJY0YojAI6QpJ35JnBi8HzlMQCgWbh6cRvXsJ3sICZS/XE41c7Y4F6fvSw2TouEU8 /hIeRFpIRLa/qKgVfV+6KRKZHwEKaJDSLjlen+hYdA8RQPLgcCsBVPhsukcvWrJmCoPH vmZQ== X-Gm-Message-State: AOAM532DCatpB77qzUZIgRyHKwGl30AU3UZYAGzoRS7m2z4MEUHneIte bwZIjVcxjYDX2rACzLXZ4JDWlyRjkCEtnbExo+g= X-Google-Smtp-Source: ABdhPJwIUk+xH2XLdsGOSpTqpzCiqMyIIgGIRT754UFhYOnUmhQCXJiZatectdzX9ji/mLtK0YU9kjDljaFIUSbeRyo= X-Received: by 2002:ac8:5c15:: with SMTP id i21mr6121759qti.190.1605355979927; Sat, 14 Nov 2020 04:12:59 -0800 (PST) MIME-Version: 1.0 References: <160435977209.20839.4083263519198538783@ietfa.amsl.com> In-Reply-To: From: Yoshifumi Nishida Date: Sat, 14 Nov 2020 04:12:48 -0800 Message-ID: To: Yuchung Cheng Cc: "tcpm@ietf.org Extensions" , Eric Dumazet , iccrg IRTF list , Kevin Yang Content-Type: multipart/alternative; boundary="000000000000ebf4e805b41010a6" 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 12:13:03 -0000 --000000000000ebf4e805b41010a6 Content-Type: text/plain; charset="UTF-8" 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 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: > 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 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 > --000000000000ebf4e805b41010a6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
Thanks for preparing the draft. I basic= ally 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?=C2=A0
=C2=A0 =C2= =A0 For example, If TSopt has 1 ms granularity, I think ETS option will nee= d to carry only small=C2=A0fractions of timestamp.=C2=A0

2: "To prevent a false positive PAWS rejection of a valid segme= nt, an ETS receiver MUST skip the PAWS check"
=C2=A0 =C2=A0 = -> This is one possible approach, but just skipping PAWS doesn't sou= nd very good to me.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0How about d= iscarding the segment while updating TS.recent as an alternative? If the se= gment is not an old one, it will be retransmitted and accepted.
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0I think this is a bit more conservative.<= /div>

3: It is not very clear for me how measuring Netwo= rkRTT can contribute to improving RTO.=C2=A0
=C2=A0 =C2=A0 Or, ar= e there some other ways to utilize NetworkRTT?=C2=A0

4: Just out of curiosity, is intended=C2=A0status standard track or expe= rimental? ExID is usually used for exp or info docs.

Thanks,
--
Yoshi

On Mon, Nov 2, 2020 at 4:26 PM Yuchu= ng Cheng <ycheng=3D40goog= le.com@dmarc.ietf.org> wrote:
Hi tcpm & iccrg,
<= br>
We are proposing a new TCP timestamp option to measure the ne= twork delay more precisely (e.g. excluding delayed ACK effects) for congest= ion control, e.g. Swift published SIGCOMM 2020. The precision of the measur= ements can potentially be further enhanced by NIC hardware timestamps. We a= re working on a reference implementation for Linux as well.

<= /div>
We'll also present it in the upcoming tcpm meeting. Feedbacks= are very welcome.=C2=A0

---------- 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.tx= t
To: Eric Dumazet <edumazet@google.com>, Yuchung Cheng <ycheng@google.com>, Neal Cardwell= <ncardwell@go= ogle.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:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-yang-tcpm-ets
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP ETS: Extensible Timestamp Opti= ons
Document date:=C2=A0 2020-11-02
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-yang-tcpm-ets-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:= //datatracker.ietf.org/doc/draft-yang-tcpm-ets/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/html/draft-yang-tcpm-ets
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.= ietf.org/html/draft-yang-tcpm-ets-00


Abstract:
=C2=A0 =C2=A0This document presents ETS: an Extensible TimeStamps option fo= r TCP.
=C2=A0 =C2=A0It allows hosts to use microseconds as the unit for timestamps= to
=C2=A0 =C2=A0improve the precision of timestamps, and advertise the maximum= ACK
=C2=A0 =C2=A0delay for its own delayed ACK mechanism.=C2=A0 Furthermore, it= extends the
=C2=A0 =C2=A0information provided in the [RFC7323] TCP Timestamps Option by=
=C2=A0 =C2=A0including the receiver delay in the TSecr echoing, so that the=
=C2=A0 =C2=A0receiver of the ACK is able to more accurately estimate the po= rtion
=C2=A0 =C2=A0of the RTT that resulted from time traveling through the netwo= rk.
=C2=A0 =C2=A0The ETS option format is extensible, so that future extensions= can
=C2=A0 =C2=A0add further information without the overhead of extra TCP opti= on kind
=C2=A0 =C2=A0and length fields.




Please note that it may take a couple of minutes from the time of submissio= n
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
--000000000000ebf4e805b41010a6--