Re: [multipathtcp] Timestamp option for Multipath TCP

"Scharf, Michael (Nokia - DE/Stuttgart)" <> Wed, 29 March 2017 11:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF6801296A4 for <>; Wed, 29 Mar 2017 04:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TK_3-R1p8HxM for <>; Wed, 29 Mar 2017 04:12:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E566E12969C for <>; Wed, 29 Mar 2017 04:12:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IIkj+lsBwTVm9ONIjtkgF+IEYb//BOCmg3JyS1LLa2U=; b=Oa9KpV09cBaFY4uesYQhN+zaGrJQ9z/TUSHuLaPk6YV7xtuybQmfESt0C0eiLxMo0LF/8cjdtwBNnsIs+bDi98N0yHM02M47FannAPHxDzaH/rEocJZqIcO3k3VI/JVYQl/zmIHJwZI3HAkQqMK1vNBFvn6eQZa165hwGz/nw4I=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Wed, 29 Mar 2017 11:12:10 +0000
Received: from ([]) by ([]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 11:12:10 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <>
To: Alan Ford <>, "" <>, multipathtcp <>
Thread-Topic: [multipathtcp] Timestamp option for Multipath TCP
Thread-Index: AQHSo+KLIDVa3V37o0atHORTYNcOlKGrLfiAgACDzEA=
Date: Wed, 29 Mar 2017 11:12:10 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US, de-DE
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2547; 7:Ktg1uvJ1ioZlhDvfNksiP75eGnQ34VIwjvF/4OYjrQ7+aadwdaZ3KDIjcHQI7V0GM7Z2hwCfibPZXQvK0NIHNFJeibyJib6D8rEc9ngDDtKL+kryKlqhAFTqCmzhWZ4FM5aQf0rzjhUlwKbr8htqKqLYsEi5sb5ggR3EEjCWKhdzAmDoIAvynsmsUlNgIA/39RRa4bIjUMfsgj/AhR2G/XJehJjdWMg5b+qJznRV2FBboR+xTlBYiuQKYuwf2JmrQTgQoLUw7HE5XuYLE/SDYFWJXAXGSrW+gSMXifzi5To7YVgCT8xMsXftEEBqWbkWr90FEZyTmRgkUY57ZQC65A==
x-ms-office365-filtering-correlation-id: 7aa3c5bd-0079-458d-0cba-08d4769471fe
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2547;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406075)(20161123558025)(6072148); SRVR:AM5PR0701MB2547; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2547;
x-forefront-prvs: 0261CCEEDF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39860400002)(39400400002)(39850400002)(39450400003)(39410400002)(24454002)(7906003)(7736002)(74316002)(5660300001)(54356999)(8936002)(8676002)(76176999)(81166006)(50986999)(33656002)(66066001)(86362001)(606005)(77096006)(6506006)(6436002)(102836003)(6116002)(790700001)(229853002)(3846002)(7696004)(53936002)(55016002)(99286003)(2950100002)(9686003)(236005)(6306002)(54896002)(38730400002)(3660700001)(39060400002)(6246003)(3280700002)(189998001)(2906002)(2900100001)(25786009)(53546009)(19609705001)(122556002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2547;; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2547B76C59F7874285B22C8193350AM5PR0701MB2547_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2017 11:12:10.4653 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2547
Archived-At: <>
Subject: Re: [multipathtcp] Timestamp option for Multipath TCP
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Mar 2017 11:12:17 -0000

I guess this is well known: Making 7323 more flexible has been discussed multiple times in TCPM because of the TS option space consumption.

BTW, there will be a discussion in TCPM today related to PAWS.


From: multipathtcp [] On Behalf Of Alan Ford
Sent: Mittwoch, 29. März 2017 05:17
To:; multipathtcp <>
Subject: Re: [multipathtcp] Timestamp option for Multipath TCP

Hi Olivier,

Are these really mutually exclusive options? Relaxing the 7323 requirement seems the right thing to do anyway; adding an option is a nice extra for people that need TS for measurements other than PAWS.

But we could in theory put timestamp negotiation in MP_CAPABLE so we define what it means for one end to require timestamps, and then use regular TCP timestamps - no need for it to be a MPTCP option.

Or we could say that MP_CAPABLE + Timestamp = TS required. Then that makes it negotiable; 6824bis would be changing the semantics of the presence of today's TS option.


On Thu, 23 Mar 2017 at 09:34, Olivier Bonaventure <<>> wrote:

The standard timestamp option for TCP is defined in RFC7323. It is
widely implemented and used. It has two main objectives :

- timing measurements
- protection agains wrapped sequence numbers

Given the importance of the second utilisation, RFC7323 has mandated the
presence of a timestamp option in each segment once negotiated in the
three-way handshake. For Multipath TCP, the DSN option already protects
us from PAWS problems and it should not be mandatory to include
timestamps in each packet sent over a Multipath TCP connection. Given
the length of the timestamp and DSN options these two options already
consume a large number of bytes and could limit the number of SACK
blocks that can be placed inside acknowledgements.

I will only be able to attend the Chicago meeting remotely, but I would
like to start a discussion on the utilisation of timestamps by Multipath
TCP on the list. I see two possibilities, but there are possibly more :

1. Ask for a revision of RFC7323 that allows timestamp options to be
optional in packets of Multipath TCP connections

2. Define a new Multipath TCP option to carry timestamps. The
utilisation of this option would be included in Multipath TCP and thus
no option besides MP_CAPABLE would need to be included in the SYN.

Do you have any opinion on these two possibilities ?



multipathtcp mailing list<>