Re: [multipathtcp] Options or Payload?

"SCHARF, Michael" <> Tue, 10 November 2009 02:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 072B23A681B for <>; Mon, 9 Nov 2009 18:48:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hIYCnW-Roakp for <>; Mon, 9 Nov 2009 18:48:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EB0B73A6405 for <>; Mon, 9 Nov 2009 18:48:31 -0800 (PST)
Received: from ( []) by (8.13.8/8.13.8/ICT) with ESMTP id nAA2mtv9015558; Tue, 10 Nov 2009 03:48:55 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Nov 2009 03:48:53 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [multipathtcp] Options or Payload?
Thread-Index: AcphoPYqM13XFcsoT3yDBuE0UMQEPwADQ09A
References: <>
From: "SCHARF, Michael" <>
To: "Ford, Alan" <>, <>
X-Scanned-By: MIMEDefang 2.57 on
Subject: Re: [multipathtcp] Options or Payload?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 10 Nov 2009 02:48:33 -0000

Hi all,

> Specifically, instead of doing this with TCP Options, the 
> same instructions could be included in the payload. Similar 
> to TLS, the data could be chunked and each chunk has a data 
> sequence and length header.
> These can be interspersed with control blocks to signal 
> addresses, security of joining subflows to connections, and 
> connection close. A simple 2-octet TCP option would still be 
> used in the initial SYN to signal MPTCP capability.
> This has the benefit that it would allow the signalling to 
> have reliability, and we wouldn't be hit with option space 
> limits, and thus be potentially able to do better security 
> algorithms. It would also give us greater freedom in signals 
> for future extensibility (for example, if we wanted to signal 
> ports for additional subflows, not just addresses).

Maybe there is a further advantage: I could imagine that payload chunks
could simplify the MPTCP stack design. Sporadically adding TCP options
other than SACK could result a mess in a real stack (correct MSS
calculation, dealing with segmentation offloading, etc.). At least I
recall that we had such problems in our Quick-Start TCP implementation
in Linux.