Re: [multipathtcp] Timestamp option for Multipath TCP

Christoph Paasch <cpaasch@apple.com> Wed, 29 March 2017 15:15 UTC

Return-Path: <cpaasch@apple.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 603F212955D for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 08:15:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 4855ySrHHU-6 for <multipathtcp@ietfa.amsl.com>; Wed, 29 Mar 2017 08:14:58 -0700 (PDT)
Received: from mail-in25.apple.com (mail-out25.apple.com [17.171.2.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87576127599 for <multipathtcp@ietf.org>; Wed, 29 Mar 2017 08:14:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; 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 relay22.apple.com (relay22.apple.com [17.171.128.103]) by mail-in25.apple.com (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 ma1-mmpp-sz10.apple.com (st1-02-mail-lb2-v365-snip.apple.com [17.171.128.5]) by relay22.apple.com (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 ([17.168.191.252]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONL00CBI10WKY50@ma1-mmpp-sz10.apple.com>; Wed, 29 Mar 2017 08:14:57 -0700 (PDT)
Sender: cpaasch@apple.com
Date: Wed, 29 Mar 2017 10:14:56 -0500
From: Christoph Paasch <cpaasch@apple.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Cc: multipathtcp <multipathtcp@ietf.org>
Message-id: <20170329151456.GE2779@dhcp-8507.meeting.ietf.org>
References: <c030efb2-5a1f-9ec9-a214-c302ebfb151f@uclouvain.be>
In-reply-to: <c030efb2-5a1f-9ec9-a214-c302ebfb151f@uclouvain.be>
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: <https://mailarchive.ietf.org/arch/msg/multipathtcp/6H4yauLASKiXG3Tv2QLLxwn8phs>
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 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
segment)?

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?


Christoph