Subject: [multipathtcp] One more version of the draft MPTCP charter

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 Sep 2009 14:32:27 +0200

Hi,

attached is a new version of the draft charter. Alan Ford provided me
with a new version that I since have made some changes to.

The existing consensus roughness to the charter is all about single or
both end modifications. I have reviewed the arguments and my position is
that the modifications to both ends appears to be the most reasonable
work item for a WG. My motivation is the following:

1. Both ends provide the greatest benefits in the long run, but I do
acknowledge the increase deployment hurdles.

2. Both ends target an addressing environment with multiple interfaces
that to me appears to be more common and more easily achievable without
changes to routing infrastructure.

3. Single ended and its achievement of path diversity seems to rely on
mechanisms that doesn't exist.

I do acknowledge that neither of the solutions provide a really
generalized solution when it comes to which environments it can be
deployed. There is clearly going to be a lot of more discussion on how
you achieve the desired path diversity with different means both with
provider dependent and provide independent addresses with or without
multiple interfaces.

However, I do note that this is proposed to be a WG that develops
experimental specifications. We can improve, extend and even re-design
when we have learn more.

Further comments on the draft charter is welcome. I do intended to
request that IESG consider this for external review on its telechat in
2.5 weeks. Which means I needs to have charter text with sufficient
consensus by next weeks Thursday.

Best Regards

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: 090907 
Last changer: Magnus Westerlund

The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of 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.

In support of these goals, this 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.

Initially the working group will focus on a solution requiring modification of both endpoints. One or both endpoints are expected to have multiple addresses which can be used to potentially provide multiple paths between the endpoints. Whilst this will require modifications to the TCP stack at the endpoints, all existing applications should be able to use the new MPTCP stack without modification, and any impact on applications must be considered and documented. In due course, an extended API is expected to be defined to allow applications to express particular preferences over MPTCP operation, and gather information about MPTCP-specific behaviour. A key measure of the success of this working group is that the TCP protocol modifications are deployable in an unmodified Internet and work with existing unmodified applications. It is also essential that all new threats introduced by MPTCP are carefully analysed and addressed in the appropriate protocol documents.

The following components will be defined:

a. An architectural framework for congestion dependent multipath transport protocols. This is a working 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. In addition, this document will provide a threat analysis of multipath transport. Where available, this document will also include a summary of the results of experiments carried out.

b. A coupled congestion control algorithm
This will specify a 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 persue additional work in these areas.

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

d. Application considerations
This will be a living document presenting the impacts that MPTCP may have on applications, such as performance changes, and will include an extended API describing how applications can exploit additional features of multipath transport. While MPTCP must be usable without any application changes, this API should be an optional extension that provides access to multipath information and enable the control of the usage. The necessity of this work will be determined during the development of the MPTCP protocol itself.

In addition, the following item is excluded from this charter at this stage, but could form part of a re-charter once the initial work described above has been completed.

e. Guidance for implementers of single-ended multipath TCP
Single-ended multipath TCP, where one endpoint is able to control the routing of TCP packets across multiple paths, does not require any on-the-wire protocol changes to be standardised, and as such this document will focus on practical implementation experience.

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

The initial goal is that the documents produced by the WG will be either experimental or informational. When experience has been gathered on topics such as that MPTCP can be deployed and used without significant changes to existing Internet infrastructure, be used with unmodified applications, is stable and congestion safe over the wide range of existing Internet paths, a recharter to take revised specification to proposed standard can be requested. 

Goals and Milestones:

Aug 2010 - Submit to IESG Architectural Guidelines and Threat Analysis as an informational RFC
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

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 9 Sep 2009 09:23:54 -0700

Hello Magnus,

Magnus Westerlund wrote:
> both end modifications. I have reviewed the arguments and my position
> is that the modifications to both ends appears to be the most
> reasonable work item for a WG. My motivation is the following:
> 

I think Iljitsch made the point already that there such mechanisms do exist: DSMIPv6 and SHIM6. So I do think it makes sense to work on a single ended version of SCTP that can rely on those mechanisms when available.

Moreover, I want to have a more architectural discussion on the layer at which address agility mechanisms can reside and on the implications of having them co-existing at two different layers such as network and transport. 
 
There's the precedent of SHIM6 vs. SCTP where a SHIM6 I-D discussing its applicability said the following:

   However, since SCTP and shim6 both aim to exchange addressing
   information between hosts in order to meet the same general goal, it
   is possible that their simultaneous use might result in unexpected
   behaviour, e.g. due to race conditions.

   The capabilities of SCTP with respect to path maintenance of a
   reliable, connection-oriented stream protocol are more extensive than
   the more general layer-3 locator agility provided by shim6.  It is
   recommended that shim6 is not used for SCTP sessions, and that path
   maintenance is provided solely by SCTP.

I think it was fine to say so because SCTP was there before so SHIM6 had to cope with SCTP, not the other way around. So that's what you end up with: no SHIM6 for SCTP.
 
But now the situation is different, we have SHIM6, we have MIP6 and its dual stack mode that works for both IPv4 and IPv6 and pass thru NATs. So we do have address agility mechanisms at the _network_ layer, a one-ended (MIPv6) and a dual ended (SHIM6).
 
>From an architecture point of view, if the assumption that address agility can reside in the network layer is not insane, which I'm assuming isn't since the IETF developed at least 3 protocols doing so based on that assumption, doesn't it make sense that while developing new flavors of transport layer address agility (such as mptcp), care is taken to analyze the interactions between transport and network layer address agility mechanisms and specify behavior that makes them work nicely together?

Possible acceptable behavior could be:

- the transport layer agility mechanism leverages on the network layer mechanism when available, and provides its own mechanism otherwise.

- the transport layer agility mechanism is disabled when the network layer mechanism is enabled.

- the network layer agility mechanism is disabled when the transport layer mechanism is enabled.

In summary, I'd like the charter to cover work on the single-ended version and also interactions between mptcp and existing network layer address agility mechanisms.

--julien

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 10 Sep 2009 11:42:38 +0200

> - the transport layer agility mechanism leverages on the network  
> layer mechanism when available, and provides its own mechanism  
> otherwise.

> layer mechanism is enabled.

This of course gets even worse when host A supports the network layer  
mechanism and host B doesn't, as the Shim6 capability of the other  
side isn't known at the start of the first session between two  
hosts... (I'm guessing the same for MIP but don't know.)

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 17:03:29 +0200

Hi Julien,

Yes, interesting issues. However, I think they need somewhat different
skills than what is needed for defining a two-ended MPTCP.

In the interest of having a focused working group with a clear goal I
still think that focusing on two-ended MPTCP only is the most attractive
option.

There is clearly work that can be done around single ended MPTCP and the
interactions with lower layer mechanism. I do hope they are not abandon.
Another WG or later in the lifetime of this WG can be the appropriate
place to take this work on.

Best Regards

Magnus

-- 

Magnus Westerlund

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Sep 2009 17:12:50 +0200

Hi Magnus,

I understand that the other concern expressed by Julien is that probably 
it would be important to understand how MPTCP and existing address 
agility mechanisms such as MIP interact.

After all, we do want that different pieces of the architecture interact 
nicely and some thought about this type of interactions arw worthwhile imho.

I think this would be perfectly in scope of the architectural document 
that is included in the current charter. Maybe it would be good to make 
it more epxliclty i.e. that the arch document will cover the 
interactions of MPTCP and other mechanisms defined by the IETF for 
supporting address agility.

Regards, marcelo

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 14 Sep 2009 17:46:10 +0200

> supporting address agility.

Makes sense, I will try to write that into the draft charter. I have
gotten some private feedback that I think will improve the charter. I
hope to be able to send that out tomorrow afternoon.

Cheers

Magnus Westerlund

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Sep 2009 12:18:44 -0400

Excerpts from marcelo bagnulo braun on Mon, Sep 14, 2009 05:12:50PM
+0200:
> I understand that the other concern expressed by Julien is that
> probably it would be important to understand how MPTCP and existing
> address agility mechanisms such as MIP interact.
> 
> After all, we do want that different pieces of the architecture
> interact nicely and some thought about this type of interactions arw
> worthwhile imho.
> 
> I think this would be perfectly in scope of the architectural
> document that is included in the current charter. Maybe it would be
> good to make it more epxliclty i.e. that the arch document will
> cover the interactions of MPTCP and other mechanisms defined by the
> IETF for supporting address agility.

Marcelo, IMHO ...

Certainly the group charter should include how MPTCP interacts with
other infrastructure elements.  In fact you could stop right there,
with that sentence.  Since it renders most other approaches to
"suppporting address agility" unnecessary, I don't see the need to
talk about interactions between them -- they won't happen in
real-world deployments.  HIP has other justifications so the
interactions are worth exploring.  It would be good to describe
interactions between MPTCP and MIP's HA/HoA capabilities, but not
MIPv6 "route" optimization, and so on.

Scott

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 14 Sep 2009 20:07:47 +0200

> MIPv6 "route" optimization, and so on.
not sure what do you mean by MIP's HA/HoA cpabilities
but in any case, figuring out whehter it makes sense to use MPTCP joint 
with RO mode or with BT mode, is already part of the analysis!
So i guess that we agree that at this stage we need to include this 
analysis.

Regards, marcelo

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