Re: [tcpm] Multipath TCP signaling

Will this have any effect on covert chanels?

hal wigoda
chicago
student, depaul university

On Mar 22, 2010, at 1:48 AM, Yoshifumi Nishida wrote:

> 
> 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 <c.raiciu@cs.ucl.ac.uk>
> Subject: [tcpm] Multipath TCP signaling
> Date: Wed, 24 Feb 2010 11:27:41 +0100
> Message-ID: <DDA0E1E9-E5EE-4623-9928-1BC3B8529A78@cs.ucl.ac.uk>
> 
>> 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
>> tcpm@ietf.org
>> https://www.ietf.org/mailman/listinfo/tcpm
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm