[multipathtcp] Options or Payload?

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

MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Date: Tue, 10 Nov 2009 00:58:48 -0000
Message-ID: <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>
Thread-Topic: Options or Payload?
Thread-Index: AcphoPYqM13XFcsoT3yDBuE0UMQEPw==
From: "Ford, Alan" <alan.ford@roke.co.uk>
To: multipathtcp@ietf.org
Subject: [multipathtcp] Options or Payload?
Precedence: list

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

[multipathtcp] Options or Payload? Ford, Alan
Re: [multipathtcp] Options or Payload? Yoshifumi Nishida
Re: [multipathtcp] Options or Payload? Ford, Alan
Re: [multipathtcp] Options or Payload? Joe Touch
Re: [multipathtcp] Options or Payload? William Herrin
Re: [multipathtcp] Options or Payload? SCHARF, Michael
Re: [multipathtcp] Options or Payload? Joe Touch
[multipathtcp] Options or Payload: pros and cons Costin Raiciu
Re: [multipathtcp] Options or Payload: pros and c… SCHARF, Michael
Re: [multipathtcp] Options or Payload: pros and c… Costin Raiciu
Re: [multipathtcp] Options or Payload: pros and c… Costin Raiciu