Re: [tcpm] usage for timestamp options in the wild

Praveen Balasubramanian <pravb@microsoft.com> Thu, 27 September 2018 16:35 UTC

Return-Path: <pravb@microsoft.com>
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 E4AED130EBC for <tcpm@ietfa.amsl.com>; Thu, 27 Sep 2018 09:35:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.455
X-Spam-Level:
X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.456, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 rGS6oI6TG14A for <tcpm@ietfa.amsl.com>; Thu, 27 Sep 2018 09:35:23 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::711]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59546130EB5 for <tcpm@ietf.org>; Thu, 27 Sep 2018 09:35:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=48RmyuPsblGg1IGueIdMzpCOED28BVaADGoDVaaDvpI=; b=bWjMe/jN1o4GjvnLe+lgw7EWHbXsqqzA9SQN0dolUGcnZ2KPcicwvGnxfjivSqDqh67V5+1QPb7NYrEjp9CY7Lsw4BFUWXqwhIhAc4h0Y/MAyROZR6u3IlOBNK1YzchtWE2Dtn7ewB+PKxaLiiu7x9nfBR5t24AnldWXzgQpxVI=
Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0702.namprd21.prod.outlook.com (10.175.142.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.2; Thu, 27 Sep 2018 16:35:20 +0000
Received: from MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f]) by MWHPR21MB0191.namprd21.prod.outlook.com ([fe80::5443:2f41:bcd:634f%5]) with mapi id 15.20.1207.011; Thu, 27 Sep 2018 16:35:20 +0000
From: Praveen Balasubramanian <pravb@microsoft.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] usage for timestamp options in the wild
Thread-Index: AQHUVcFDBUenX6MW2Ui5madIUzPkvaUC3v1AgAAZMYCAAAwkYIAAeMKAgADUONA=
Date: Thu, 27 Sep 2018 16:35:20 +0000
Message-ID: <MWHPR21MB0191F84789FF05409B43CE24B6140@MWHPR21MB0191.namprd21.prod.outlook.com>
References: <CAO249yd-3PBzjtO+Jgpz-qDTROgoKJEQetJTxiepJ34LPqZG+w@mail.gmail.com> <MWHPR21MB019123F8820BE88FEAA2A9FBB6150@MWHPR21MB0191.namprd21.prod.outlook.com> <CAO249ydsiYpurTinJE+KR1G0v6Letpr_8jsudSdxdquR_DXisQ@mail.gmail.com> <MWHPR21MB01913A2B05C037E594F78CBAB6150@MWHPR21MB0191.namprd21.prod.outlook.com> <CAO249ye1YtMV-fj+dqvcwZFHNOkjAcB=224JCQaoWuakGDsuWQ@mail.gmail.com>
In-Reply-To: <CAO249ye1YtMV-fj+dqvcwZFHNOkjAcB=224JCQaoWuakGDsuWQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [2001:4898:80e8:9:51a5:baf2:9712:df79]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0702; 6:S+JCIvq8+1U0qoC83jAb2qdFG+YccB+vOofNGKz1uCSVaJEp+EPi8CDhF5LepbzyAhhfv+6QYfK9MZm7yBEjVme1/Rj2RIwjXgGpUMMa6NYXPPyjo1ITiXyBMQEaRFJLgc9AeMC9Uzkmiw8RiSJlTBfKlPBh6OULWllVI5i6AXLvOP3W4BLTCKEx62T3slRNkOoni2lspj3D3J8Xe8OX5pAhQObmJaA3mtAgWYGMva6q4FoG/3suMDbq5FJBDrym/JTfuNMwogmcqNk0GV2GKzm5EkiG7HkZXIaFgr+j8+sHE8zPHyeqUiHt+Vf4EunqtVfZRnhHvDSERb26Pm4pn/23sXSyJ5q90XnrJ70Y9OISguidRL6AL/GJVNxD31C/gUziwZzsqVZCzD81i+t2E5kWuN3eA4DG+7ZXgDgVGlcRO88TjR5FxylsTDBSpjFD61maEfNkv8STA5GV0h2RYw==; 5:64UAhDSGGwDUioAiKawiJyEQCPkj9LgbI0zAVuQxGpeh7X0r5/fvOL6CB19LPnuYK8HJwSYCWFrR+2R1T+p4SapRy7cbnnGhZLrTZcT4LNPc9lgTS0crH4/6xyCrHfgYactcOsAXajNY2+pwwEh7z6LL399XnNC3pnT7mXjNMOE=; 7:wehTylgkZwno69xV/e2+h3TbIHpMasTSjjKBWeuwlrMZxOxLbNcba4FUN6mDk1vOmZIHrbpg0E2N+2cfXD3CEKZDDFkzsFwe4bVOL0domAtYsDYQDRLjPvuKZbQ8rKYItgfdvS/egBLnlKOaMhuaCATSAe9XC/mO+9ybk1HaMQ2gpE/6q1F391D+U++v6MLTZ7UE7pW+DduhBZu7URHiZe+WBTANlb6b/kQjvOBzJBSSRc6ysJJm7N2jsu1afNHf
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: e4783c8d-bd84-44d5-2a85-08d62497370f
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534165)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(4618075)(2017052603328)(7193020); SRVR:MWHPR21MB0702;
x-ms-traffictypediagnostic: MWHPR21MB0702:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <MWHPR21MB0702BC0D049F6BB1329296B2B6140@MWHPR21MB0702.namprd21.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155)(190501279198761)(227612066756510)(219752817060721)(189930954265078);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231355)(944501410)(52105095)(2018427008)(93006095)(93001095)(10201501046)(3002001)(6055026)(149066)(150057)(6041310)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(20161123562045)(201708071742011)(7699051)(76991041); SRVR:MWHPR21MB0702; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0702;
x-forefront-prvs: 0808323E97
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(376002)(346002)(396003)(366004)(199004)(189003)(53936002)(46003)(186003)(8936002)(8676002)(81166006)(81156014)(68736007)(486006)(11346002)(446003)(476003)(86362001)(86612001)(8990500004)(4326008)(6246003)(19609705001)(55016002)(9686003)(54896002)(33656002)(236005)(7736002)(790700001)(6116002)(74316002)(6436002)(229853002)(2906002)(6306002)(97736004)(93886005)(316002)(2900100001)(22452003)(71190400001)(71200400001)(102836004)(25786009)(606006)(10290500003)(7696005)(105586002)(76176011)(5660300001)(106356001)(53546011)(14454004)(10090500001)(99286004)(256004)(14444005)(6916009)(6506007)(34290500001)(5250100002)(508600001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0702; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: P+IPpza1qjcRX0/nfgwokaQCYXJBnMzuyaCGWVgBwbZHkHOGjsncy9mEJcasXdLqdQ+3pPnYgQ0n9Pdg8YmQ80V0yLNZI9bmCFm+nXBM/RXTBEDjHSw2yakG/jFMe5Y4CFtsoMQkw4K85C50mnCJqDmYb6eUWsakPfL4SUpWyJFmM4IwBCA7iTjnVwHXiH2VdChlGPF1vJU3xyrZHNEd3FwAPJF7k7Si2tKryaUMTczZnB+6uKJHRNP1I5Q8oQQN2X6P8G4myVwoqqsJaJy+PIE/LLE+ajkQ7qPitGGsJ3VIWUDULnHz3+B9IPcz/OMcboRzmSDAHWC/FRhPUcKEVOJ77QxGyWdTQjppujJPUn4=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0191F84789FF05409B43CE24B6140MWHPR21MB0191namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e4783c8d-bd84-44d5-2a85-08d62497370f
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Sep 2018 16:35:20.0656 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0702
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/4mVu9P0eYvItCuCv1iAGj0pxakc>
Subject: Re: [tcpm] usage for timestamp options in the wild
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Sep 2018 16:35:27 -0000

For just computing RTO, once per RTT is sufficient. Based on lab measurements, any delay based algorithms like HyStart or delay based congestion control all work better if more RTT samples are taken throughout the RTT. RACK requires send timestamps and with that infrastructure in place it is easier to compute more RTT samples per RTT.

It's certainly a worthwhile A/B/C experiment to compare accuracy of RTT using timestamps, one sample per RTT, and multiple samples (N) spread across the RTT. Windows has a constant N today to minimize memory and CPU usage. If anyone has any data on this, please share.

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Sent: Wednesday, September 26, 2018 8:44 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>jp>; tcpm@ietf.org
Subject: Re: [tcpm] usage for timestamp options in the wild

Hi Praveen,
Sorry, I was not clear enough... I was interested in how windows samples RTT.

I mean, I am interesting in knowing if the conventional once per RTT samplings can archive sufficient results
or recording the transmission time of sending packets like RACK can compensate the lack of TS options.
--
Yoshi

On Wed, Sep 26, 2018 at 1:36 PM, Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>> wrote:
It follows RFC 6298 and RTO is based on SRtt and RttVar. RTT sample measurement will make use of timestamps when present or just use ACK arrival time. As a side result of RACK implementation, the number of RTT samples taken per RTT was increased. See Section 2 and 3 in RFC 6298.

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>>
Sent: Wednesday, September 26, 2018 12:48 PM
To: Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp<mailto:nishida@sfc.wide.ad.jp>>; tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: Re: [tcpm] usage for timestamp options in the wild

Hi Praveen,

On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian <pravb@microsoft.com<mailto:pravb@microsoft.com>> wrote:
Windows doesn’t do timestamp option by default. It’s 10 byte per packet overhead for marginal benefits.

Interesting. So, windows derives RTO only from ACK arrival time?
--
Yoshi


From: tcpm <tcpm-bounces@ietf.org<mailto:tcpm-bounces@ietf.org>> On Behalf Of Yoshifumi Nishida
Sent: Wednesday, September 26, 2018 10:49 AM
To: tcpm@ietf.org<mailto:tcpm@ietf.org>
Subject: [tcpm] usage for timestamp options in the wild

Hello,
this is just out of my curiosity.
I've checked traffic archives in CAIDA (https://data.caida.org/datasets/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata.caida.org%2Fdatasets%2F&data=02%7C01%7Cpravb%40microsoft.com%7Cecf887b1e89041da30e008d624703d0d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636736461848296751&sdata=OffGwYFhj%2FwqTbsT7P7%2BaYi88WtT5ne1MI6k79unxTQ%3D&reserved=0>) and WIDE (http://mawi.wide..ad.jp/mawi/<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmawi.wide.ad.jp%2Fmawi%2F&data=02%7C01%7Cpravb%40microsoft.com%7Cecf887b1e89041da30e008d624703d0d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636736461848296751&sdata=Q1M0qVe7u%2B%2F40spn2%2B746Ir7WUGllyLiIr2tBtNFwhU%3D&reserved=0>) on a whim and tried to see how many connections utilize timestamps.

As far as I've checked some archives recently captured, it seems that around 60-70% TCP connections use timestamp option. But, this ratio seems to be a bit lower as I thought most of implementations these days support TS option and activate it by default.
Does anyone have some ideas about it? Am I looking at uncommon data? Or there are still many old implementations around? Or, many users have disabled the option for some reasons?
--
Yoshi