IETF Logo Mail Archive

Re: [multipathtcp] Timestamp option for Multipath TCP

"Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com> Wed, 29 March 2017 11:12 UTC

Return-Path: <michael.scharf@nokia.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6801296A4 for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 04:12:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Level:
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: 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 TK_3-R1p8HxM for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 04:12:13 -0700 (PDT)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0108.outbound.protection.outlook.com [104.47.1.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E566E12969C for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 04:12:12 -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; bh=IIkj+lsBwTVm9ONIjtkgF+IEYb//BOCmg3JyS1LLa2U=; b=Oa9KpV09cBaFY4uesYQhN+zaGrJQ9z/TUSHuLaPk6YV7xtuybQmfESt0C0eiLxMo0LF/8cjdtwBNnsIs+bDi98N0yHM02M47FannAPHxDzaH/rEocJZqIcO3k3VI/JVYQl/zmIHJwZI3HAkQqMK1vNBFvn6eQZa165hwGz/nw4I=
Received: from AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) by AM5PR0701MB2547.eurprd07.prod.outlook.com (10.173.92.15) 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 AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) by AM5PR0701MB2547.eurprd07.prod.outlook.com ([10.173.92.15]) with mapi id 15.01.1005.010; Wed, 29 Mar 2017 11:12:10 +0000
From: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>
To: Alan Ford <alan.ford@gmail.com>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Timestamp option for Multipath TCP
Thread-Index: AQHSo+KLIDVa3V37o0atHORTYNcOlKGrLfiAgACDzEA=
Date: Wed, 29 Mar 2017 11:12:10 +0000
Message-ID: <AM5PR0701MB2547B76C59F7874285B22C8193350@AM5PR0701MB2547.eurprd07.prod.outlook.com>
References: <c030efb2-5a1f-9ec9-a214-c302ebfb151f@uclouvain.be> <CAOs_kTYJREt0CxgAV0Jqa+4+mzsgKjRZ2TVKTJOVh8pZDpJvpg@mail.gmail.com>
In-Reply-To: <CAOs_kTYJREt0CxgAV0Jqa+4+mzsgKjRZ2TVKTJOVh8pZDpJvpg@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia.com;
x-originating-ip: [12.205.206.2]
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: <AM5PR0701MB25472E3C115E70D1D779765793350@AM5PR0701MB2547.eurprd07.prod.outlook.com>
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; H:AM5PR0701MB2547.eurprd07.prod.outlook.com; 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-OriginatorOrg: nokia.com
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Bj55xN-jeWAY-wFX8Z2d5fdK31o>
Subject: Re: [multipathtcp] Timestamp option for Multipath TCP
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=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.

Michael


From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Alan Ford
Sent: Mittwoch, 29. März 2017 05:17
To: Olivier.Bonaventure@uclouvain.be; multipathtcp <multipathtcp@ietf.org>
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.

Regards,
Alan

On Thu, 23 Mar 2017 at 09:34, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>> wrote:
Hello,


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 ?


Thanks



Olivier

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
https://www.ietf.org/mailman/listinfo/multipathtcp

v2.23.0 | Report a Bug | By Email