Re: [multipathtcp] Timestamp option for Multipath TCP

Alan Ford <> Tue, 04 April 2017 22:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93FD61293DA for <>; Tue, 4 Apr 2017 15:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 R_GxEDSJpTxB for <>; Tue, 4 Apr 2017 15:25:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c0c::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0FD46126E01 for <>; Tue, 4 Apr 2017 15:25:00 -0700 (PDT)
Received: by with SMTP id t20so20512481wra.1 for <>; Tue, 04 Apr 2017 15:24:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y8S2EKTsYVCdaIfuTx+0MdE+UMdSFiA1Ug/nmFqFjc4=; b=jInJivaP+XFN/Se87AbJUieaUY6fxxfXeTNUVgmcy4FLc45ov0o9pzWdHqvdZZS8El meFc0/vcqR5jpYQqPvvSbQiNqye1I4q64rOt7y9wziNfhZS2zkQ1NzRWs2zeWPTxEDBA JnThNoHAAZ6aAZ7Zvvsi5UA6pJq/WzfjbAgOED3h3q455sUzdey/SFbgg4Y7lMU7a3sl NVTRiHpOWZ4zhWZHvE1YhmtKtIpHdpyJhTL4yxdPUb6mFjVQfQVV7uD8L4xfnfNnCu33 kOqknKTLQnHjhY8C8he+QedCxmxrGFjK/bprnlJ027s1tO6UACud8LZXw9yl6ze4VMIs ok2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y8S2EKTsYVCdaIfuTx+0MdE+UMdSFiA1Ug/nmFqFjc4=; b=loPRDLBbKXwrlE2I9AiSvS5h4fC/zbUBm2exAhazSy+sjFUWS/t++pr+b9tAhPDhno uaaX6NLsB53zD+9XRwW80sVLB3Ut93SLNHnlp5zahz3rzTeJIf1M+ZYkeWRLafl861M3 v6WaBjNtaK9rk+WR6Ldvme4InMOBwblar0tX0o34ffhvi8pEOo3CH4uoZuRapJJqdBkM 6rSbHkdog6f2RCe5zxCsqTeowwvRomVDe87rzxN5l71qn51V2aOlRLEIrh9Jve7Bfsat J4iHn4cbW/csVm171GM1rQX7CrUvPtqLjrSamSMWqQtnEhAJBYormgWAVU5PQ9TEjtxN ms5w==
X-Gm-Message-State: AFeK/H0b+2psN6BiPBhMBtVw3l8Xl5aHDw+QalJeTA+Dzp1eu2nAmDFqZOaAbbsi93oN8w==
X-Received: by with SMTP id r74mr80988wrb.6.1491344698585; Tue, 04 Apr 2017 15:24:58 -0700 (PDT)
Received: from alans-mbp.lan ([]) by with ESMTPSA id v108sm23795936wrc.41.2017. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 15:24:57 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Tue, 4 Apr 2017 23:24:57 +0100
Cc: Olivier Bonaventure <>, multipathtcp <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Christoph Paasch <>
X-Mailer: Apple Mail (2.3124)
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: Tue, 04 Apr 2017 22:25:07 -0000

Hi Olivier,

Following up from IETF98 here, could you clarify what docs changes would be required for your proposals here to be applied, both in terms of 6824bis, and for any references (e.g. 7323)?


> On 29 Mar 2017, at 16:14, Christoph Paasch <> wrote:
> 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
> _______________________________________________
> multipathtcp mailing list