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

Praveen Balasubramanian <pravb@microsoft.com> Wed, 26 September 2018 20:37 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 8F7DC129385 for <tcpm@ietfa.amsl.com>; Wed, 26 Sep 2018 13:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.467
X-Spam-Level:
X-Spam-Status: No, score=-0.467 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 QHFj0HLUHJMl for <tcpm@ietfa.amsl.com>; Wed, 26 Sep 2018 13:37:00 -0700 (PDT)
Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710131.outbound.protection.outlook.com [40.107.71.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB6F6126CC7 for <tcpm@ietf.org>; Wed, 26 Sep 2018 13:36:59 -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=WKBOqnVcz3pMOhptU+anJPriU5O+AZ+P0X7sLYFeams=; b=o0yqtJ9rolFbpQz6lbpZJUzFljFQSpTMHv8jWsjwq4qDq/VZmFaQO5cz2X3T7yBKKcTyikwNer2oJ4+41nsHbSybY4tOzVoEP/VFERfKOIM3f4iqzYhrKuG/mjrYJUiXjYFa4yXsiZ3/Z1PtUTEQT+TNzDs03+wudqMi63nqPO4=
Received: from MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) by MWHPR21MB0510.namprd21.prod.outlook.com (10.172.95.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1207.2; Wed, 26 Sep 2018 20:36:58 +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.006; Wed, 26 Sep 2018 20:36:58 +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: AQHUVcFDBUenX6MW2Ui5madIUzPkvaUC3v1AgAAZMYCAAAwkYA==
Date: Wed, 26 Sep 2018 20:36:58 +0000
Message-ID: <MWHPR21MB01913A2B05C037E594F78CBAB6150@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>
In-Reply-To: <CAO249ydsiYpurTinJE+KR1G0v6Letpr_8jsudSdxdquR_DXisQ@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:3:8e1c:417:2114:339b]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; MWHPR21MB0510; 6:iEMovL2sqKavzXgHAsOffvpzcDoOnkabwS5J5emwe0AXP6Qii760sTujchwosmIW47SccbV2dSKvzpMZDFbY13p6fycOcRJu6/VXvKqv7KoqjhcKhmjZIip2Dmr+sc7TBbrKdToU6FwAJHj/GTB2h8dKSrblQ2rEeAuANYhYGW65/UJCKt8b0Z4Rxapf5H/ims3zwSl+kBRFIlLYkBu5Rj2lAVdac/nHpX/1AV+/OjCX2LGsSlwO0HVYLnwWKaMeLCwnJOzlT8SEOCeZTs73DGY72b4Z+jTCgpi29Nv6t9LYhCBmWYJ87jx/aFJPCfMI5t2gdOGzOtMjRryzEGihsQnPFR4Fy0IHU2FDrlHFd1VU9HTP8HlVLYzmH/6swuqj+rXhAoJspOTpD52R3bQOfMN9EDLGlAnQWyrFbB6aQkKZBvJRagJV5CS77HyNJrc+shPxHz9pDUZNODGbLKKiFg==; 5:HCTLvd4th0CpHl0vn2OkLvBSaimxzwbynGNd6AKRjEX1RGHJ548DhBDg4cKTpqsspyTjBhl+83FGmlDc3KWHXwbrY5Wq+ZSaBk09eJLjeDZh6tDFcyCLxtsP0uuyI38Ay9+TR3JWTW12WVKpdiQzQ3iLRPuLaF/5Oddcn/hggfk=; 7:f3VDTAejOcVSRZwRSnEDa5EFrM3QtDOEQlPKjGmXmfM113nWty2eSDfmcdg4vziUwOA3vAcr33c61VURLp0czyWJeMpQA0nKejIDf/gxIzQmRPYlYflxzm6K9Q97xkDQayKSz723ag1JXffsfXm/IkEUi8cH4jp53ykrlA8gavvuUCU3JZ/eVAFltRPI0EjzW2H+oRysx8VNxudqvzzLvaJ/S8Fsz5j1A6URSfvyTddHucfSyKD+ZLmQR0vzbEiq
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 789d5f8c-e6bf-4aa7-746b-08d623efce61
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:MWHPR21MB0510;
x-ms-traffictypediagnostic: MWHPR21MB0510:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com;
x-microsoft-antispam-prvs: <MWHPR21MB0510C368107B50A9EF1CF374B6150@MWHPR21MB0510.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)(93006095)(93001095)(3231355)(944501410)(52105095)(2018427008)(3002001)(10201501046)(6055026)(149066)(150057)(6041310)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(201708071742011)(7699051)(76991041); SRVR:MWHPR21MB0510; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0510;
x-forefront-prvs: 08076ABC99
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(366004)(396003)(136003)(189003)(199004)(71200400001)(71190400001)(7696005)(53936002)(6306002)(34290500001)(9686003)(229853002)(2906002)(55016002)(236005)(46003)(22452003)(99286004)(25786009)(478600001)(10290500003)(5660300001)(7736002)(74316002)(33656002)(54896002)(6436002)(10090500001)(81166006)(11346002)(81156014)(76176011)(446003)(97736004)(19609705001)(105586002)(8990500004)(6116002)(790700001)(4326008)(106356001)(14454004)(6246003)(2900100001)(86612001)(606006)(186003)(476003)(86362001)(8936002)(6916009)(316002)(8676002)(14444005)(53546011)(256004)(68736007)(6506007)(5250100002)(102836004)(486006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0510; H:MWHPR21MB0191.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: n7PNVRIzV2ouupfxP+PccLLK6xvWWc7ZeN/y5JaRr2szpE9MSra7FWb+EVhipgGr4W3wMUev8l71WEkY00NhYqDN8HXYcN0tpbhgQKrPYdghxKybVVtaTNLvmGy8IUSF17YkDQQnE6tjI/qmnzeAetemG6OGt3bfp+JTMH7LFlgygACSL6sg4NopLoDjrf/q2WP6mIOF4XSzRRBIzRtJOv9VFcjYgqjL4m5/DQsrFsbW4/kBTg0gVH/l2hDgDhOYvVW9J2gk/QQsPahy6Yk0Q90xjI6jH17jxfsWZcOxpIxwA2HH7mhiLrONM0/ht1/AFbtMXJLTgsdoo0xvZGWShLotxRmeFnVLgea+EUNznEg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01913A2B05C037E594F78CBAB6150MWHPR21MB0191namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 789d5f8c-e6bf-4aa7-746b-08d623efce61
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2018 20:36:58.4590 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0510
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/F5oH0hnjIDjsVLNdIg_VD5kr-PA>
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: Wed, 26 Sep 2018 20:37:02 -0000

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>
Sent: Wednesday, September 26, 2018 12:48 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,

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%7C27cca6cac8fd49d98f6908d623ee27fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735903152884299&sdata=lMPj3nuM%2FiNU8HBirxJQ6L%2Bg5N5ABT3McVOpVq5ZOW0%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%7C27cca6cac8fd49d98f6908d623ee27fb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636735903152894308&sdata=JE%2Ba6m7ElaS6bU4ITuoLb48ack%2FNfQTjOYkHJp7Ax6A%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