From nobody Sun Jun 10 23:00:01 2018 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 A3A0B130EE6 for ; Sun, 10 Jun 2018 22:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 TYWQur0wiRw9 for ; Sun, 10 Jun 2018 22:59:55 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0122.outbound.protection.outlook.com [104.47.2.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B56F130E0C for ; Sun, 10 Jun 2018 22:59:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=A0vyJBQbNjnHr43kr6PknDS1A9fGSOAXOs9r+PZaav8=; b=Z+OU/WPDr3lgQnN6h7eSKt7lv7KrCzPFMkCbiC7EQehXLcmzv160m7TKXn7U7MEo7GZuJpvEsU5btqA37rXiEf6PmM+ilUjuZ6vC0wyNTMBU4OWCDXsojAMj3IwazprCwiISUppSNwo60oy69u3vjbgZaZe9iTciXlNNdvx0DcY= Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB1858.eurprd07.prod.outlook.com (10.167.216.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.863.6; Mon, 11 Jun 2018 05:59:52 +0000 Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::48b9:5449:401e:6d55]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([fe80::48b9:5449:401e:6d55%9]) with mapi id 15.20.0863.010; Mon, 11 Jun 2018 05:59:52 +0000 From: "Scharf, Michael (Nokia - DE/Stuttgart)" To: "tcpm@ietf.org" CC: Carles Gomez Montenegro , "jon.crowcroft@cl.cam.ac.uk" Thread-Topic: [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-03.txt] Thread-Index: AQHUAJwbKopQIpl5+kmhGvch9WQLMKRakK6w Date: Mon, 11 Jun 2018 05:59:52 +0000 Message-ID: References: <24a42252af5bb9ae009b54d2d66d3032.squirrel@webmail.entel.upc.edu> In-Reply-To: <24a42252af5bb9ae009b54d2d66d3032.squirrel@webmail.entel.upc.edu> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=michael.scharf@nokia.com; x-originating-ip: [92.203.189.113] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB1858; 7:kv0XHZKsS/ztmoUh+FGSEgEtPK6G2TJU8GmMJg4ggCmEjtMghC0IJT9UOs8bVoSIqMz7eP+0AL7h9AHkUfayRS4iQKsDVlt0j37rXiSr2QinLJhIOyMzQrT/P/K4wN2bBgXbHmLs5xUdeWq84Sv7dkpJNkDjSDb/TmkH6ol6vz7qViN1R+QqwxFwAIkGj/p3C7RJTDRD0Mnv6yKcRqetXlUJKvpOKMw8TOIPyVbm5z2/3HDR3mLbguYnJTaJAK+R x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM5PR0701MB1858; x-ms-traffictypediagnostic: AM5PR0701MB1858: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(82608151540597)(109105607167333); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM5PR0701MB1858; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB1858; x-forefront-prvs: 070092A9D3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(376002)(346002)(396003)(39860400002)(13464003)(199004)(189003)(25786009)(97736004)(2900100001)(478600001)(2351001)(14454004)(316002)(102836004)(6506007)(53546011)(86362001)(7696005)(76176011)(186003)(26005)(966005)(81156014)(476003)(486006)(11346002)(74316002)(446003)(105586002)(106356001)(7736002)(81166006)(33656002)(5250100002)(1730700003)(2501003)(305945005)(561944003)(6116002)(3846002)(5640700003)(3660700001)(9686003)(54906003)(6306002)(8676002)(6436002)(6916009)(99286004)(2473003)(4326008)(55016002)(53936002)(8936002)(68736007)(5660300001)(3280700002)(229853002)(66066001)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB1858; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: LnGDVAhZGmMy9IQZjZ2HO1qpnFyYo0oqhExhH2bM4pMeB1cuRjvi9WPLtceh/f58ul6wNwRVuFViSpcDyIfjSKg1XHt0iPLpp2pIsyCE2abDM7IkAk1H4nyA4ZDKdto1Cst1j10mkJV0+qYHCduTDihYSn7i3KoOWjBDGyM+XeU2cIkda2hLIf8WS+zZYWZ9B8g6DLUdW5vttb3aqY0YGVNHLL79MSA4UkmNZDqm77q9xpkGPk2lKpvlUK+AyjbB spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Office365-Filtering-Correlation-Id: 01862411-c0d9-4610-d85b-08d5cf608cbc X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 01862411-c0d9-4610-d85b-08d5cf608cbc X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2018 05:59:52.7259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB1858 Archived-At: Subject: [tcpm] FW: [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-03.txt] X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 11 Jun 2018 05:59:59 -0000 To keep the TCPM community in the loop. The authors really look for feedback (preferably on the LWIG list). Michael -----Original Message----- From: Carles Gomez Montenegro [mailto:carlesgo@entel.upc.edu]=20 Sent: Sunday, June 10, 2018 11:19 AM To: lwip@ietf.org Cc: Scharf, Michael (Nokia - DE/Stuttgart) ; jon.= crowcroft@cl.cam.ac.uk Subject: [Fwd: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-netw= orks-03.txt] Dear LWIG WG, As you can see below, we have updated the LWIG TCP draft. Comments are welc= ome! On the other hand, while we believe the document is starting to be quite co= mplete, we would like to take the opportunity to ask you a few questions: 1.- With regard to the constrained TCP implementations survey in the Annex,= please let us know if you would object against presence in the Annex of an= y of the currently covered implementations, or if you think others may need= to be included. 2.- So far, we have not been able to find or receive much content for the "= Data size" row in the summary table. A nice exception to this is RAM usage = measurement results on the RIOT TCP implementation, that have been kindly p= rovided by Simon Brummer. However, as getting similar information for the r= est of implementations appears to be difficult, our proposal would be remov= ing this row from the table (as shown in the current draft version), while = keeping the "Code size" row in. RAM usage details for the RIOT TCP implemen= tation have been included anyway as a table footnote. Would anyone object to this approach? 3.- If you are aware of specific code vulnerabilities that may arise when i= mplementing TCP for constrained devices, please let us know. Thanks, Carles, Jon, Michael ---------------------------- Original Message ---------------------------- Subject: [Lwip] I-D Action: draft-ietf-lwig-tcp-constrained-node-networks-03.txt From: internet-drafts@ietf.org Date: Sun, June 10, 2018 10:36 am To: i-d-announce@ietf.org Cc: lwip@ietf.org -------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Light-Weight Implementation Guidance WG of= the IETF. Title : TCP Usage Guidance in the Internet of Things (IoT= ) Authors : Carles Gomez Jon Crowcroft Michael Scharf Filename : draft-ietf-lwig-tcp-constrained-node-networks-03.txt Pages : 24 Date : 2018-06-10 Abstract: This document provides guidance on how to implement and use the Transmission Control Protocol (TCP) in Constrained-Node Networks (CNNs), which are a characterstic of the Internet of Things (IoT). Such environments require a lightweight TCP implementation and may not make use of optional functionality. This document explains a number of known and deployed techniques to simplify a TCP stack as well as corresponding tradeoffs. The objective is to help embedded developers with decisions on which TCP features to use. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lwig-tcp-constrained-node-netwo= rks/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lwig-tcp-constrained-node-networks-0= 3 https://datatracker.ietf.org/doc/html/draft-ietf-lwig-tcp-constrained-node-= networks-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lwig-tcp-constrained-node-ne= tworks-03 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Lwip mailing list Lwip@ietf.org https://www.ietf.org/mailman/listinfo/lwip From nobody Thu Jun 14 06:15:08 2018 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 61149130E1C; Thu, 14 Jun 2018 06:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 HuCY0HslXSzh; Thu, 14 Jun 2018 06:15:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D10C130DEF; Thu, 14 Jun 2018 06:15:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 18CC0B81BBD; Thu, 14 Jun 2018 06:14:58 -0700 (PDT) To: vladnc@gmail.com, ycheng@google.com, hkchu@google.com, sivasankar@cs.ucsd.edu, arvind@google.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: ietf@kuehlewind.net, iesg@ietf.org, tcpm@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180614131458.18CC0B81BBD@rfc-editor.org> Date: Thu, 14 Jun 2018 06:14:58 -0700 (PDT) Archived-At: Subject: [tcpm] [Errata Verified] RFC7413 (5373) X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Thu, 14 Jun 2018 13:15:03 -0000 The following errata report has been verified for RFC7413, "TCP Fast Open". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5373 -------------------------------------- Status: Verified Type: Technical Reported by: Vladimir Nicolici Date Reported: 2018-05-31 Verified by: Mirja Kühlewind (IESG) Section: 4.1.3.1. Original Text ------------- For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and ports) at least temporarily. Corrected Text -------------- For any negative responses, the client SHOULD disable Fast Open on the specific path (the source and destination IP addresses and the destination port) at least temporarily. Notes ----- The original language seems to imply that the cached negative response should only affect connections if they are initiated from the same source port and source IP. Since the client source port can change for subsequent TCP connections, and it's unlikely that just changing the source port would result in a successful TCP FO connection when a previous connection from a different source port failed, associating the cached negative response with the source port is probably not very useful, and could actually be detrimental to performance and reliability, depending on the implementation. If the implementation would decide to check the source port when matching negative cached responses to a new connection, it would negatively impact performance when the source port changes, because the implementation wouldn't find a matching negative response in the cache. Furthermore, if each connection retry is made from a different source port, checking the source port when matching the cached negative responses would make the client unable to connect to the server, until all possible source ports are included in cached negative responses. This means it's much better not recommending to associate the source port to the cached negative responses, to prevent any confusion and possible implementation issues. Either that, or add additional clarification, describing exactly how a negative cached response should be matched to a subsequent connection attempt. -------------------------------------- RFC7413 (draft-ietf-tcpm-fastopen-10) -------------------------------------- Title : TCP Fast Open Publication Date : December 2014 Author(s) : Y. Cheng, J. Chu, S. Radhakrishnan, A. Jain Category : EXPERIMENTAL Source : TCP Maintenance and Minor Extensions Area : Transport Stream : IETF Verifying Party : IESG From nobody Mon Jun 18 11:22:19 2018 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 433FD130EE5; Mon, 18 Jun 2018 11:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 85q99M7juHfU; Mon, 18 Jun 2018 11:22:06 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD3B130EFB; Mon, 18 Jun 2018 11:21:57 -0700 (PDT) Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 258762783BE; Tue, 19 Jun 2018 03:21:55 +0900 (JST) Received: by mail-io0-f177.google.com with SMTP id l19-v6so17715305ioj.5; Mon, 18 Jun 2018 11:21:55 -0700 (PDT) X-Gm-Message-State: APt69E11TMFg1w44WOiO+W/C6bO5Y7j0YIUv2QLVp0c+gFJGxlWSVx+w 9gj//f+oVmWMdgutzdfmP7j/jVbuz3oH175hKhI= X-Google-Smtp-Source: ADUXVKL/+5IGDciqtb+Evj6abR9BYhgmNM7p7VavzP20bLVA+CkgVkAJPzqCsDllhfjh5uSqmrBSCt2lUaTcFJc3EuU= X-Received: by 2002:a6b:dd14:: with SMTP id f20-v6mr10793932ioc.7.1529346114018; Mon, 18 Jun 2018 11:21:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Mon, 18 Jun 2018 11:21:53 -0700 (PDT) From: Yoshifumi Nishida Date: Mon, 18 Jun 2018 11:21:53 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Cc: "tcpm-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dd6302056eeea36d" Archived-At: Subject: [tcpm] IETF 102 agenda request X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 18 Jun 2018 18:22:16 -0000 --000000000000dd6302056eeea36d Content-Type: text/plain; charset="UTF-8" Hello, According to the current agenda ( https://datatracker.ietf.org/meeting/102/agenda.html), our WG meeting is scheduled on Tuesday (7/17) 9:30-12:00. (please note this is still preliminary and might be changed later) If you are planning to present something, please let the chairs know the following information. * Title / draft name * Presenter's name * Total time (including Q/A) Thanks, -- tcpm co-chairs --000000000000dd6302056eeea36d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hello,

According to the = current agenda (https://datatracker.ietf.org/meeting/102/agenda.html), our WG mee= ting is scheduled on Tuesday (7/17) 9:30-12:00. (please note this is still = preliminary and might be changed later)
If you are planning to pr= esent something, please let the chairs know the following information.
=
* Title / draft name
* Presenter's= name
* Total = time (including Q/A)

Thanks,
--
tcpm co-chairs
--000000000000dd6302056eeea36d-- From nobody Wed Jun 20 23:50:08 2018 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 469AB130EB9 for ; Wed, 20 Jun 2018 23:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 PdOrcL-TvBA6 for ; Wed, 20 Jun 2018 23:50:03 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D3511292F1 for ; Wed, 20 Jun 2018 23:50:02 -0700 (PDT) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B2D0F2784E9 for ; Thu, 21 Jun 2018 15:50:00 +0900 (JST) Received: by mail-it0-f54.google.com with SMTP id a3-v6so3284876itd.0 for ; Wed, 20 Jun 2018 23:50:00 -0700 (PDT) X-Gm-Message-State: APt69E2tNtNIun7zhJNnq2khzTJ0J1bvbw8YqziwvdKR+2b6YYWNXDRn 5x1LkeyycaaCqkhC5lWAXXLLlmHvGRok1qOJq+s= X-Google-Smtp-Source: ADUXVKK5BPckA5Ek1eRzqlLF7RxRfHMGF1vjpibdKPyRCfGuug74p/6ptTg15LFXD4FtRf4+XAJcd7ImZz0zroAny2s= X-Received: by 2002:a02:a999:: with SMTP id q25-v6mr19640377jam.47.1529563799487; Wed, 20 Jun 2018 23:49:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 23:49:58 -0700 (PDT) From: Yoshifumi Nishida Date: Wed, 20 Jun 2018 23:49:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ee0f58056f215236" Archived-At: Subject: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Thu, 21 Jun 2018 06:50:06 -0000 --000000000000ee0f58056f215236 Content-Type: text/plain; charset="UTF-8" Hello, I have been thinking about PAWS and TS option for a while and prepared a simple short draft. The basic ideas in the draft are like this. 1: There are several technologies (such as tcpinc, mptcp, tls) that can be used as a replacement of PAWS They can even provide stronger protections than PAWS, which might be able to contribute to recycling connections in TIME_WAIT. 2: Some implementations have records of transmission times on each segment which won't require TS option for RTTM. 3: When 1 is available, we don't have to put a TS option in every segment. Also, when 1 and 2 are available, we don't have to use TS option at all. Since we already have base technologies to replace PAWS and TS, all we need here is a simple signaling mechanism for feature negotiation. The draft is still very premature and I may overlook something, but it would be great if I could get some feedback. Thanks, -- Yoshi ---------- Forwarded message ---------- From: Date: Wed, Jun 20, 2018 at 9:28 PM Subject: I-D Action: draft-nishida-tcpm-disabling-paws-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Disabling PAWS When Other Protections Are Available Author : Yoshifumi Nishida Filename : draft-nishida-tcpm-disabling-paws-00.txt Pages : 7 Date : 2018-06-20 Abstract: PAWS provides protection against old duplicated segments caused by wrapped sequence or earlier incarnated connections. One drawback of PAWS is that it requires to place timestamp option in all segments, which consumes 10-12 bytes in the option space of TCP. In addition, since PAWS just checks if timestamps is older or not, the protection logic is not very strong against malicious attacks or cannot work properly in some situations. On the other hand, some other technologies which can provide stronger protections than PAWS are becoming available these days. In this document, we propose to utilize other protection mechanisms as replacements of PAWS when they are available. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nishida-tcpm-disabling-paws/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-nishida-tcpm-disabling-paws-00 https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-disabling-paws-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000000000000ee0f58056f215236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I have been thinking = about PAWS and TS option for a while and prepared a simple short draft.
The basic ideas in the draft are like this.

1: There are several technologies (such as tcpinc, mptcp, tls) that can be= used as a replacement of PAWS
=C2=A0 =C2=A0 They can even provid= e stronger protections than PAWS, which might be able to contribute to recy= cling connections in TIME_WAIT.

2: Some implementa= tions have records of transmission times on each segment which won't re= quire TS option for RTTM.
=C2=A0=C2=A0 =C2=A0
3: When 1= is available, we don't have to put a TS option in every segment.=C2=A0=
=C2=A0 =C2=A0 Also, when 1 and 2 are available, we don't hav= e to use TS option at all.
=C2=A0 =C2=A0 Since we already have ba= se technologies to replace PAWS and TS, all we need here is a simple signal= ing mechanism for feature negotiation.

The draft i= s still very premature and I may overlook something, but it would be great = if I could get some feedback.

Thanks,
--=
Yoshi

---------- Forwarded m= essage ----------
From: <internet-drafts@ietf.o= rg>
Date: Wed, Jun 20, 2018 at 9:28 PM
Subject: I-D Act= ion: draft-nishida-tcpm-disabling-paws-00.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Disabling PAWS When Other Protections Are Available
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Yosh= ifumi Nishida
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-nis= hida-tcpm-disabling-paws-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-06-20

Abstract:
=C2=A0 =C2=A0PAWS provides protection against old duplicated segments cause= d by
=C2=A0 =C2=A0wrapped sequence or earlier incarnated connections.=C2=A0 One = drawback of
=C2=A0 =C2=A0PAWS is that it requires to place timestamp option in all segm= ents,
=C2=A0 =C2=A0which consumes 10-12 bytes in the option space of TCP.=C2=A0 I= n addition,
=C2=A0 =C2=A0since PAWS just checks if timestamps is older or not, the prot= ection
=C2=A0 =C2=A0logic is not very strong against malicious attacks or cannot w= ork
=C2=A0 =C2=A0properly in some situations.=C2=A0 On the other hand, some oth= er
=C2=A0 =C2=A0technologies which can provide stronger protections than PAWS = are
=C2=A0 =C2=A0becoming available these days.=C2=A0 In this document, we prop= ose to
=C2=A0 =C2=A0utilize other protection mechanisms as replacements of PAWS wh= en they
=C2=A0 =C2=A0are available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-nishida-tcpm-disabling-paws/

There are also htmlized versions available at:
https://tools.ietf.org/html/dra= ft-nishida-tcpm-disabling-paws-00
https://datatracker.ietf.o= rg/doc/html/draft-nishida-tcpm-disabling-paws-00


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html<= /a>
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--000000000000ee0f58056f215236-- From nobody Fri Jun 22 09:57:26 2018 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 ABE0E130EAF for ; Fri, 22 Jun 2018 09:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 mR3nrAR-Qh_S for ; Fri, 22 Jun 2018 09:57:16 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 51E27130EE7 for ; Fri, 22 Jun 2018 09:57:16 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id p126-v6so2890089wmb.2 for ; Fri, 22 Jun 2018 09:57:16 -0700 (PDT) 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; bh=GCCgecUEznAANAm7FHj96gGWa6HbWmJEAze7exeWoi4=; b=J0ttJRC1D7e9HucG0t2bd+BKjyxp6hZBRBWzg2bmzAXjPJQ2qbqCC49QiZVzwaxzlI vR9/AmAGLktITH7G45jnbiG5HItIHxMLj+Dn6/Qgdkk0VjVc5lO7MA4MlyBz3DHY74mu xn8iytrffepfGi3tP0EbnlHwCNmXbTbmI4HUrgDlJcBZsEs7FIbktxh2LUFtG6IE+Jwo 5xRvyV0cNWYaXSokds7HteQT1bUNxwpGW9RErwQSgFrQTAdekqaJPfgXJRBk577GA2zs zNNoVg0oJsOZH9ZNp5YRooH4WsnUr4GU7emEEHcOnIE3uCGacxWEXdG0fYeNpNWe5uxS 5w1A== 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=GCCgecUEznAANAm7FHj96gGWa6HbWmJEAze7exeWoi4=; b=M45aZDEm6k/lDOTDQHrB32eJ9AiKA97G4R9eqFLx06U8emwl1KlAQ+HRCwu7PRN2cg Es5O0UAawysIdG6+RWlF1wOTHkxAyY9AEyXsRysXxc82K+Ng6ilJW5NqVZOHIer1NyFq ZzLZlhSHMpJkwhR+Kg5FvRLlrwH7HtN4YBhioA9ItRRgJRvCP6RgBVXxIXOavkIxIlkq QWTd5eFPJFfsRSnukuqyxtEPcT+cLo6Q+kxRZOAXnup/28lkEpSlExmskyr2qwdqFFwo bXZynPhQrypHn7ZzwMLs5mCZW4wzR0pbd1daxNZYv5Gz1HjoQj0kGvVIesPizsKM3YTF 68kg== X-Gm-Message-State: APt69E3WhnP+wC0myfMEb3vsXCddXOxnNlrsO9PBdAdW4LPn3GTkFjgh rCTvWrA/Ggokl0fJopDy0EaNVkJ6+IDFwZthl6JGeA== X-Google-Smtp-Source: ADUXVKKw3VKo/wfgvpUTDINDda/zvFbSokRgJIam2NjEL5OZgb5GnU/IvIo6jPgAmLJsyoHwP+iqXCW8krYJ490p7nI= X-Received: by 2002:a1c:69d7:: with SMTP id z84-v6mr2173505wmh.147.1529686634477; Fri, 22 Jun 2018 09:57:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Neal Cardwell Date: Fri, 22 Jun 2018 12:56:57 -0400 Message-ID: To: Yoshifumi Nishida Cc: "tcpm@ietf.org" , Yuchung Cheng , Eric Dumazet , Wei Wang , Van Jacobson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Fri, 22 Jun 2018 16:57:25 -0000 On Thu, Jun 21, 2018 at 2:50 AM Yoshifumi Nishida wrote: > > Hello, > > I have been thinking about PAWS and TS option for a while and prepared a simple short draft. > The basic ideas in the draft are like this. > > 1: There are several technologies (such as tcpinc, mptcp, tls) that can be used as a replacement of PAWS > They can even provide stronger protections than PAWS, which might be able to contribute to recycling connections in TIME_WAIT. > > 2: Some implementations have records of transmission times on each segment which won't require TS option for RTTM. > > 3: When 1 is available, we don't have to put a TS option in every segment. > Also, when 1 and 2 are available, we don't have to use TS option at all. > Since we already have base technologies to replace PAWS and TS, all we need here is a simple signaling mechanism for feature negotiation. > > The draft is still very premature and I may overlook something, but it would be great if I could get some feedback. > > Thanks, > -- > Yoshi Hi Yoshifumi, Thanks for this draft! Personally, I am fine with the general direction of disabling PAWS. But I would argue strongly for keeping TCP timestamps. The draft mentions "suppressing timestamp options" here: ... The goal of the proposal in the draft is to provide stronger protections for old duplicated segments while facilitating the use of TCP option space by suppressing timestamp options. I would argue strongly against suppressing/omitting TCP timestamp options, even if other mechanisms are available that subsume PAWS protection. There are a number of significant advantages to TCP timestamps, beyond PAWS: (1) quickly detecting spurious loss recoveries (using the Eifel algorithm - https://tools.ietf.org/html/rfc3522 - implemented by Linux) (2) architecturally, they allow TCP to have an approximation to the "packet number" that QUIC has (enabling (1)): https://tools.ietf.org/html/draft-ietf-quic-recovery-08#section-2 (3) allowing receivers to estimate RTT (used by Linux receive buffer autotuning) (4) allowing more precise bandwidth and RTT measurements by congestion control and passive monitoring systems And there are probably other nice uses that I'm forgetting. :-) >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): https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf 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 Regarding passive measurements using TCP timestamps, Kathleen Nichols has some great work using TCP timestamps to analyze TCP traffic. For example: https://datatracker.ietf.org/meeting/97/materials/slides-97-maprg-video-at-the-edge-passive-delay-measurements-kathleen-nichols-01.pdf cheers, neal > ---------- Forwarded message ---------- > From: > Date: Wed, Jun 20, 2018 at 9:28 PM > Subject: I-D Action: draft-nishida-tcpm-disabling-paws-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Disabling PAWS When Other Protections Are Available > Author : Yoshifumi Nishida > Filename : draft-nishida-tcpm-disabling-paws-00.txt > Pages : 7 > Date : 2018-06-20 > > Abstract: > PAWS provides protection against old duplicated segments caused by > wrapped sequence or earlier incarnated connections. One drawback of > PAWS is that it requires to place timestamp option in all segments, > which consumes 10-12 bytes in the option space of TCP. In addition, > since PAWS just checks if timestamps is older or not, the protection > logic is not very strong against malicious attacks or cannot work > properly in some situations. On the other hand, some other > technologies which can provide stronger protections than PAWS are > becoming available these days. In this document, we propose to > utilize other protection mechanisms as replacements of PAWS when they > are available. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-nishida-tcpm-disabling-paws/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-nishida-tcpm-disabling-paws-00 > https://datatracker.ietf.org/doc/html/draft-nishida-tcpm-disabling-paws-00 > > > 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. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm From nobody Fri Jun 22 11:35:41 2018 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 2D5B3130ED6 for ; Fri, 22 Jun 2018 11:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 yTjsOQ8B6rTW for ; Fri, 22 Jun 2018 11:35:32 -0700 (PDT) Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30374130EAF for ; Fri, 22 Jun 2018 11:35:32 -0700 (PDT) Received: from [10.0.0.246] (122.190.broadband18.iol.cz [109.81.190.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id D5E5E80517; Fri, 22 Jun 2018 20:26:00 +0200 (CEST) To: Yoshifumi Nishida , "tcpm@ietf.org" References: From: Fernando Gont Openpgp: preference=signencrypt Autocrypt: addr=fgont@si6networks.com; prefer-encrypt=mutual; keydata= xsFNBE5so2gBEACzBQBLUy8nzgAzSZn6ViXT6TmZBFNYNqTpPRvTVtUqF6+tkI+IEd9N2E8p pXUXCd0W4dkxz6o7pagnK63m4QSueggvp881RVVHOF8oTSHOdnGxLfLeLNJFKE1FOutU3vod GK/wG/Fwzkv9MebdXpMlLV8nnJuAt66XGl/lU1JrNfrKO4SoYQi4TsB/waUQcygh7OR/PEO0 EttiU8kZUbZNv58WH+PAj/rdZCrgUSiGXiWUQQKShqKnJxLuAcTcg5YRwL8se/V6ciW0QR9i /sr52gSmLLbW5N3hAoO+nv1V/9SjJAUvzXu43k8sua/XlCXkqU7uLj41CRR72JeUZ4DQsYfP LfNPC98ZGTVxbWbFtLXxpzzDDT8i3uo7w1LJ2Ij/d5ezcARqw01HGljWWxnidUrjbTpxkJ9X EllcsH94mer728j/HKzC9OcTuz6WUBP3Crgl6Q47gY5ZIiF0lsmd9/wxbaq5NiJ+lGuBRZrD v0dQx9KmyI0/pH2AF8cW897/6ypvcyD/1/11CJcN+uAGIrklwJlVpRSbKbFtGC6In592lhu7 wnK8cgyP5cTU+vva9+g6P1wehi4bylXdlKc6mMphbtSA+T3WBNP557+mh3L62l4pGaEGidcZ DLYT2Ud18eAJmxU3HnM8P3iZZgeoK7oqgb53/eg96vkONXNIOwARAQABzSVGZXJuYW5kbyBH b250IDxmZ29udEBzaTZuZXR3b3Jrcy5jb20+wsGBBBMBAgArAhsjBQkSzAMABgsJCAcDAgYV CAIJCgsEFgIDAQIeAQIXgAUCTmylpQIZAQAKCRCuJQ1VHU50kv7wD/9fuNtTfxSLk3B3Hs3p ixTy8YXVjdkVwWlnJjFd7BOWmg7sI+LDhpjGfT6+ddOiwkumnvUZpObodj4ysH0i8c7P4C5t F9yu7WjklSlrB5Rth2CGChg5bKt541z2WHkFFxys9qBLmCSYDeKQkzLqhCjIUJizY2kOJ2GI MnSFDzJjhSFEh//oW830Y8fel1xnf/NVF+lBVtRMtMOfoWUqDjvP3sJ1G4zgkDCnF0CfncLx +hq2Mv26Uq9OTzvLH9aSQQ/f067BOkKAJKsfHdborX4E96ISTz57/4xECRSMr5dVsKVm4Y// uVIsb+L5z+a32FaiBZIAKDgnJO7Z8j6CV5e5yfuBTtX52Yi9HjYYqnYJGSDxYd6igD4bWu+7 xmJPHjkdqZgGV6dQIgiUfqkU+s5Cv350vK48CMaT/ZLo2BdsMhWsmaHmb+waePUMyq6E4E9x 9Js+EJb9ZiCfxS9exgieZQpet1L36IvhiwByvkQM009ywfa30JeMOltUtfLi5V06WQWsTzPL 5C+4cpkguSuAJVDTctjCA0moIeVDOpJ8WH9voQ4IeWapQnX35OIoj1jGJqqYdx65gc1ygbyx b8vw+pJ9E5GLse5TQnYifOWpXzX9053dtbwp/2OVhU4KLlzfCPCEsoTyfu9nIZxdI2PMwiL5 M85BfjX4NmwBLmPGoM7BTQRObKNoARAAqqXCkr250BchRDmi+05F5UQFgylUh10XTAJxBeaQ UNtdxZiZRm6jgomSrqeYtricM9t9K0qb4X2ZXmAMW8o8AYW3RrQHTjcBwMnAKzUIEXXWaLfG cid/ygmvWzIHgMDQKP+MUq1AGQrnvt/MRLvZLyczAV1RTXS58qNaxtaSpc3K/yrDozh/a4pu WcUsVvIkzyx43sqcwamDSBb6U8JFoZizuLXiARLLASgyHrrCedNIZdWSx0z0iHEpZIelA2ih AGLiSMtmtikVEyrJICgO81DkKNCbBbPg+7fi23V6M24+3syHk3IdQibTtBMxinIPyLFF0byJ aGm0fmjefhnmVJyCIl/FDkCHprVhTme57G2/WdoGnUvnT7mcwDRb8XY5nNRkOJsqqLPemKjz kx8mXdQbunXtX9bKyVgd1gIl+LLsxbdzRCch773UBVoortPdK3kMyLtZ4uMeDX3comjx+6VL bztUdJ1Zc9/njwVG8fgmQ+0Kj5+bzQfUY+MmX0HTXIx3B4R1I1a8QoOwi1N+iZNdewV5Zfq+ 29NlQLnVPjCRCKbaz9k6RJ2oIti55YUI6zSsL3lmlOXsRbXN5bRswFczkNSCJxJMlDiyAUIC WOay7ymzvgzPa+BY/mYn94vRaurDQ4/ljOfj6oqgfjts+dJev4Jj89vp8MQI3KJpZPEAEQEA AcLBZQQYAQIADwUCTmyjaAIbDAUJEswDAAAKCRCuJQ1VHU50km4xEACho45PZrUjY4Zl2opR DFNo5a6roTOPpgwO9PcBb3I5F8yX2Dnew+9OhgWXbBhAFq4DCx+9Gjs43Bn60qbZTDbLGJ/m 8N4PwEiq0e5MKceYcbetEdEUWhm5L6psU9ZZ82GR3UGxPXYe+oifEoJjOXQ39avf9S8p3yKP Diil0E79rn7LbJjMcgMLyjFg9SDoJ6pHLtniJoDhEAaSSgeV7Y745+gyMIdtQmrFHfqrFdjq D6G0HE+Z68ywc5KN67YxhvhBmSycs1ZSKAXv1zLDlXdmjHDHkU3xMcB+RkuiTba8yRFYwb/n j62CC4NhFTuIKOc4ta3dJsyXTGh/hO9UjWUnmAGfd0fnzTBZF8Qlnw/8ftx5lt4/O+eqY1EN RITScnPzXE/wMOlTtdkddQ+QN6xt6jyR2XtAIi7aAFHypIqA3lLI9hF9x+lj4UQ2yA9LqpoX 6URpPOd13JhAyDe47cwsP1u9Y+OBvQTVLSvw7Liu2b4KjqL4lx++VdBi7dXsjJ6kjIRjI6Lb WVpxe8LumMCuVDepTafBZ49gr7Fgc4F9ZSCo6ChgQNLn6WDzIkqFX+42KuHz90AHWhuW+KZR 1aJylERWeTcMCGUSBptd48KniWmD6kPKpzwoMkJtEXTuO2lVuborxzwuqOTNuYg9lWDl7zKt wPI9brGzquUHy4qRrA== Message-ID: Date: Fri, 22 Jun 2018 18:26:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Fri, 22 Jun 2018 18:35:35 -0000 On 06/21/2018 09:49 AM, Yoshifumi Nishida wrote: > Hello, > > I have been thinking about PAWS and TS option for a while and prepared a > simple short draft. > The basic ideas in the draft are like this. > > 1: There are several technologies (such as tcpinc, mptcp, tls) that can > be used as a replacement of PAWS >     They can even provide stronger protections than PAWS, which might be > able to contribute to recycling connections in TIME_WAIT. Not sure if I understood correctly, but you may be able to recycle connections in the TIME-WAIT state if the initial timestamps are monotonically-increasing. Cheers, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From nobody Fri Jun 22 16:19:13 2018 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 E728F130F0E for ; Fri, 22 Jun 2018 16:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tG8WgkpsCj66 for ; Fri, 22 Jun 2018 16:19:04 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D490F130E10 for ; Fri, 22 Jun 2018 16:19:03 -0700 (PDT) Received: from mail-io0-f171.google.com (mail-io0-f171.google.com [209.85.223.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BE4B22783AE for ; Sat, 23 Jun 2018 08:19:00 +0900 (JST) Received: by mail-io0-f171.google.com with SMTP id q4-v6so7534715iob.2 for ; Fri, 22 Jun 2018 16:19:00 -0700 (PDT) X-Gm-Message-State: APt69E1ZTHPWtXrnyPPpysSqeVw45SqMGlAd+ALOVJ5b06aANlBVmqBJ SDFLO98QopTcl8Cc/RE7JjePSqbNFOyorw4G2A8= X-Google-Smtp-Source: AAOMgpfK0MpVBMhXSOfev26xI/cZg917GL9MCvQSL7CbnsFZv8JbBZ+rIHJNZGWRO6WfNIcpdsU91000AjxJJr49iQA= X-Received: by 2002:a6b:dd14:: with SMTP id f20-v6mr2926879ioc.7.1529709539588; Fri, 22 Jun 2018 16:18:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 16:18:58 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 22 Jun 2018 16:18:58 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Fernando Gont Cc: Yoshifumi Nishida , "tcpm@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b78209056f43417d" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Fri, 22 Jun 2018 23:19:11 -0000 --000000000000b78209056f43417d Content-Type: text/plain; charset="UTF-8" Hi Fernando, On Fri, Jun 22, 2018 at 8:26 AM, Fernando Gont wrote: > On 06/21/2018 09:49 AM, Yoshifumi Nishida wrote: > > Hello, > > > > I have been thinking about PAWS and TS option for a while and prepared a > > simple short draft. > > The basic ideas in the draft are like this. > > > > 1: There are several technologies (such as tcpinc, mptcp, tls) that can > > be used as a replacement of PAWS > > They can even provide stronger protections than PAWS, which might be > > able to contribute to recycling connections in TIME_WAIT. > > Not sure if I understood correctly, but you may be able to recycle > connections in the TIME-WAIT state if the initial timestamps are > monotonically-increasing. > > Yes, you're right as long as initial timestamps are monotonically increasing. But, I think this is not true on some implementations (e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=95a22caee396cef0bb2ca8fafdd82966a49367bb ) I think it would be better if we can have other ways than PAWS to support this kind of situations. -- Yoshi --000000000000b78209056f43417d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Fernando,

On Fri, Jun 22, 2018 at 8:26 AM, Fernando Gont <fgo= nt@si6networks.com> wrote:
On 06/21/2018 09:49 AM, Yoshifumi= Nishida wrote:
> Hello,
>
> I have been thinking about PAWS and TS option for a while and prepared= a
> simple short draft.
> The basic ideas in the draft are like this.
>
> 1: There are several technologies (such as tcpinc, mptcp, tls) that ca= n
> be used as a replacement of PAWS
> =C2=A0 =C2=A0 They can even provide stronger protections than PAWS, wh= ich might be
> able to contribute to recycling connections in TIME_WAIT.

Not sure if I understood correctly, but you may be able to recycle connections in the TIME-WAIT state if the initial timestamps are
monotonically-increasing.

Yes, you're right as long as initial timestamps a= re monotonically increasing.
I = think it would be better if we can have other ways than PAWS to support thi= s kind of situations.
--
Yoshi
=C2=A0
--000000000000b78209056f43417d-- From nobody Fri Jun 22 16:23:26 2018 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 DB882130F0E for ; Fri, 22 Jun 2018 16:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 lS2ZRgyZH54N for ; Fri, 22 Jun 2018 16:23:21 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46927130E10 for ; Fri, 22 Jun 2018 16:23:21 -0700 (PDT) Received: from mail-io0-f170.google.com (mail-io0-f170.google.com [209.85.223.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 760C4278536 for ; Sat, 23 Jun 2018 08:23:19 +0900 (JST) Received: by mail-io0-f170.google.com with SMTP id f1-v6so7534358ioh.6 for ; Fri, 22 Jun 2018 16:23:19 -0700 (PDT) X-Gm-Message-State: APt69E22/lzvXswin94OgTUga8L2GL4LgOnUWA75Zm1aTGgvwOwIUvdf nFQ1pvLZA81Xcs66V4ppBKZsLEaIKOUEcprmN9s= X-Google-Smtp-Source: AAOMgpdA5lZfLred2woz/RkjtEE2TjGMKfPTzTVDhd8J7YCrMafpP8+bIHGEFAP9Jc/J/HL2geHZYg932fmr7xRt6Hg= X-Received: by 2002:a6b:dd14:: with SMTP id f20-v6mr2934767ioc.7.1529709798384; Fri, 22 Jun 2018 16:23:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 16:23:17 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 22 Jun 2018 16:23:17 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Neal Cardwell Cc: Yoshifumi Nishida , "tcpm@ietf.org" , Yuchung Cheng , Eric Dumazet , Wei Wang , Van Jacobson Content-Type: multipart/alternative; boundary="0000000000002469f9056f435150" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Fri, 22 Jun 2018 23:23:25 -0000 --0000000000002469f9056f435150 Content-Type: text/plain; charset="UTF-8" Hi Neal, On Fri, Jun 22, 2018 at 9:56 AM, Neal Cardwell wrote: > On Thu, Jun 21, 2018 at 2:50 AM Yoshifumi Nishida > wrote: > > > > Hello, > > > > I have been thinking about PAWS and TS option for a while and prepared a > simple short draft. > > The basic ideas in the draft are like this. > > > > 1: There are several technologies (such as tcpinc, mptcp, tls) that can > be used as a replacement of PAWS > > They can even provide stronger protections than PAWS, which might be > able to contribute to recycling connections in TIME_WAIT. > > > > 2: Some implementations have records of transmission times on each > segment which won't require TS option for RTTM. > > > > 3: When 1 is available, we don't have to put a TS option in every > segment. > > Also, when 1 and 2 are available, we don't have to use TS option at > all. > > Since we already have base technologies to replace PAWS and TS, all > we need here is a simple signaling mechanism for feature negotiation. > > > > The draft is still very premature and I may overlook something, but it > would be great if I could get some feedback. > > > > Thanks, > > -- > > Yoshi > > > Hi Yoshifumi, > > Thanks for this draft! Personally, I am fine with the general > direction of disabling PAWS. But I would argue strongly for keeping > TCP timestamps. > The draft mentions "suppressing timestamp options" here: > > ... The goal of the > proposal in the draft is to provide stronger protections for old > duplicated segments while facilitating the use of TCP option space by > suppressing timestamp options. > > I would argue strongly against suppressing/omitting TCP timestamp > options, even if other mechanisms are available that subsume PAWS > protection. > > There are a number of significant advantages to TCP timestamps, beyond > PAWS: > > (1) quickly detecting spurious loss recoveries (using the Eifel > algorithm - https://tools.ietf.org/html/rfc3522 - implemented by > Linux) > > (2) architecturally, they allow TCP to have an approximation to the > "packet number" that QUIC has (enabling (1)): > https://tools.ietf.org/html/draft-ietf-quic-recovery-08#section-2 > > (3) allowing receivers to estimate RTT (used by Linux receive buffer > autotuning) > > (4) allowing more precise bandwidth and RTT measurements by congestion > control and passive monitoring systems > > And there are probably other nice uses that I'm forgetting. :-) > Thanks. These are very useful pointers for me to think about the draft further. I think you argument is fair enough. My intention is to relax the requirement "The TSopt MUST be sent in every non- 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): > > https://www.ietf.org/proceedings/97/slides/slides- > 97-tcpm-tcp-options-for-low-latency-00.pdf > > 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 > Yes, I am aware of this draft. One thing I'm curious is that I thought servers in google may have records of transmission time per packet as it's required by RACK. However, this draft utilizes TS option with fine granularity. Do you still need TS option even when you have records of transmission time, or this feature is not used in the datacenter? Anyway, both changing timestamp granularity and disabling PAWS change TS option semantics. It can make sense to have an unified negotiation scheme for both. I will think about it more. Thank you so much! -- Yoshi --0000000000002469f9056f435150 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Neal,

On Fri, Jun 22, 2018 at 9:56 AM, Neal Cardwell <ncardwell@g= oogle.com> wrote:
On Thu, Jun 21, 2018 at 2:50 AM Yoshifumi Nishida
<nishida@sfc.wide.ad.jp>= ; wrote:
>
> Hello,
>
> I have been thinking about PAWS and TS option for a while and prepared= a simple short draft.
> The basic ideas in the draft are like this.
>
> 1: There are several technologies (such as tcpinc, mptcp, tls) that ca= n be used as a replacement of PAWS
>=C2=A0 =C2=A0 =C2=A0They can even provide stronger protections than PAW= S, which might be able to contribute to recycling connections in TIME_WAIT.=
>
> 2: Some implementations have records of transmission times on each seg= ment which won't require TS option for RTTM.
>
> 3: When 1 is available, we don't have to put a TS option in every = segment.
>=C2=A0 =C2=A0 =C2=A0Also, when 1 and 2 are available, we don't have= to use TS option at all.
>=C2=A0 =C2=A0 =C2=A0Since we already have base technologies to replace = PAWS and TS, all we need here is a simple signaling mechanism for feature n= egotiation.
>
> The draft is still very premature and I may overlook something, but it= would be great if I could get some feedback.
>
> Thanks,
> --
> Yoshi


Hi Yoshifumi,

Thanks for this draft! Personally, I am fine with the general
direction of disabling PAWS. But I would argue strongly for keeping
TCP timestamps.=C2=A0

The draft mentions "suppressing timestamp options" here:

=C2=A0 ... The goal of the
=C2=A0 =C2=A0proposal in the draft is to provide stronger protections for o= ld
=C2=A0 =C2=A0duplicated segments while facilitating the use of TCP option s= pace by
=C2=A0 =C2=A0suppressing timestamp options.

I would argue strongly against suppressing/omitting TCP timestamp
options, even if other mechanisms are available that subsume PAWS
protection.

There are a number of significant advantages to TCP timestamps, beyond PAWS= :

(1) quickly detecting spurious loss recoveries (using the Eifel
algorithm - https://tools.ietf.org/html/rfc3522 - implem= ented by
Linux)

(2) architecturally, they allow TCP to have an approximation to the
"packet number" that QUIC has (enabling (1)):
=C2=A0 https://tools.ietf.org/html/= draft-ietf-quic-recovery-08#section-2

(3) allowing receivers to estimate RTT (used by Linux receive buffer autotu= ning)

(4) allowing more precise bandwidth and RTT measurements by congestion
control and passive monitoring systems

And there are probably other nice uses that I'm forgetting. :-)

Thanks. These are very useful pointers for me = to think about the draft further.

I think you argu= ment is fair enough.

My intention is to relax the = requirement "The = TSopt MUST be sent in every non-<RST>=C2=A0segment for the duration of the connectio= n" in RFC7323
so that TSopt can be sent at arbitrary intervals. Arbi= trary intervals can contain infinite interval, but you can only do so when = you really want, otherwise you shouldn't.
So, disabling TS entirely i= s just an option.=C2=A0


>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):

=C2=A0 h= ttps://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-opti= ons-for-low-latency-00.pdf

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.:

=C2=A0bits : meaning
=C2=A0 00: traditional RFC 7323 timestamps: use PAWS
=C2=A0 01: microsecond timestamps, disable PAWS
=C2=A0 10: millisecond timestamps, disable PAWS
=C2=A0 11: values with other semantics, disable PAWS
<= br>
Yes, I am aware of this draft.
One thing I'm cu= rious is that I thought servers in google may have records of transmission = time per packet as it's required by RACK.
However, this draft= utilizes TS option with fine granularity.=C2=A0
Do you still nee= d TS option even when you have records of transmission time, or this featur= e is not used in the datacenter?

Anyway, both chan= ging timestamp granularity and disabling PAWS change TS option semantics.= =C2=A0
It can make sense to have an unified negotiation scheme fo= r both.
I will think about it more.

Than= k you so much!
--
Yoshi
--0000000000002469f9056f435150-- From nobody Sun Jun 24 20:09:04 2018 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 16A7A12777C for ; Sun, 24 Jun 2018 20:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 2TVi-W0zPDE7 for ; Sun, 24 Jun 2018 20:08:59 -0700 (PDT) Received: from lauren.room52.net (lauren.room52.net [45.63.28.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 949E4124BE5 for ; Sun, 24 Jun 2018 20:08:59 -0700 (PDT) Received: by lauren.room52.net (Postfix) with ESMTPSA id 6D55F1B149; Mon, 25 Jun 2018 13:08:57 +1000 (AEST) To: Yoshifumi Nishida , Neal Cardwell Cc: "tcpm@ietf.org" , Eric Dumazet , Van Jacobson References: From: Lawrence Stewart Message-ID: Date: Mon, 25 Jun 2018 13:08:56 +1000 User-Agent: Not your concern MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 25 Jun 2018 03:09:02 -0000 Greetings Yoshifumi and all, On 23/06/2018 09:23, Yoshifumi Nishida wrote: > Hi Neal, > > On Fri, Jun 22, 2018 at 9:56 AM, Neal Cardwell > wrote: > > On Thu, Jun 21, 2018 at 2:50 AM Yoshifumi Nishida > > wrote: > > > > Hello, > > > > I have been thinking about PAWS and TS option for a while and prepared a simple short draft. > > The basic ideas in the draft are like this. > > > > 1: There are several technologies (such as tcpinc, mptcp, tls) that can be used as a replacement of PAWS > >     They can even provide stronger protections than PAWS, which might be able to contribute to recycling connections in TIME_WAIT. > > > > 2: Some implementations have records of transmission times on each segment which won't require TS option for RTTM. > > > > 3: When 1 is available, we don't have to put a TS option in every segment. > >     Also, when 1 and 2 are available, we don't have to use TS option at all. > >     Since we already have base technologies to replace PAWS and TS, all we need here is a simple signaling mechanism for feature negotiation. > > > > The draft is still very premature and I may overlook something, but it would be great if I could get some feedback. > > > > Thanks, > > -- > > Yoshi > > > Hi Yoshifumi, > > Thanks for this draft! Personally, I am fine with the general > direction of disabling PAWS. But I would argue strongly for keeping > TCP timestamps.  > > > The draft mentions "suppressing timestamp options" here: > >   ... The goal of the >    proposal in the draft is to provide stronger protections for old >    duplicated segments while facilitating the use of TCP option space by >    suppressing timestamp options. > > I would argue strongly against suppressing/omitting TCP timestamp > options, even if other mechanisms are available that subsume PAWS > protection. > > There are a number of significant advantages to TCP timestamps, > beyond PAWS: > > (1) quickly detecting spurious loss recoveries (using the Eifel > algorithm - https://tools.ietf.org/html/rfc3522 > - implemented by > Linux) > > (2) architecturally, they allow TCP to have an approximation to the > "packet number" that QUIC has (enabling (1)): >   https://tools.ietf.org/html/draft-ietf-quic-recovery-08#section-2 > > > (3) allowing receivers to estimate RTT (used by Linux receive buffer > autotuning) > > (4) allowing more precise bandwidth and RTT measurements by congestion > control and passive monitoring systems > > And there are probably other nice uses that I'm forgetting. :-) > > > Thanks. These are very useful pointers for me to think about the draft > further. > > I think you argument is fair enough. > > My intention is to relax the requirement "The TSopt MUST be sent in > every non- 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): > >   > https://www.ietf.org/proceedings/97/slides/slides-97-tcpm-tcp-options-for-low-latency-00.pdf > > > 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 > > > Yes, I am aware of this draft. > One thing I'm curious is that I thought servers in google may have > records of transmission time per packet as it's required by RACK. > However, this draft utilizes TS option with fine granularity.  > Do you still need TS option even when you have records of transmission > time, or this feature is not used in the datacenter? > > Anyway, both changing timestamp granularity and disabling PAWS change TS > option semantics.  > It can make sense to have an unified negotiation scheme for both. > I will think about it more. On this topic, bits of my PhD thesis may be of tangential interest: https://researchbank.swinburne.edu.au/file/67be6dea-9503-43d4-bb6b-8d3f28d74272/1/lawrence_stewart_thesis.pdf Chapter 6 (page 100) in particular explores a simplistic PAWS-compatible scheme that uses the TSVal as a token so that arbitrary granularity clocks can be associated with different connections (e.g. to facilitate path-appropriate RTT measurement and in turn aid incast mitigation in low-latency IP networks). Cheers, Lawrence From nobody Mon Jun 25 02:34:40 2018 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 1817912D949 for ; Mon, 25 Jun 2018 02:34:38 -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 kdS6DZJwYlDg for ; Mon, 25 Jun 2018 02:34:36 -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 824661277C8 for ; Mon, 25 Jun 2018 02:34:35 -0700 (PDT) Received: from [192.168.233.107] ([213.143.121.76]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lqhaw-1g2Zg409A2-00eQ4F; Mon, 25 Jun 2018 11:32:46 +0200 To: tcpm@ietf.org, nishida@sfc.wide.ad.jp, ncardwell@google.com References: From: "Scheffenegger, Richard" Message-ID: <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> Date: Mon, 25 Jun 2018 11:32:48 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:qt7HZhH60mePmy1QRwp2p7EY+1rJsh1weREuvjzDnmXR/7KUdzD QcPXjv8w6skVVCvRzpFnKubll+jSk9eZwSqxeJr+KCQpkerRPre+4LkTyIRL0Hql9McOeyK ehOFSDPIgR7OL3mrffh4wWjgCuclhl0udHdbfP9Jby+dRSZIucecsxNqXReZgnbLPC8BAU5 SAe8yGCcCrxpq3oFlhOVA== X-UI-Out-Filterresults: notjunk:1;V01:K0:kB9sc13f+4w=:vIUCGJ4/7cBjLmWoqWQ8dW CJ8Y+EKW23bm43YDEF8vCfqhTiHEsb5Vq2WUpxTJwtMn2LmD4giSwPX7OEh0tOA92iTj1eWyY I8fC2LD8lb17qgJSmhPZQgdym1Z4f2vmCsoF/zk1kGfaBjzBnEsQHyAq8yZJ6r6MkO6fAIIAM 6qHO1tjhK/JUWHWRDRrgyIGcRQdu0usJfimydTxvjDvNJzvxkO1KPzkcVlxbC3fU0Ru1Qhk3Y 9eQx67Q93+FBQYDQxYRQ5z423XdE8sVYLI44PGb/teRhpCOeTFHs2v7auNa616BlLoe2bmTbd 7LfSbzcyA1JFEOlRyPY7iMtOabJMd413BiwJMXBAiCFNUukLRU7fr0rJ7tmNbjWx7AQoHV/T7 XuaS/+19kjnKmQH2c8p6uoMN5oPaxSL9sMHgPITFUg/nTWBb0XRMNaXBVW7dCVL1+2DMDVMw7 OEib3Gogx0qgeQAguUr6lGToz6ZEFZSa7Wm4vQ1UkcGU7AKIQ+AjuIFwK6ZD91T8RcRasUFP/ ir/UK4wCJc/8YwEOfdon1Kf1V9gJt4/+3i5TVz5fxJpCK7I8K8407Y5zeV2/yEPZToUjKg3A2 7q02VAlOi8TNKzSViOLbhO4ZbUWAhA2fkhndv64zpWC80IPAWyCH//C1y+FvERoI+VuTHMp58 iM0uB/MTpoGgn4zkOajrAXRsaTyZKQczQnMYFDvrs73vKjkBUujYqdIiftejjTecYWLdYTUGc c8wGw+Q3FIMzWIx+3NFQ6adiXAaSZlTmyEGXV1sX6TrxNqqcrv5vTHv3tEjo2gXzy6mV266HY O2DVDyM Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 25 Jun 2018 09:34:38 -0000 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- 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 Best regards, Richard From nobody Mon Jun 25 13:29:24 2018 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 F2886130E3E for ; Mon, 25 Jun 2018 13:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.511 X-Spam-Level: X-Spam-Status: No, score=-17.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham 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 FLxZy_T9nXq2 for ; Mon, 25 Jun 2018 13:29:21 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 9E3C9130E40 for ; Mon, 25 Jun 2018 13:29:21 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id p185-v6so14252379itp.4 for ; Mon, 25 Jun 2018 13:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ToRX7PtkpZczpgQtItA0ypwSH7/iNsj56uInTI4ZveM=; b=FF51ytXYzn8hhjzCnp9ctO3CbWXvdzVteff5LoXLdcxs64d7Vcc45ruvnCac2kR16f yClyGvkEEy1JwWsV2wQd68AutMw2Y7R7uIIv+Ioy9TrrdL+DI8JXaFYc3ClNCuY3CYXR DyeQGxMEQzmxzSINKMqUCAzPqnzbCy5nu2iziCYjnTcc5gu2rhol0sE8IwrIXHHIDA4s HOp/qezvkrpTKb8EzbzaQu6RPO88a0Jp1MrmWAdGCz8rriCQTVGX5lI+PKSbtPfZuytu bOj0RwpSCwXm9W+wUaXy8uEvVDDJWXCDoJII/fw322XJ2J9j6YA/ZXhB94Zfog6USoGJ QOLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ToRX7PtkpZczpgQtItA0ypwSH7/iNsj56uInTI4ZveM=; b=SCauCWSwxW1Bi77Fbtmg0SZMBH5vAqPYEgAysZV50HkhhRBN9X2MpykJBOtAeXteEr Z3oKqtVWTPREpgdj13pdOILlwbBKQg6qABE6IY8hfPNCKSaeytF66SQDTapb58FT2tmY KVBMgUOWrl5N/bdKdT1mMuY+9uOagU9XN26fxuy7Ouv+WftY6j1LetryvSROYgEYS1jH RSllQcgaIwFJ2iCavKMyIr2ciPE/IBn5mTFzGmTZW4mE6OTaoJjtdqrsnJ3IT4+gacY0 p/JMJuT9xms2MJorRbbLsVaOJd+6bDiqk4s+p9vs6wxnRNa2eGid3wcijQKjpTROuduC ruRA== X-Gm-Message-State: APt69E2I1TpnvhdEA3XsZ3+rPooFMQhDsoaICitFovjgZk4SGZDm9AzM KXIpTP+xpvO4AgQIxv8d8URqAkloKBZe9g0Re3aMDA== X-Google-Smtp-Source: AAOMgpeIBTPrR2ZwIGPpRztE5IX2bENWllSop+OSmPC3UKf9o2Zqj65Ntsc/3UXmXgfOHMRMUfeqijl542sMjHxdO10= X-Received: by 2002:a24:9003:: with SMTP id x3-v6mr2127261itd.139.1529958560647; Mon, 25 Jun 2018 13:29:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:6b17:0:0:0:0:0 with HTTP; Mon, 25 Jun 2018 13:28:39 -0700 (PDT) In-Reply-To: References: From: Yuchung Cheng Date: Mon, 25 Jun 2018 13:28:39 -0700 Message-ID: To: Yoshifumi Nishida Cc: Neal Cardwell , "tcpm@ietf.org" , Eric Dumazet , Wei Wang , Van Jacobson Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Mon, 25 Jun 2018 20:29:23 -0000 > Do you still need TS option even when you have records of transmission time, or this feature is not used in the datacenter? RACK's packet sent time and TS options are orthogonal. but yes we do use both. In particular, the TS-opt val in Google DCs is in microsecond unit, which we negotiated internally using a private option like what Neal proposed. We do have to relax the PAWs check for that, so your proposal would make this feature standardize-able for public Internet :-) RACK's packet sent time is essential to RACK. But TS-opt is a nice to have feature to measure RTT on retransmitted packets. From nobody Tue Jun 26 21:02:20 2018 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 010A2130F49 for ; Tue, 26 Jun 2018 21:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 qnMe411rh10m for ; Tue, 26 Jun 2018 21:01:58 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67355130F56 for ; Tue, 26 Jun 2018 21:01:58 -0700 (PDT) Received: from mail-it0-f50.google.com (mail-it0-f50.google.com [209.85.214.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 90FD32784DC for ; Wed, 27 Jun 2018 13:01:55 +0900 (JST) Received: by mail-it0-f50.google.com with SMTP id l16-v6so4672332ita.0 for ; Tue, 26 Jun 2018 21:01:55 -0700 (PDT) X-Gm-Message-State: APt69E2N4rJY32Bg1aZp88WhsMtMVlltzajCfyg7k90zd1fb/GUFoTrG 6YALm1Ad2fPFe3bU8Bvx10kQZpngy3r4uwWxU3k= X-Google-Smtp-Source: AAOMgpdz/P+VwDc2Lb35B3KL9MEh3msXV+DB+mXiQxMzD9PdISpcSQCu1EuBybwL7ctcdYxoVrzMeiQ5nWQjy9H8jpQ= X-Received: by 2002:a24:3105:: with SMTP id y5-v6mr3622360ity.138.1530072114382; Tue, 26 Jun 2018 21:01:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 21:01:53 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Tue, 26 Jun 2018 21:01:53 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Yuchung Cheng Cc: Yoshifumi Nishida , Neal Cardwell , "tcpm@ietf.org" , Eric Dumazet , Wei Wang , Van Jacobson Content-Type: multipart/alternative; boundary="000000000000dbcd03056f97ac9f" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Wed, 27 Jun 2018 04:02:12 -0000 --000000000000dbcd03056f97ac9f Content-Type: text/plain; charset="UTF-8" Hi Yuchung, On Mon, Jun 25, 2018 at 1:28 PM, Yuchung Cheng wrote: > > Do you still need TS option even when you have records of transmission > time, or this feature is not used in the datacenter? > > RACK's packet sent time and TS options are orthogonal. but yes we do > use both. In particular, the TS-opt val in Google DCs is in > microsecond unit, which we negotiated internally using a private > option like what Neal proposed. We do have to relax the PAWs check for > that, so your proposal would make this feature standardize-able for > public Internet :-) > > RACK's packet sent time is essential to RACK. But TS-opt is a nice to > have feature to measure RTT on retransmitted packets. > Thanks for the useful info. It seems that people still want to keep TS. Just to be clear, the main point of the draft is to disable PAWS as the title indicates. I guess I should focus on this point more explicitly in the next version. -- Yoshi --000000000000dbcd03056f97ac9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yuchung,=C2=A0

On Mon, Jun 25, 2018 at 1:28 PM, Yuchung Cheng <ychen= g@google.com> wrote:
= > Do you still need TS option even when you have records of transmission= time, or this feature is not used in the datacenter?

RACK's packet sent time and TS options are orthogonal. but yes w= e do
use both. In particular, the TS-opt val in Google DCs is in
microsecond unit, which we negotiated internally using a private
option like what Neal proposed. We do have to relax the PAWs check for
that, so your proposal would make this feature standardize-able for
public Internet :-)

RACK's packet sent time is essential to RACK. But TS-opt is a nice to have feature to measure RTT on retransmitted packets.
=
Thanks for the useful info. It seems that people still want = to keep TS.

Just to be clear, the main point of th= e draft is to disable PAWS as the title indicates.
I guess I = should focus on this point more explicitly in the next version.
-= -
Yoshi
--000000000000dbcd03056f97ac9f-- From nobody Tue Jun 26 21:05:47 2018 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 E554812785F for ; Tue, 26 Jun 2018 21:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Z2_Sdh0bTO8A for ; Tue, 26 Jun 2018 21:05:42 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57DF124BE5 for ; Tue, 26 Jun 2018 21:05:41 -0700 (PDT) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 82AA0278572 for ; Wed, 27 Jun 2018 13:05:39 +0900 (JST) Received: by mail-it0-f52.google.com with SMTP id 128-v6so5518235itf.1 for ; Tue, 26 Jun 2018 21:05:39 -0700 (PDT) X-Gm-Message-State: APt69E02N4EIAiBchXPyjYG1orjMPNx4xvbDpb10r4ahkixdh+8bQ+A6 xYxIEj8X5Q0XGt4pzkECsZbaofxBBQg7kR1Nc+A= X-Google-Smtp-Source: AAOMgpfxsVMgeClQLS1TBpiPnZETmnOIDmfTM3WA6aozUJZB0fmNusFrbCgiiuTjzBFy1YcGx20Y/B4b1WdOv1E7OYw= X-Received: by 2002:a02:9914:: with SMTP id r20-v6mr3478857jaj.144.1530072338184; Tue, 26 Jun 2018 21:05:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7599:0:0:0:0:0 with HTTP; Tue, 26 Jun 2018 21:05:37 -0700 (PDT) In-Reply-To: <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> References: <3b6c1b5f-766c-12e1-5fa9-35e369042120@gmx.at> From: Yoshifumi Nishida Date: Tue, 26 Jun 2018 21:05:37 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Scheffenegger, Richard" Cc: "tcpm@ietf.org" , Yoshifumi Nishida , ncardwell@google.com Content-Type: multipart/alternative; boundary="00000000000032c0af056f97ba9b" Archived-At: Subject: Re: [tcpm] Disabling PAWS when possible X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.26 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: Wed, 27 Jun 2018 04:05:45 -0000 --00000000000032c0af056f97ba9b Content-Type: text/plain; charset="UTF-8" Hi Richard, On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard 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- 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-timesta > mp-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 --00000000000032c0af056f97ba9b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Richard,

On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard <rs.= ietf@gmx.at> wrote:
Hi Yosh= ifumi, Neal,


Am 23.06.2018 um 01:23 schrieb Yoshifumi Nishida:

My intention is to relax the requirement "The TSopt MUST be sent in ev= ery non-<RST> segment for the duration of the connection" in RFC= 7323
so that TSopt can be sent at arbitrary intervals. Arbitrary intervals can c= ontain infinite interval, but you can only do so when you really want, othe= rwise you shouldn't.
So, disabling TS entirely is just an option.


=C2=A0 >=C2=A0 From my perspective, one huge advantage from disabling PA= WS is that it
=C2=A0 >=C2=A0 enables the timestamps to be an opaque identifier, so tha= t the sender
=C2=A0 >=C2=A0 can use them in any way it chooses. In particular, it wou= ld allow the
=C2=A0 >=C2=A0 sender to use microsecond timestamps, without worrying ab= out the
=C2=A0 >=C2=A0 remote side dropping packets due to PAWS checks. This was= the main
=C2=A0 >=C2=A0 challenge we found in implementing microsecond TCP timest= amps inside
=C2=A0 >=C2=A0 Google datacenters, as we discussed at TCPM a while back = (slide 6):

 [...]

>=C2=A0 =C2=A0>=C2=A0 My main comment would be, if some proposal is g= oing to
>=C2=A0 =C2=A0>=C2=A0 standardize a negotiation scheme for using time= stamps but
>=C2=A0 =C2=A0>=C2=A0 disabling PAWS, IMHO there could be huge value = in having that
>=C2=A0 =C2=A0>=C2=A0 negotiation mechanism optionally specify the se= mantics of a
>=C2=A0 =C2=A0>=C2=A0 sender's timestamp values, so that congesti= on control and
>=C2=A0 =C2=A0>=C2=A0 passive monitoring tools could make use of the = timestamps
>=C2=A0 =C2=A0>=C2=A0 for bandwidth and latency measurements. This co= uld be
>=C2=A0 =C2=A0>=C2=A0 something as simple as 2 bits, e.g.:
>=C2=A0 =C2=A0>
>=C2=A0 =C2=A0>=C2=A0 bits : meaning
>=C2=A0 =C2=A0>=C2=A0 =C2=A000: traditional RFC 7323 timestamps: use = PAWS
>=C2=A0 =C2=A0>=C2=A0 =C2=A001: microsecond timestamps, disable PAWS<= br> >=C2=A0 =C2=A0>=C2=A0 =C2=A010: millisecond timestamps, disable PAWS<= br> >=C2=A0 =C2=A0>=C2=A0 =C2=A011: 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 compl= etely opaque - that is, disallowing the receiver to make any use of it, onl= y allowing it to be a signal from the sender in the past (1RTT) to the send= er in the future.

Or making it more transparent, but disabling PAWS - meaning that the conten= t of TSopt can actually be interpreted by a receiver, potentially allowing = additional capabilities (one-way delay variation measurement, "TCP Chi= rp", springs to mind).


Provided the clock granularity is fine enough, both points (unique packet i= dentifier, 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

Yep, signaling mechanism to change the semantics = of TS is an interesting point for discussions.
We can extend TS o= ption like you proposed in the draft or integrating into existing negotiati= on mechanisms or developing a new option.
Developing a new option= seems to be a straightforward approach, but it will consume extra option s= pace and may be discarded by middleboxes.

BTW, the= draft above is cited in the draft as a good starting point of discussion.<= /div>
--
Yoshi

=C2=A0
--00000000000032c0af056f97ba9b--