Re: [tcpm] Multipath TCP signaling

["Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[e-mail]>]

This is an interesting question.

My initial response would be to definitely use the options
approach.  I could be completely wrong, but my memory is
that middleboxes weren't filtering new options very
aggressively in the studies that have been done with tbit
and other tools, plus (as you noted) you have to use new
options anyways to signal the multipath capability.

For the question of options reliability, I've seen a
project in the past that essentially ran TCP within the
TCP options space, by setting a few bits of the option
to represent options-sequence numbers and options-ack
numbers (since the data-rate of the options stream is
lower, the number of bits needed is reduced from the
size of these fields in the normal TCP header).  I don't
know if that would work well here or not, but it would
be food for thought at least.

--
Wes Eddy
MTI Systems


>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Costin Raiciu
>Sent: Wednesday, February 24, 2010 5:28 AM
>To: [e-mail]
>Subject: [tcpm] Multipath TCP signaling
>
>Hi,
>
>In the multipath TCP working group we are trying to decide which is the
>best way to signal multipath specific information between endpoints. We
>are writing this message to invite contributions and thoughts from
>members of the tcpm list, as we believe that whatever solution we choose
>will impact other tcp signaling in the future.
>
>Let me briefly tell you what we are trying to do.
>
>Multipath works by assigning a data level sequence number to application
>data, and sending this data over different "subflows" which look like
>tcp over the wire. These subflows have their own sequence numbers too,
>on top of the data sequence number.
>
>The information multipath needs to get across is:
>- multipath enabled / join connection - this is only on flow/subflow
>startup
>- data sequence number (each segment must have this to enable the
>receiver to reorder data)
>- add/remove ip to connection (not often)
>- security negotiation, if needed
>- subflow policy, etc.
>
>We have analyzed the requirements of this control information (e.g.
>reliable, in order) and two basic ways of signaling it:
>- using TCP options - this is the traditional TCP way of signaling
>control information; it is unreliable and the space is limited, it will
>be a bit difficult to get it through existing middleboxes, but it plays
>nice with future "multipath aware" middleboxes.
>- using the payload - this would use TLV like encoding (as in tls) and
>does not have space issues. However, all the control info is now
>ordered, congestion controlled and reliably sent - which may not be what
>we want. This will get through more middleboxes today, but it is not
>nice to future middleboxes: they have to keep state to be able to parse
>the control info. Also, the middleboxes cannot easily add control info
>(this is contentious, I know, but should be possible).
>
>The detailed analysis is in the following doc:
>http://www.cs.ucl.ac.uk/staff/C.Raiciu/files/options_vs_payload.pdf
>
>What do people think is the best approach?
>Costin
>_______________________________________________
>tcpm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tcpm