Subject: [multipathtcp] Yet another version (090921)

From: Magnus Westerlund <[email-masked]>
Date: Mon, 21 Sep 2009 18:55:25 +0200

Hi,

Taking Joe's, Toby's and Jari's comments into account I have produced
this version. Some significant changes that I like feedback on.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
Multipath TCP Working Group Charter (Draft)
===========================================
Version: 090921 
Last changer: Magnus Westerlund

The Multipath TCP (MPTCP) working group develops mechanisms that add the 
capability of simultaneously using multiple paths to a regular TCP 
session. The primary output of the group will be protocol extensions 
needed to deploy MPTCP, and adaptations to congestion control to safely 
support multi-path resource sharing. Initially the WG will only produce 
documents that are experimental or informational. 

Key goals for MPTCP is to be deployable and usable without significant 
changes to existing Internet infrastructure, usable by unmodified 
applications, stable and congestion safe over the wide range of existing
Internet paths. The design's success in meeting the goals 
should be determined through experiments. However, it is expected that 
some results from large scale experiments can only be achievable after the 
publication of the initial design. 

The working group will provide a modular architecture that is designed 
to be easily extensible and adaptable. In particular, the congestion 
control mechanism is separated from the mechanisms for identifying and 
using multiple paths. The working group will focus on a solution 
requiring modification of both peers. One or both peers are expected to 
have multiple addresses. Multiple addresses, even on different network 
interfaces are no guarantee that the paths between the peers are even 
partially diverging. However, using multiple addresses will in a number 
of cases results in different paths. The design need to address the 
issues associated with the lack of guarantee of different paths.

Whilst MPTCP will require modifications to the TCP stack at both the 
endpoints, all existing applications should be able to use the new MPTCP 
stack without modification and gain benefits from multipath usage. The 
impact on different classes of applications will be considered and 
documented. An extended API will be defined to allow applications to 
express particular preferences for how MPTCP operates, and get 
additional information about MPTCP-specific run- time events. 

It is also essential that all new security threats introduced by MPTCP 
are carefully analyzed and addressed in the appropriate protocol 
documents.

The following items will be worked on:

a. An architectural framework for congestion dependent multipath 
transport protocols. This is a document to track the technical 
documents, describing how the modular components fit together, and will 
describe the motivations and the general approach that should be 
followed to enable congestion dependent multipath transport. It will 
also analyze how MPTCP interacts with existing infrastructure elements 
and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. 
The results of any experiment performed during the development should also be 
included or referenced. 

b. A security threat analysis for multipath TCP. The ability to change 
the addresses used in the TCP session opens up new types of 
vulnerabilities and attacks. These and their mitigations needs to be 
documented. 

c. A coupled congestion control algorithm. This algorithm is the 
multipath equivalent of SACK/NewReno congestion control. As experience 
is gathered from implementations of other congestion control algorithms, 
it is expected that the working group will be rechartered to pursue 
additional work in these areas. 

d. Extensions to current TCP to support multi-addressed multipath TCP. 
This covers all on-the-wire changes required to create a two-ended MPTCP 
solution using multiple addresses at one or both ends. It will be 
designed in a modular fashion to allow alternative address management 
schemes to be explored in future. This document will also include a 
basic security model, including analysis and mitigation of threats 
introduced by these specific MPTCP extensions.

e. An application consideration, presenting the impacts that 
MPTCP may have on applications, such as performance changes, and 
including an extended API describing how applications can exploit 
additional features of multipath transport. While MPTCP needs to be 
usable without any application changes, this API should be an optional 
extension that provides access to multipath information and enables  
control over usage. 

Where appropriate, this group is expected to coordinate with, and will 
use input from, the MIF working group to support use of multiple 
interfaces.

Goals and Milestones:

Mar 2010 - Established WG consensus on the Architecture
Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat Analysis as informational RFC(s)
Dec 2010 - Submit to IESG basic coupled congestion control as an experimental RFC
Dec 2010 - Submit to IESG protocol specification for MPTCP extensions as an experimental RFC
Mar 2011 - Submit to IESG application considerations and API as an informational RFC
Mar 2011 - Recharter or close WG

---

From: Pasi Sarolahti <[email-masked]>
Date: Mon, 21 Sep 2009 18:11:07 -0700

> this version. Some significant changes that I like feedback on.

The text looks pretty good to me. Mostly an editorial suggestion to  
the part that discusses whether paths are different or not:

Originally:
"One or both peers are expected to
have multiple addresses. Multiple addresses, even on different network
interfaces are no guarantee that the paths between the peers are even
partially diverging. However, using multiple addresses will in a number
of cases results in different paths. The design need to address the
issues associated with the lack of guarantee of different paths."

suggest:
"One or both peers are expected to have multiple addresses, which  
often results in different network paths that are at least partially  
diverging. However, multiple addresses, even on different network  
interfaces are no guarantee that the paths are diverging at all. The  
design needs to address the issues associated with fully or partially  
joint paths."

I.e., trying to give a bit more emphasis to the fact that often the  
paths may be just partially diverging and share some links. This may  
be relevant at least for the congestion control aspects, especially if  
the paths share the same bottleneck.

Then, on work item c:
The meaning of "A coupled congestion control algorithm" might not be  
clear to everyone. I wonder if simply calling it "multipath-aware  
congestion control algorithm" would be sufficient here.

- Pasi

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 09:36:06 +0100

Inline (these are just responses to Pasi's comments...)

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Pasi Sarolahti
> Sent: 22 September 2009 02:11
> To: Magnus Westerlund
> Cc: [email-masked]
> Subject: Re: [multipathtcp] Yet another version (090921)
> 

Pasi's version sounds better - it makes the problem clearer and puts the
correct emphasis on the chances of path disjointedness. I wonder if it
might be worth being a little clearer still and highlight that partially
joint paths may share a bottleneck? 

> congestion control algorithm" would be sufficient here.

I think it needs to imply more than just an awareness of multipath
(after all you can be aware of something without actually taking it into
account) but I agree "coupled congestion control" needs a bit of
expansion. Could we just combine them into a "coupled multipath-aware
congestion control algorithm"? I know it's a bit of a mouthful...

Toby

> 
> - Pasi
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: <[email-masked]>
Date: Tue, 22 Sep 2009 11:36:52 +0100

Minor grammatical corrections:

"... output of the group will be the protocol extensions..." (insert "the")

"Key goals for MPTCP are to be deployable..." (change "is" to "are")

For comments on multiple addresses see Pasi's email and my response to it...

"...and to get additional information about MPTCP-specific run-time events." (insert "to" and remove space between run- and time)

I find "This is a document to track the technical documents,..." a confusing phrase. Perhaps it might be better to say "...an overview document which tracks..."
"...should also be included or referenced in this document." (insert "in this document" for clarity)

"The ability to change the addresses used in the TCP session opens up..." Suggested alternative wording: "The ability to change the addresses used during a TCP session opens up..."

"An application consideration, ..." doesn't quite make sense. You either mean "An application considerations document" or "A protocol impact study" 

"enables control over usage" sounds awkward. Might be better to expand it "enables control over the usage of multipath"

In Goals and Milestones there is inconsistent use of capital letters in the titles of the different submissions...

Toby

> [email-masked]] On Behalf Of Magnus Westerlund
> Sent: 21 September 2009 17:55
> To: [email-masked]
> Subject: [multipathtcp] Yet another version (090921)
> 
> Hi,
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Sep 2009 20:47:46 -0700

Hi Magnus,

Looks good, though I would put API in with the protocol spec, not the
application considerations doc.

Joe
- ---

Mar 2010 - Established WG consensus on the Architecture
Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat
Analysis as informational RFC(s)
Dec 2010 - Submit to IESG basic coupled congestion control as an
experimental RFC
Dec 2010 - Submit to IESG protocol specification for MPTCP extensions as
an experimental RFC
Mar 2011 - Submit to IESG application considerations and API as an
                                                     ^^^^^^^
informational RFC
Mar 2011 - Recharter or close WG