Re: [multipathtcp] Options or Payload?

["SCHARF, Michael" <[e-mail]>]

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.

Michael