Re: [multipathtcp] High-level design decisions /architecture

[Yoshifumi Nishida <[e-mail]>]

Hello Alan, 
Thanks for your comments. 

From: "Ford, Alan" <[e-mail]>
Subject: RE: [multipathtcp] High-level design decisions /architecture
Date: Tue, 3 Nov 2009 22:12:22 -0000
Message-ID: <[e-mail]>

 > > Then, we might need to update Add Address option in the draft to
 > propagate
 > > port number.
 > > and the term Address ID might be a bit confusing.
 > 
 > I don't see that we do. The general principle is that an endpoint should
 > use the ports that are currently in use at the other endpoint on its new
 > connections, to maximise getting through firewalls and middleboxes, and
 > also to support any port-based QoS traffic engineering, etc. That
 > doesn't preclude an endpoint from trying other port numbers with the
 > same token, but the chances of that working would seem slim. I'm not
 > entirely sure whether we want to explicitly permit or explicitly forbid
 > that, yet.

OK. Thanks for the clarification. If using different port is very limited use
I guess it's not a major thing.

From: "Ford, Alan" <[e-mail]>
Subject: Re: [multipathtcp] High-level design decisions /architecture
Date: Tue, 3 Nov 2009 18:35:40 -0000
Message-ID: <[e-mail]>

 > *	3 application profiles are mentioned (Bulk data transport,
 > Latency-sensitive transport with overflow, Latency-sensitive transport
 > with hot stand by) 
 > 
 > 	*	[Question: how are these supported? Is a negotiation
 > mechanism needed?]            
 > 
 > [Alan: TBD ;-)  The sender can control much of this; expressing policy
 > to/from the receiver is one of the key open issues.]

Hmm.. Suppose if you have a PC with two NICs and want to use one NIC only for back-up. 
When you want to download something from a server, how do you specify the above requirment? 
All I can think is signaling mechanism.. Can we leave this as an open issues?

 > o        [Question: what are the mechanisms for evolvability? How is it
 > negotiated which new module (for congestion control or path manager) to
 > use?]
 > 
 > [Alan: I would have thought that kind of decision is entirely out of
 > scope for a high-level framework, and even for detailed API decisions.
 > This is intended entirely as implementation guidance and was not written
 > with the intent for people to plug-and-play different modules.]

I somehow would like to know whether we're going to have one default CC 
algorithm or support multiple algorithms. 
For example, DCCP has several CC algorithms based on some profiles. 
In case of MPTCP, one CC is enough? How about non-reno type CC like CUBIC?

Maybe the answer is we could have multiple algorithms, but how to specify is
an implementation matter? 

Thanks,
--
Yoshifumi Nishida
[e-mail]