Subject: [multipathtcp] Draft charter 090922 or yet, yet another version

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Sep 2009 15:23:14 +0200

Hi,

Thanks for the feedback Pasi and Toby. I have implemented your
suggestions into this version.

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: 090922
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 the protocol extensions 
needed to deploy MPTCP, and adaptations to congestion control to safely 
support multipath resource sharing. Initially the WG will only produce 
documents that are experimental or informational. 

Key goals for MPTCP are 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, 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 and shared bottlenecks.

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 to 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 overview document which tracks 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 in this document. 

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

c. A coupled multipath-aware 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 considerations document, 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 the usage of multipath. 

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: <[email-masked]>
Date: Tue, 22 Sep 2009 14:32:50 +0100

That seems perfect now apart from a single missing comma:

"... different network interfaces, are no guarantee..."

Toby

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Magnus Westerlund
> Sent: 22 September 2009 14:23
> To: [email-masked]
> Subject: [multipathtcp] Draft charter 090922 or yet, yet another
> version
> 
> Hi,
>

---

From: Scott Brim <[email-masked]>
Date: Tue, 22 Sep 2009 10:16:15 -0400

Hi.  Just a few more comments.  The last two are not just editorial.

> applications, stable and congestion safe over the wide range of existing

congestion-safe

  (I assume you mean "will not kill approved TCPs")

> a. An architectural framework for congestion dependent multipath 

congestion-dependent

> transport protocols. This is a overview document which tracks the 

a overview -> an overview

> vulnerabilities and attacks. These and their mitigations needs to be 

needs to be -> will be

> control. As experience is gathered from implementations of other 

other -> various

> This document will also include a

The analysis and mitigation should be in the (b) document.  This (c)
document should just have the basic security model, and refer to (b) for
the rest.  I would delete the second half of the sentence.

> Mar 2011 - Submit to IESG application considerations and API as an informational RFC

I would move this up sooner.  The API is important, and we don't have to
focus on one document at a time..

Thanks ... Scott

---

From: "Ford, Alan" <[email-masked]>
Date: Tue, 22 Sep 2009 15:37:34 +0100

Looks great! A couple more minor editorial changes:

"Key goals for MPTCP are 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."

-> Reads slightly strangely. How about making the list more explicit:
"Key goals for MPTCP are: to be deployable and usable without significant changes to existing Internet infrastructure; to be usable by unmodified applications; and to be stable and congestion safe over the wide range of existing Internet paths."

"are at least partially diverging"

-> "are at least partially divergent" (and same in next sentence)

"Whilst MPTCP will require modifications to the TCP stack at both the endpoints"

-> You've changed all other "endpoints" to "peers", so "...at both peers" ?

"This is a overview document which tracks..."

-> "This is an overview document..."

Regards,
Alan

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Magnus Westerlund
> Subject: [multipathtcp] Draft charter 090922 or yet, yet another version
> 
> Hi,
>