Subject: [multipathtcp] initial draft proposal for revised charter

From: <[email-masked]>
Date: Tue, 20 Mar 2012 08:40:21 +0000

Since we have finished our current charter, we need to revise it.
Here's a first attempt at this for comments. We will discuss the revised charter in Paris, but please comment in the meantime as this will make our face-to-face time more effective.
Two points to note & for comment:

*         It suggests we will work on a bis version of the protocol moving it to standards track. This will be the current functionality + lessons from implementations, interops etc

*         This would mean that new functionality is in experimental extensions, rather than incorporated in the standards track doc

*         The text below is deliberately provocative in suggesting that the only new functionality we work on is MPTCP proxy. This is just a guess based on recent mailing list activity. We have discussed several other topics in the past. We need to define the list of new functionality we will work on during the next phase of the WG
Thanks,
Phil & Yoshifumi.
--
Multipath TCP (mptcp)
---------------------

Charter

Current Status: Active

Chairs:
     Philip Eardley <[email-masked]>
     Yoshifumi Nishida <[email-masked]>

Transport Area Directors:
     Wesley Eddy <[email-masked]>
     David Harrington <[email-masked]>

Transport Area Advisor:
     Wesley Eddy <[email-masked]>

Mailing Lists:
     General Discussion: [email-masked]
     To Subscribe:       https://www.ietf.org/mailman/listinfo/multipathtcp
     Archive:            http://www.ietf.org/mail-archive/web/multipathtcp/

Description of Working Group:

  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.

  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,  including NAT interactions.

In its initial charter, the working group focussed on a solution
  requiring modification of both peers. One or both peers
  have multiple addresses, which often results in different network paths
  that are at least partially divergent (however, note there is no guarantee that the paths are
  divergent at all). The WG defined a modular architecture that is designed
  to be easily extensible and adaptable, to allow (for example) a new mechanisms for congestion control or security, or alternative address management schemes.

The WG produced experimental or informational documents that defined:

  a. An architectural framework for congestion-dependent multipath
  transport protocols. It describes the motivations and the general approach that should
  be followed to enable congestion-dependent multipath transport.

  b. A security threat analysis for multipath TCP.

  c. A coupled multipath-aware congestion control algorithm. This
  algorithm is the multipath equivalent of SACK/NewReno congestion
  control.

  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 includes a
  basic security model.

  e. Application Interface Considerations. It summarizes the impact that MPTCP may have on applications, such as changes in performance.  Also, it describes an optional, basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP.

The working group now re-charters with the goal of moving a bis version of the protocol document from the Experimental to the Standards track. It requires experience from implementations, experiments and use cases. The WG will organise interop event(s). There already exists a reference Linux implementation and other implementation and experiment activity is on-going and will continue during 2012, with the objective of progressing the protocol to standards track during 2013.

The working group will also add new functionality, as Experimental extension(s) to the core MPTCP protocol:

*         Proxy functionality

*         Nothing else envisaged at this stage

*         (the above two bullets are just a preliminary guess based on recent mailing list activity)

Finally, the working group will document useful information about:

*         advice about implementation specific heuristics

*         record interesting experiments (including interop events), experiences and use cases

Goals and Milestones: to be defined

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 20 Mar 2012 14:19:50 -0500

All,

I propose that the new charter explores alternative MPTCP implementations and their respective tradeoff in feature support.

The present design makes the implicit assumption that MPTCP is implemented in the kernel's transport layer. While such implementation permits multipath operation under "worst-case" situations, i.e. when large variations in throughput and delay exist across multiple paths, it is also very cumbersome to conduct.

In more favorable multipath environments or when mobility support is sufficient, alternative implementation approaches, such as bump-in-the-stack with zero-payload-buffering, can be pursued which are easier to conduct, provide better cross-platform portability and enable more economical proxy realizations.

Our efforts to realize such a L3 MPTCP implementation have identified a variety of issues where the present MPTCP design is too rigid. Note that other protocols, e.g. IPsec (RFC 2401), explicitly consider different implementation approaches.

While exploring implementation alternatives, the new charter should ensure full interoperability among all potential approaches.

I think that MPTCP's applicability, market acceptance and deployability would greatly benefit from such charter extension.

Comments are welcome. Thanks.

Regards,

Georg

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 20, 2012 4:40 AM
To: [email-masked]
Subject: [multipathtcp] initial draft proposal for revised charter

Charter

Current Status: Active

Chairs:

Transport Area Advisor:

Mailing Lists:

*         Proxy functionality

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 27 Mar 2012 13:04:11 -0500

All,

I'm proposing to add MOBILITY to MPTCP's revised charter, for the following reasons:

1)       Strong use case:
MPTCP allows 3G/4G mobility operators to dynamically offload traffic from their air interface to unlicensed spectrum. When deployed as end-to-end solution, it also permits dynamically offloading the 3G/4G core. Together with MPTCP's middlebox compliance, there is no other solution that offers such features.

2)       Implementation sweet spot:
MPTCP-mobility can be realized via simple implementation below transport layer while being fully interoperable with full-blown MPTCP. Using the same implementation, proxy operation can be conducted in a very resource-efficient manner. This makes MPTCP rollout fast and proxy operation low-cost.

3)   Buzz:
There is a large group of people, e.g. mobile operators, interested to find a solution to the above use case and they NEVER think of MPTCP unless it gets the term "MOBILITY" explicitly spelled out in its charter!

In other words: I think we are missing out on a great opportunity if we do NOT put MOBILITY onto the revised charter. Thanks.

Regards,
Georg

Sent: Tuesday, March 20, 2012 9:40 AM

Charter

Current Status: Active

Chairs:

Transport Area Advisor:

Mailing Lists:

*         Proxy functionality

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 27 Mar 2012 21:40:39 +0200

Georg,
> 
> I’m proposing to add MOBILITY to MPTCP’s revised charter, for the
> following reasons:
> 
>  
> 
> 1)       Strong use case:
> 
> MPTCP allows 3G/4G mobility operators to dynamically offload traffic
> from their air interface to unlicensed spectrum. When deployed as
> end-to-end solution, it also permits dynamically offloading the 3G/4G
> core. Together with MPTCP’s middlebox compliance, there is no other
> solution that offers such features.
> 

This already works with the current specification. We have an
implementation that is already able to perfom WiFi/3G offload and we are
performing measurements in real networks.

We already have some experience to prepare a report describing how MPTCP
can be used in mobile
environments. If the WG thinks that such a report would be useful, we
can prepare a first draft.

Based on our previous work, we also have some ideas on the datacenter
usecase for MPTCP and could also contribute to an applicability draft in
this domain.

> MPTCP-mobility can be realized via simple implementation below transport
> layer while being fully interoperable with full-blown MPTCP. Using the
> same implementation, proxy operation can be conducted in a very
> resource-efficient manner. This makes MPTCP rollout fast and proxy
> operation low-cost.

The main benefit of MPTCP compared to network layer solutions is that
the congestion control scheme is aware of the path changes and can react
appropriately. I'm not sure I completely understand the benefits and
limitations of your proposed simple implementation.

An important point for the acceptance of MPTCP will be interoperability
reports from at least two different implementations. Our implementation
is now almost completely compliant. We'd be happy to perform
interoperability tests with any other implementation.

> 3)   Buzz:
> 
> There is a large group of people, e.g. mobile operators, interested to
> find a solution to the above use case and they NEVER think of MPTCP
> unless it gets the term “MOBILITY” explicitly spelled out in its charter!

Mobile network operators willing to see a demonstration of MPTCP in a
mobile Wifi/3G offload scenario can contact us offline...

Olivier

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 27 Mar 2012 21:43:50 +0200

Phil,

> Here’s a first attempt at this for comments. We will discuss the revised
> charter in Paris, but please comment in the meantime as this will make
> our face-to-face time more effective.

> ·         It suggests we will work on a bis version of the protocol
> moving it to standards track. This will be the current functionality +
> lessons from implementations, interops etc

It is important to document lessons from implementations and we should
organise interop events as soon as another implementation becomes available.

> ·         This would mean that new functionality is in experimental
> extensions, rather than incorporated in the standards track doc
> ·         The text below is deliberately provocative in suggesting that
> the only new functionality we work on is MPTCP proxy. This is just a
> guess based on recent mailing list activity. We have discussed several
> other topics in the past. We need to define the list of new
> functionality we will work on during the next phase of the WG

The MPTCP proxy is an important problem that needs to be solved. I fully
support including it in the charter.

Olivier

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 28 Mar 2012 02:36:14 -0500

Olivier,

I know that the present implementation already supports mobility. But that doesn't diminish my points. What I am aiming for is middle-box-compliant mobility at low cost.

I have inserted comments. Thanks.

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2012 9:41 PM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Yoshifumi Nishida
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Georg,
> core. Together with MPTCP's middlebox compliance, there is no other

[GH] That's all fine, but it doesn't affect the validity of point 1). 

[GH] I presented the concept in Quebec City. I can show trial results from an implementation. We can discuss benefits and limitations at any time. We can also work this as part of a new charter.

[GH] We have just started interoperability tests with Christoph's code. Interoperability, indeed, is very important.

> unless it gets the term "MOBILITY" explicitly spelled out in its charter!

[GH] ...if they realize that MPTCP offers a "mobility solution for traffic offload". Mobility-seeking people don't trigger when you say "multipath". I don't understand why you want to miss out on this opportunity.

Olivier

---

From: Daniel Migault <[email-masked]>
Date: Wed, 28 Mar 2012 10:58:20 +0200

Hi,

Offload is currently a VERY HOT topic for ISPs, but ISPs HARDLY know MPTCP
(I know a lot more about it then I do about MPTCP). Thus I would favor any
titles document that are offload-centric. This would provide MPTCP the
necessary visibility, and MPTCP is of interest for ISPs in an offload
context.

MIP/MOBIKE is probably a target for offload. However, in the short term,
some ISPs will probably not deploy MIP architecture nor deploy a complete
Security Gateway architecture ready to deal with all the EU traffic.
Consequently, in the short term such ISPs are looking for solution where
Mobility Multihoming and Multiple Interfaces Management is handled by the
EU, not the CORE Network.

Without an infrastructure that deals with all traffic in a single manner,
Mobility Multihoming and Multiple Interface Management will be handled on a
per application basis. This can be done at the application layer, but in
some case, there are some interests to do that at the transport layer.

I worked with SCTP but MPTCP seems a lot better. Aside from MPTCP features
we have to also evaluate how migration from TCP applications to MPTCP can
be done, the easiest the better -- even if not all features are available.
Does MPTCP overhead for a single connection affects traditional TCP
users....

The important thing is that I feel ISPs are considering adapting some of
their applications to adapt them to an offload context, and that 's a real
opportunity.

Best Regards,
Daniel

On Wed, Mar 28, 2012 at 9:36 AM, Hampel, K Georg (K Georg) <
[email-masked]> wrote:

> Olivier,
>
> I know that the present implementation already supports mobility. But that
> doesn't diminish my points. What I am aiming for is middle-box-compliant
> mobility at low cost.
>
> [GH] I presented the concept in Quebec City. I can show trial results from
> an implementation. We can discuss benefits and limitations at any time. We
> can also work this as part of a new charter.
>
>
> [GH] We have just started interoperability tests with Christoph's code.
> Interoperability, indeed, is very important.
>
>
> > 3)   Buzz:
> >
> [GH] ...if they realize that MPTCP offers a "mobility solution for traffic
> offload". Mobility-seeking people don't trigger when you say "multipath". I
> don't understand why you want to miss out on this opportunity.
>
>
>
> Olivier
>
> --
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: <[email-masked]>
Date: Wed, 28 Mar 2012 10:21:16 +0100

Daniel -
thanks for your input on a good use case, this is very useful.

just wanted to make sure I understand this right
>>The important thing is that I feel ISPs are considering adapting some of their applications to adapt them to an offload context, and that 's a real opportunity.
By ISP, are you just referring to mobile ISP, and offload means using WiFi rather than 3/4G?

by default, MPTCP uses the same API as TCP, ie it is hidden from the application. we also defined a 'basic mptcp api' that allows mptcp-aware apps to get some mptcp info. we have talked about doing an advanced mptcp api with more complex capability - the api draft gives a few ideas. currently no-one has said they think the re-charter should work on specifying the advanced api.

mptcp's congestion control is friendly to ordinary tcp (ie it doesn't outcompete where mptcp's multiple paths happen to all go through the same link that is also a bottleneck for a [single path] tcp)

we will be having re-chartering discussion on friday - so it is very relevant to talk about where we need to develop extra functionality, and/or where we need Info doc that explains how to use the currently specified capability in specific use cases that are of particular interest.

api doc is http://datatracker.ietf.org/doc/draft-ietf-mptcp-api/ (status: completed WGLC, about to go to IESG)

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Daniel Migault [[email-masked]]
Sent: 28 March 2012 09:58
To: Hampel, K Georg (K Georg)
Cc: [email-masked]
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Hi,

Offload is currently a VERY HOT topic for ISPs, but ISPs HARDLY know MPTCP (I know a lot more about it then I do about MPTCP). Thus I would favor any titles document that are offload-centric. This would provide MPTCP the necessary visibility, and MPTCP is of interest for ISPs in an offload context.

MIP/MOBIKE is probably a target for offload. However, in the short term, some ISPs will probably not deploy MIP architecture nor deploy a complete Security Gateway architecture ready to deal with all the EU traffic. Consequently, in the short term such ISPs are looking for solution where Mobility Multihoming and Multiple Interfaces Management is handled by the EU, not the CORE Network.

Without an infrastructure that deals with all traffic in a single manner, Mobility Multihoming and Multiple Interface Management will be handled on a per application basis. This can be done at the application layer, but in some case, there are some interests to do that at the transport layer.

I worked with SCTP but MPTCP seems a lot better. Aside from MPTCP features we have to also evaluate how migration from TCP applications to MPTCP can be done, the easiest the better -- even if not all features are available. Does MPTCP overhead for a single connection affects traditional TCP users....

The important thing is that I feel ISPs are considering adapting some of their applications to adapt them to an offload context, and that 's a real opportunity.

Best Regards,
Daniel

On Wed, Mar 28, 2012 at 9:36 AM, Hampel, K Georg (K Georg) <[email-masked]<mailto:[email-masked]>> wrote:
Olivier,

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Tuesday, March 27, 2012 9:41 PM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Yoshifumi Nishida
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Georg,

Olivier

[email-masked]<mailto:[email-masked]>

--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 28 Mar 2012 11:46:11 +0200

Georg,

> [GH] That's all fine, but it doesn't affect the validity of point 1). 

We should document use cases of MPTCP. We are ready to contribute by
preparing a draft on :
- mptcp use case for mobile offload
- mptcp use case for datacenters

MPTCP could also play a role in the IPv4/IPv6 transition and we would be
ready to contribute to a draft to discuss this use case as well.

> [GH] ...if they realize that MPTCP offers a "mobility solution for traffic offload". Mobility-seeking people don't trigger when you say "multipath". I don't understand why you want to miss out on t…

I agreed that MPTCP can play a role in this domain and we should
probably improve the marketing of MPTCP. Documenting use cases would be
a good way to improve the visibility within the IETF, but not all
operators follow IETF.

Concerning the charter, we should not limit ourselves to the mobile
environment. MPTCP has the same use cases as TCP and thus has broad
applicability.

Olivier

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 28 Mar 2012 11:50:20 +0200

Daniel,
> 
> I worked with SCTP but MPTCP seems a lot better. Aside from MPTCP
> features we have to also evaluate how migration from TCP applications to
> MPTCP can be done, the easiest the better -- even if not all features
> are available. Does MPTCP overhead for a single connection affects
> traditional TCP users.... 

MPTCP does not require any change to the socket API. MPTCP already works
with existing applications provided of course that MPTCP is included in
the operating system. For example, on a host where UDP is completely
blocked by the firewall, skype works perfectly above our MPTCP
implementation in the Linux kernel. Video and voice calls work correctly
even when MPTCP is using both 3G and WiFi or when there is a handover
from 3G to WiFi. The same is true for any socket-based application.

Olivier

---

From: Scott Brim <[email-masked]>
Date: Wed, 28 Mar 2012 11:58:44 +0200

On 03/28/12 10:58, Daniel Migault allegedly wrote:
> I worked with SCTP but MPTCP seems a lot better. 

!! :-)

> their applications to adapt them to an offload context, and that 's a
> real opportunity.

I agree.  However, I believe that this is already covered by the charter
and has been an expected use case since the first MPTCP presentation to
the RRG.

FYI, a few IETFs ago when MPTCP proxies were first brought up, I
suggested that the control protocol for using them should be the same as
for MIP HAs in order to provide an evolutionary path (... and Randy
Stewart let us know that he had the same thing for SCTP back in 2001).

Scott

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 28 Mar 2012 06:44:21 -0500

Olivier,

I agree with all of your points. I also agree that we should NOT limit MPTCP to the mobile environment. But that shouldn't prohibit us from adding Mobility as one focus point to the charter. 

The same applies to proxies: They are not needed for data centers but we still seem to agree that they deserve a spot on the revised charter.

Regards,

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 11:46 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Yoshifumi Nishida
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Georg,

Olivier

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 29 Mar 2012 02:18:07 -0500

All,

One important issue to be addressed for MPTCP MOBILITY is the overhead optimization when only one path is available. In wireless access environments, this applies to a large fraction of traffic. For MPTCP MOBILITY use cases, only 1 path is used for almost all the time. 

When only 1 path is available there is no principal reason to require full-fledged 2-layer operation, i.e. insert/process DSS options or to require subflow-level buffering.

This item needs more work since such optimization should not jeopardize middle-box compliance.

Regards,

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: Wednesday, March 28, 2012 1:44 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Olivier,

Regards,

Georg

-----Original Message-----
From: Olivier Bonaventure [mailto:[email-masked]] 
Sent: Wednesday, March 28, 2012 11:46 AM
To: Hampel, K Georg (K Georg)
Cc: [email-masked]; [email-masked]; Yoshifumi Nishida
Subject: Re: [multipathtcp] Proposal for revised charter: MPTCP MOBILITY

Georg,

Olivier