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

["Ford, Alan" <[e-mail]>]

Hi Phil, all,

 

Some comments inline.

 

Thing is, there are quite a large scope of topics ranging from
"architecture" to "high-level design decisions". It is quite feasible to
have fixed architectural components while high-level design can be
flexible. This not necessarily the same as "detailed design"!

 

From: [e-mail]
[mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: 02 November 2009 17:48
To: [e-mail]
Subject: [multipathtcp] High-level design decisions /architecture

 

Hi

 

In order to help the process of reaching consensus on the high-level
design decisions /architecture, we have gone through the current set of
I-Ds to identify items that seem like they may fall into the category of
high-level design decisions - see below. Note: this list is not to meant
to imply our support or non-support of these items (except where our
charter requires our support!); the purpose is to identify what needs to
be discussed.

 

Please shout if there's something we misunderstood or missed.

 

Please let the WG know your opinions on these items - especially if your
disagree with any, have a potential alternative, or think something is
part of 'detailed design' and not 'high-level design'.

 

Thanks

Phil & Yoshifumi

 

 

Protocol-related

============

*	IPv4 & IPv6 will have the same high-level design 

	*	[Comment: the Charter implies both v4 & v6 are in scope]


 

[Alan: Agreed]

 

*	The MPTCP connection is identified, from an apps perspective, by
the addresses associated with the original path (even if that subflow
/path closes) 

 

[Alan: This is still a contentious issue. If the new MPTCP API is in
use, this issue - as a concept - does not really exist. There is a
connection identifier, there are sets of addresses, etc. This is talking
about the legacy case, and what happens if an application later queries
a socket (getsockname and getpeername). I can see Bill's and Joe's
arguments here of where problems could occur. I think, however, that the
problems that may occur with returning the original addresses are less
than any other way.]

 

*	A SYN/ACK exchange (on a single path) checks that both ends
support MPTCP, with automatic fall-back to TCP if not 
*	each MPTCP subflow looks exactly like an ordinary, semantically
independent TCP flow. MPTCP effectively runs on top. So re-transmission,
FINs etc are independent on each subflow 

 

[Alan: Yes, I think this is an important high-level decision]

 

*	control of the MPTCP connection (as opposed to the subflows) is
carried in TCP options, eg DATA FIN for closing an MPTCP connection 
*	the protocol involves an MPTCP stack at both ends of the MPTCP
connection 

	*	[Comment: this is in our charter] 

*	Either end of the MPTCP connection can add or remove paths
to/from the MPTCP connection 

	*	[Comment / Question: this seemed a bit unclear in the
protocol i-d, but is presumably required?] 

 

[Alan: Yes, absolutely. Adding paths and signalling new addresses are
also potentially separate to permit flexibility with
middleboxes/firewalls/etc.]

 

*	Subflow end point definition

	*	[Question: Should we allow subflows in a single MPTCP
connection to have different ports?] 

 

[Alan: Yes. By default I would expect implementations to go for the same
ports so as to maximise the chances of getting through
firewall/middleboxes, but there is no technical reason why it could not
be used between any ports. The draft specifies the mapping that an
endpoint must have.]

 

 

Congestion algorithm

===============

*	the goals are: [1] MPTCP is at least as good as TCP would be on
the best subflow path; [2] on any path, an MPTCP connection uses less
(or the same) capacity as a TCP connection would do; [3] MPTCP moves
traffic off more congested paths and onto less congested ones 
*	increases in the congestion windows of the subflows are coupled;
for decreases in the congestion windows, each subflow does new reno
independently (ie they are not coupled) 
*	slow start, fast re-transmit and fast recovery are the same as
RFC5681 

 

 

API

===

*	no changes to existing apps are needed to use MPTCP; MPTCP uses
the unaltered TCP socket API 
*	There is an optional, extended API 

	*	[Question: would both ends need the extended API, with a
fall-back if not?] 

 

[Alan: No, the extended API is about signalling preferences to, and
getting information from, the local implementation. If it did involve
anything happening on the wire, this would simply be triggering the
operation of existing features.]

 

	*	[Comment: presumably the actual features of the extended
API are outside the initial high-level design decisions] 

 

[Alan: Yes, although the use cases that drive the API decisions may also
help at a high level.]

 

*	congestion control state is shared among application-visible
transport instances (eg multiple HTTPs between the same pair of hosts) 

 

[Alan: Huh?]

 

*	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.]

 

 

 

Security

======

*	exchange a token in the initial SYN for the MPTCP connection,
and include the token when subflows /paths are added to the connection 

	*	[Question: Is the same token used whether the sender or
receiver (of the MPTCP connection) adds the subflow? Is the same
technique used for removing subflows? And closing connections, ie DATA
FIN?] 

 

[Alan: in the current design (very much open to input of course), the
sender and the receiver both have independent, locally unique tokens.
Aside from the initial handshake, where the local token is used, all
future token uses (currently limited to opening new subflows) are the
remote token. Removing subflows is just a FIN on the subflow, or
signalled via options if the address is lost. Closing connections also
does not use tokens.

 

We are clear that this is a very minimal handshake mechanism, simply
seeking to be no worse than regular TCP. More secure mechanisms are
FFS.]

 

*	security mechanisms will not interfere with end-to-end
authentication etc and will be compatible with legacy middleboxes 

 

 

Modularity

========

*         the architecture has 2 components, multipath scheduler & path
manager - meaning that improved /different modules of each can be
slotted in 

 

[Alan: This seems to be causing some concern with people as to whether
this belongs in an "architecture" document. Personally, I see it as part
of the "framework" through which the relevant components of any
Multipath TCP could be implemented. It is a way of thinking about the
functional separation required to allow modularity.]

 

o        [Comment: it is unclear from the Architecture i-d how the
congestion control & protocol i-ds map to these components; some of the
text (strangely?) appears in a section about implementation]

 

[Alan: Will be ironed out in due course - although the congestion
control clearly lives in the scheduler, there are also some protocol
components there.]

 

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

 

o        [Question: this would seem to imply we need to define an
interface between the modules?]

*         there is a default path manager module, meaning it is the MUST
fall-back option                                                 

o        [Comment: the charter restricts us - the path manager we work
on will distinguish paths by multiple addresses]

 

[Alan: Sure, but that doesn't prevent us designing an evolvable
framework so that different path managers could be used with much of the
rest of the protocol having minimal changes.]