Subject: Re: [tcpm] Multipath TCP signaling

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 2 Mar 2010 12:23:48 -0600

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: [email-masked] [mailto:[email-masked]] On Behalf Of
>Costin Raiciu
>Sent: Wednesday, February 24, 2010 5:28 AM
>To: [email-masked]
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 22 Mar 2010 15:48:33 +0900 (JST)

Dear all,

As Costin wrote in his mail, in multipath TCP working group, we are discussing
signaling method for multipath TCP. On Tuesday, we're going to talk about this
topic and see if we can reach consensue. We really appreciate if tcp experts
give valuable feedbacks on this.
Please come to California C at 15:20. It's right after tcpm meeting!

Thanks,
--
Phil and Yoshifumi

From: Costin Raiciu <[email-masked]>
Subject: [tcpm] Multipath TCP signaling
Date: Wed, 24 Feb 2010 11:27:41 +0100
Message-ID: <[email-masked]>

 > 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.
 > 
 > 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. 
 > 
 > - 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)
 > 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
 >

---

From: Hal Wigoda <[email-masked]>
Date: Mon, 22 Mar 2010 02:52:18 -0500

Will this have any effect on covert chanels?

hal wigoda
chicago
student, depaul university

---

From: Yoshifumi Nishida <[email-masked]>
Date: Tue, 23 Mar 2010 05:04:57 +0900 (JST)

Hi Hal,

All I can say now is we're going to discuss what is the best 
way to signal multipath TCP information to its peer on Tuesday.
Also, the WG welcomes new insights and ideas. I think there are
lots of rooms to bring your idea in mptcp since it has just started.

Thanks,
--
Yoshifumi Nishida
[email-masked]

From: Hal Wigoda <[email-masked]>
Subject: Re: [tcpm] Multipath TCP signaling
Date: Mon, 22 Mar 2010 02:52:18 -0500
Message-ID: <[email-masked]>