Re: [multipathtcp] Timestamp option for Multipath TCP

Christoph Paasch <> Wed, 29 March 2017 15:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 603F212955D for <>; Wed, 29 Mar 2017 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4855ySrHHU-6 for <>; Wed, 29 Mar 2017 08:14:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 87576127599 for <>; Wed, 29 Mar 2017 08:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailout2048s; c=relaxed/simple; q=dns/txt;; t=1490800497; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=qr5/UM4v/Un7nixTusJ7RY+4oxj++XSz09B15zd1KM4=; b=owUyMzQipD1m4crvIh9/6RLU2E9U4EZU8lklIL4zj4p/9L/PiokL3pqPLx0G5dfM qSQHfCFPa1nhLAZ4TcrHWfrR1BL+bbPjPCVlTxZPT0rhbe1cFnrHYrj8Iks+rYxf yVAUf40beNLUtSj7LNbXaAmYFI54l7M2ehOUffhSgTXKG2v6simbn3h4TyPM+JO8 hFSlYfg0RDwNd2Gipljrjchvi8T26U5rtFTaGrcFWMEsY87vi9IYJG6nE5M80Od0 aOJ2LEUXTg3FUfGZrrkit3cwzqWaT9kXhBqGvMY8aIe860m7T21FthgJee+uMPWW je2FhRPN+6s9pYYhznYDOw==;
Received: from ( []) by (Apple Secure Mail Relay) with SMTP id 92.48.09505.17FCBD85; Wed, 29 Mar 2017 08:14:57 -0700 (PDT)
X-AuditID: 11ab0219-dc2b19a000002521-ab-58dbcf71ae72
Received: from ( []) by (Apple SCV relay) with SMTP id C8.31.23309.17FCBD85; Wed, 29 Mar 2017 11:14:57 -0400 (EDT)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; CHARSET=US-ASCII
Received: from localhost ([]) by (Oracle Communications Messaging Server 64bit (built Feb 10 2017)) with ESMTPSA id <>; Wed, 29 Mar 2017 08:14:57 -0700 (PDT)
Date: Wed, 29 Mar 2017 10:14:56 -0500
From: Christoph Paasch <>
To: Olivier Bonaventure <>
Cc: multipathtcp <>
Message-id: <>
References: <>
In-reply-to: <>
User-Agent: Mutt/1.7.1 (2016-10-04)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUiuLohXbfw/O0Ig/UXjSw+r77OZnGj4QeL A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJVx/elHtoLbAhU9O+cyNjAu5u1i5OSQEDCR 2LFyAmsXIxeHkMBBRonOTf/YYRJ3jl5nhkicZZRY/LeRGSTBKyAo8WPyPZYuRg4OZgF5iYPn ZUHCzALSEo/+zmCHsLUkvj9qZYHobWKSaNpwgAkkISwgKdF95w4zSC+LgKrE9CfVIGE2oPq3 t9tZQWwRASuJU6enQ83RkLj+sJkNotVO4ummT2wQJ9hJ/PlwkQlkjJCAvcSikzwgYU4BB4mu NyvBxogKKEv8PXwP7AQJgSlsEn1rnjNPYBSZheSDWQgfzELywSwkHyxgZFnFKJybmJmjm5ln ZKqXWFCQk6qXnJ+7iREcCUySOxi/vjY8xCjAwajEw6uw+naEEGtiWXFl7iFGaQ4WJXHefftu RQgJpCeWpGanphakFsUXleakFh9iZOLglGpgXL/x4cuSqAK/02YSnVw3GX0fKH0x400QiFXq TKuMCU9ofXaOxe79pqPPrkuHKK7zLp5VvUxHbaLkS8Z9yhvzXjceernYyfNL+W2B8oDHdWZ1 H7Q+eU7fYJnT9yv/9Jmcx4t5OoLfSpocCH9no7t+s73lg01aNQUZ5cuydn34/PFpx97zuiu9 lFiKMxINtZiLihMBfHlUa2UCAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUiuLqBVbfw/O0Ig8l79Cw+r77OZnGj4QeL A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJVx/elHtoLbAhU9O+cyNjAu5u1i5OSQEDCR uHP0OnMXIxeHkMBZRonFfxuZQRK8AoISPybfY+li5OBgFpCXOHheFiTMLCAt8ejvDHYIW0vi +6NWFojeJiaJpg0HmEASwgKSEt137jCD9LIIqEpMf1INEmYDqn97u50VxBYRsJI4dXo61BwN iesPm9kgWu0knm76xAZxgp3Enw8XmUDGCAnYSyw6yQMS5hRwkOh6sxJsjKiAssTfw/dYJjAK zkJy9CyEo2chOXoWkqMXMLKsYhQsSs1JrDQy0kssKMhJ1UvOz93ECAnc9B2MR26aHWIU4GBU 4uGtWHs7Qog1say4MvcQowQHs5IIr9spoBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHevfZAKYH0 xJLU7NTUgtQimCwTB6dUA6OKt0zks2vXjsy2v7r4678FalyPYqavtN1YwOAwf0tDR6SSoMnM jxkXf76fKhfP8JxjU2H8Yo5FC1tesqUvnbNlXZkb08nLn+6Gf5GrYb93S7Nzz6VnaovPXEis MGPIYtjK2iQhXVL7Xe9kY/aXi09bv8as+7L748EI/XMSz57fzZ6qtcdnwtpYJZbijERDLeai 4kQAm3cy7lgCAAA=
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 15:15:00 -0000

Hello Olivier,

On 23/03/17 - 15:33:57, 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

if we do this, how would MPTCP decide whether or not to put a TS-option in
the segment? And will this decision-process still allow to be fully protected
against PAWS (when TSO-is used and the DSS-option does not end up on every

I can't think of a way to achieve this, because whenever we would decide to not put
a TS-option, later on after 2^32-bytes this original data might be subject
to being the "victim" of PAWS, even if we then switch into a mode where we
use TS.

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

I like this approach, because it seems to me to consume less option-space.

How would this timestamp look like in the DSS-option? Would it still be 32-bits?
I think we can make it less than 32-bits, right?