[multipathtcp] Options or Payload?

"Ford, Alan" <alan.ford@roke.co.uk> Tue, 10 November 2009 00:58 UTC

Return-Path: <alan.ford@roke.co.uk>
X-Original-To: multipathtcp@core3.amsl.com
Delivered-To: multipathtcp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B883A69DE for <multipathtcp@core3.amsl.com>; Mon, 9 Nov 2009 16:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.465
X-Spam-Level:
X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2PI1AixWWev for <multipathtcp@core3.amsl.com>; Mon, 9 Nov 2009 16:58:21 -0800 (PST)
Received: from rsys002x.roke.co.uk (rsys002x.roke.co.uk [193.118.201.109]) by core3.amsl.com (Postfix) with ESMTP id 3BBB03A6959 for <multipathtcp@ietf.org>; Mon, 9 Nov 2009 16:58:21 -0800 (PST)
Received: from rsys005a.comm.ad.roke.co.uk ([193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id nAA0wfLM028720 for <multipathtcp@ietf.org>; Tue, 10 Nov 2009 00:58:41 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
x-cr-hashedpuzzle: AFDK BIMM Bq1V CfPX Cmad C4Ji Dz0u D1I3 EMFk FLYA Fb1W FvAe F7iW GR48 GyrJ G426; 1; bQB1AGwAdABpAHAAYQB0AGgAdABjAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {3C708A4D-9708-4BDE-8384-338C3C6B187F}; YQBsAGEAbgAuAGYAbwByAGQAQAByAG8AawBlAC4AYwBvAC4AdQBrAA==; Tue, 10 Nov 2009 00:58:48 GMT; TwBwAHQAaQBvAG4AcwAgAG8AcgAgAFAAYQB5AGwAbwBhAGQAPwA=
x-cr-puzzleid: {3C708A4D-9708-4BDE-8384-338C3C6B187F}
Content-class: urn:content-classes:message
Date: Tue, 10 Nov 2009 00:58:48 -0000
Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Options or Payload?
Thread-Index: AcphoPYqM13XFcsoT3yDBuE0UMQEPw==
From: "Ford, Alan" <alan.ford@roke.co.uk>
To: <multipathtcp@ietf.org>
X-roke-co-uk-MailScanner-ID: nAA0wfLM028720
X-roke-co-uk-MailScanner: Found to be clean
X-roke-co-uk-MailScanner-SpamCheck:
X-roke-co-uk-MailScanner-From: alan.ford@roke.co.uk
Subject: [multipathtcp] Options or Payload?
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Tue, 10 Nov 2009 00:58:22 -0000

Hi all,

One of the big issues to be raised during yesterday's MPTCP session was
the question of whether TCP Options are really the right place to be
doing this. This is not the first time this has come up but deserves
further exploration.

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

On the downside, there may be cases where this could confuse
middleboxes, e.g. expecting HTTP on port 80 and finding this kind of
data instead. However, since a TCP option would be used at the start to
identify capability, if this were dropped by a middlebox/proxy then
MPTCP would not be used.

What do people think is the best approach?

Regards,
Alan