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