[multipathtcp] High-level design decisions /architecture

[<[e-mail]>]

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]


*	The MPTCP connection is identified, from an apps perspective, by
the addresses associated with the original path (even if that subflow
/path closes) 
*	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 
*	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?] 

*	Subflow end point definition

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

 

 

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?] 
	*	[Comment: presumably the actual features of the extended
API are outside the initial high-level design decisions] 

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

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

 

 

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

*	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 

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]

o        [Question: what are the mechanisms for evolvability? How is it
negotiated which new module (for congestion control or path manager) to
use?]

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]