Re: [multipathtcp] Options or Payload?

We had considered that, however the main reason against this was whether
certain middleboxes would split and coalesce TCP payloads thus breaking
the placement of the extended options - the TCP payload is essentially
no longer a continuous stream.

Wes Eddy proposed a "Long Options Option"
(http://tools.ietf.org/id/draft-eddy-tcp-loo-04.txt) which seemed to be
a possible way of doing a very similar thing, by negotiating to ensure
that long options would work along a path. Although, this draft is now
expired, and I'm not sure why it was dropped. Anyone know?

Regards,
Alan

> -----Original Message-----
> From: Yoshifumi Nishida [mailto:nishida@sfc.wide.ad.jp]
> Sent: 10 November 2009 01:35
> To: Ford, Alan
> Cc: multipathtcp@ietf.org
> Subject: Re: [multipathtcp] Options or Payload?
> 
> 
> Hello,
> How about having a simple option which indicates the offset for real
tcp
> payload?
> For example, if mptcp packets conveys 10 bytes control info in the
payload,
> set
> offset to 10 in the option.
> 
> Thanks,
> --
> Yoshifumi Nishida
> nishida@sfc.wide.ad.jp
> 
> From: "Ford, Alan" <alan.ford@roke.co.uk>
> Subject: [multipathtcp] Options or Payload?
> Date: Tue, 10 Nov 2009 00:58:48 -0000
> Message-ID:
> <2181C5F19DD0254692452BFF3EAF1D6808D7BB51@rsys005a.comm.ad.roke.co.uk>
> 
>  > 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 mailing list
>  > multipathtcp@ietf.org
>  > https://www.ietf.org/mailman/listinfo/multipathtcp