Subject: [multipathtcp] MPTCP recharter - revised text

From: <[email-masked]>
Date: Fri, 13 Apr 2012 09:21:16 +0100

Here's an attempt at the revised charter, trying to capture the ML discussion
On the proxies, it's clear there is no consensus to include the "4th point of view" (http://www.ietf.org/mail-archive/web/multipathtcp/current/msg01744.html) where neither end host runs mptcp. On the 2nd & 3rd points of view (proxy with one end running mptcp, and anchor with both ends running mptcp), there is consensus to explore this but we don't believe there is consensus to do an experimental spec.
On the other topics I think everyone is in agreement.

Please send any bashing on this as soon as possible, so we can get it into the next IESG telechat for approval.
Thanks
Phil & Yoshifumi.

==
The Multipath TCP (MPTCP) working group develops mechanisms that add the capability of simultaneously using multiple paths to a regular TCP session. 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. MPTCP assumes that both peers are modified and that 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).

In its initial charter 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 IP addresses at one or both ends. It includes a basic security solution.
e. Application Interface Considerations. It summarises 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 to progress various aspects of MPTCP.
The first goal of the working group is to create a bis version of the protocol document on the Standards track. This develops the current Experimental document (item d above), incorporating experience from (for example) implementations, interoperability events, experiments, usage scenarios, protocol corner cases, and feedback from TCPM. There already exists a reference Linux implementation and other implementation and experimental 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 document implementation advice. The current documents have several points where an implementer may benefit from guidance, for example about heuristics such as buffer sizing, or from advice about alternative implementations such as bump-in-the-stack.

The working group will also explore several of the proposed use cases for MPTCP in more detail, to ensure that MPTCP works well in practice. Practical work is highly encouraged. Likely use cases are to offload traffic from 3G to Wifi, and to manage traffic within a data centre. Another scenario is to enable operation of a single-homed, MPTCP end host without changing the MPTCP protocol.

Finally, the working group will explore whether an MPTCP-aware middlebox would be useful, where at least one end host is MPTCP-enabled. For example, potentially helping MPTCP's incremental deployment by allowing only one end host to be MPTCP-enabled and the middlebox acts as an MPTCP proxy for the other end host, which runs TCP; and potentially helping some mobility scenarios, where the middlebox acts as an anchor between two MPTCP-enabled hosts. The working group will detail what real problems an MPTCP-enabled middlebox might solve, how it would impact the Multipath TCP architecture (RFC6182), what proxy approach might be justified as compared against alternative solutions to the problems, and the likely feasibility of solving the technical and security issues.

Goals and Milestones:
Dec 2012  Consensus on what high-level changes are needed to the current MPTCP Experimental document in order to progress it on the standards track
April 2013  Implementation advice (Informational) to IESG
August 2013 Use cases (Informational) to IESG
Dec 2013 MPTCP-enabled middleboxes (Informational) to IESG
Dec 2013  MPTCP standards track protocol to IESG
Jan 2014 Re-charter or close

---

From: Rolf Winter <[email-masked]>
Date: Fri, 13 Apr 2012 10:14:52 +0000

Hi,

and sorry for being late with this. 

What I was missing in the list was one point that was, albeit briefly, discussed during the meeting. What about working on DHCP options to allow single-homed multi-path TCP capable end-host to make actual use of multiple paths in the network (see http://tools.ietf.org/html/draft-wr-mptcp-single-homed-01). No modifications to MPTCP necessary but useful in deployments where hosts are single-homed but multiple upstreams exist (like SoHo network with 3G and DSL, campus network connected to two providers etc.). 

Comments?

Best,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Freitag, 13. April 2012 10:21
> To: [email-masked]
> Subject: [multipathtcp] MPTCP recharter - revised text
> 
> On the proxies, it's clear there is no consensus to include the "4th
> point of view" (http://www.ietf.org/mail-
> archive/web/multipathtcp/current/msg01744.html) where neither end host
> runs mptcp. On the 2nd & 3rd points of view (proxy with one end running
> mptcp, and anchor with both ends running mptcp), there is consensus to
> explore this but we don't believe there is consensus to do an
> experimental spec.
> 
> Please send any bashing on this as soon as possible, so we can get it
> into the next IESG telechat for approval.
> 
> Thanks
> 
> Phil & Yoshifumi.
> 
> 
> 
> ==
> 
> The Multipath TCP (MPTCP) working group develops mechanisms that add
> the capability of simultaneously using multiple paths to a regular TCP
> session. 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.
> MPTCP assumes that both peers are modified and that 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).
> 
> 
> 
> 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.
> 
> 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 IP addresses at one or both ends. It
> includes a basic security solution.
> 
> e. Application Interface Considerations. It summarises 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 first goal of the working group is to create a bis version of the
> protocol document on the Standards track. This develops the current
> Experimental document (item d above), incorporating experience from
> (for example) implementations, interoperability events, experiments,
> usage scenarios, protocol corner cases, and feedback from TCPM. There
> already exists a reference Linux implementation and other
> implementation and experimental 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 document implementation advice. The current
> documents have several points where an implementer may benefit from
> guidance, for example about heuristics such as buffer sizing, or from
> advice about alternative implementations such as bump-in-the-stack.
> 
> 
> 
> The working group will also explore several of the proposed use cases
> for MPTCP in more detail, to ensure that MPTCP works well in practice.
> Practical work is highly encouraged. Likely use cases are to offload
> traffic from 3G to Wifi, and to manage traffic within a data centre.
> Another scenario is to enable operation of a single-homed, MPTCP end
> host without changing the MPTCP protocol.
> 
> 
> 
> Finally, the working group will explore whether an MPTCP-aware
> middlebox would be useful, where at least one end host is MPTCP-enabled.
> For example, potentially helping MPTCP's incremental deployment by
> allowing only one end host to be MPTCP-enabled and the middlebox acts
> as an MPTCP proxy for the other end host, which runs TCP; and
> potentially helping some mobility scenarios, where the middlebox acts
> as an anchor between two MPTCP-enabled hosts. The working group will
> detail what real problems an MPTCP-enabled middlebox might solve, how
> it would impact the Multipath TCP architecture (RFC6182), what proxy
> approach might be justified as compared against alternative solutions
> to the problems, and the likely feasibility of solving the technical
> and security issues.
> 
> 
> 
> 
> 
> Goals and Milestones:
> 
> Dec 2012  Consensus on what high-level changes are needed to the
> current MPTCP Experimental document in order to progress it on the
> standards track
>

---

From: <[email-masked]>
Date: Fri, 13 Apr 2012 14:01:14 +0100

Investigating the idea is included
> host without changing the MPTCP protocol.

Perhaps it would be worth adding a few ideas to explain the scenario better?

For defining dhcp options, would the dhc wg be better? (havent followed the group, so dont know if would be in their scope)

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: 13 April 2012 11:15
To: Eardley,PL,Philip,DUB8 R; [email-masked]
Subject: RE: MPTCP recharter - revised text

Hi,

Comments?

Best,

Rolf

---

From: Olivier Bonaventure <[email-masked]>
Date: Fri, 13 Apr 2012 15:14:09 +0200

Rolf,
> What I was missing in the list was one point that was, albeit briefly, discussed during the meeting. What about working on DHCP options to allow single-homed multi-path TCP capable end-host to make…

Did you present this work to MIF ? Although I do not follow the work in
the MIF WG, it seems to be in scope and MIF has been developing DHCP
extensions.

Olivier

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

---

From: Rolf Winter <[email-masked]>
Date: Fri, 13 Apr 2012 13:24:46 +0000

Hi,

AFAICT, the work will be homed in the WG to which the DHCP options apply. The DHC WG makes sure it makes sense from a DHCP perspective and review the doc. 

As typical deployment scenario take a SoHo network with a wireless router that has both 3G and DSL or cable (readily available on the market from e.g. Netgear). Other scenarios are campus networks such as universities or companies that have two (or more) providers or multiple links to the same provider (also not uncommon). In these scenarios, most hosts are single-homed (e.g. PC computers typically are connected to a wall plug or switch and that's it. Personally, I think this will hold true for the future for various reasons such as cost (cable, switch ports etc.)). Using the DHCP extensions and a particular gateway router configuration works perfectly fine (we did trials and it was easy to configure the router but that is all described in the draft).

Best,

Rolf

> From: [email-masked] [mailto:[email-masked]]
> Sent: Freitag, 13. April 2012 15:01
> To: Rolf Winter; [email-masked]
> For defining dhcp options, would the dhc wg be better? (havent followed
> the group, so dont know if would be in their scope)
> 
> 
> What I was missing in the list was one point that was, albeit briefly,
> discussed during the meeting. What about working on DHCP options to
> allow single-homed multi-path TCP capable end-host to make actual use
> of multiple paths in the network (see http://tools.ietf.org/html/draft-
> wr-mptcp-single-homed-01). No modifications to MPTCP necessary but
> useful in deployments where hosts are single-homed but multiple
> upstreams exist (like SoHo network with 3G and DSL, campus network
> connected to two providers etc.).
> 
> Comments?
> 
> Best,
> 
> Rolf
> 
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> > runs mptcp. On the 2nd & 3rd points of view (proxy with one end
> > running mptcp, and anchor with both ends running mptcp), there is
> > consensus to explore this but we don't believe there is consensus to
> > do an experimental spec.
> >
> > have multiple addresses, which often results in different network
> > paths that are at least partially divergent (however, note there is
> no

---

From: Rolf Winter <[email-masked]>
Date: Fri, 13 Apr 2012 13:29:58 +0000

Olivier,

Thanks for the pointer. I didn't look into the recent MIF docs either and I have to admit I need to do some homework here. But I would assume that this is A) particular to MPTCP and B) there is only a single interface (albeit two (or more) virtual ones after the DHCP processing is over). I'll look around for mechanisms which we could leverage. 

Best,

Rolf

> From: Olivier Bonaventure [mailto:[email-masked]]
> Sent: Freitag, 13. April 2012 15:14
> To: Rolf Winter
> Cc: [email-masked]; [email-masked]
> Subject: Re: [multipathtcp] MPTCP recharter - revised text
> 
> Rolf,
> >

---

From: Lukasz Budzisz <[email-masked]>
Date: Fri, 13 Apr 2012 15:32:16 +0200

Rolf,
have you checked our proposal for scenario with single-homed hosts 
scenario: http://www.ietf.org/id/draft-ayar-transparent-sca-proxy-00.txt

BR,
Lukasz

---

From: Rolf Winter <[email-masked]>
Date: Fri, 13 Apr 2012 13:48:49 +0000

I did and voiced my dislike during the meeting.

> From: Lukasz Budzisz [mailto:[email-masked]]
> Sent: Freitag, 13. April 2012 15:32
> To: Rolf Winter
> Cc: [email-masked]
> > AFAICT, the work will be homed in the WG to which the DHCP options
> apply. The DHC WG makes sure it makes sense from a DHCP perspective and
> review the doc.
> >
> > As typical deployment scenario take a SoHo network with a wireless
> router that has both 3G and DSL or cable (readily available on the
> market from e.g. Netgear). Other scenarios are campus networks such as
> universities or companies that have two (or more) providers or multiple
> links to the same provider (also not uncommon). In these scenarios,
> most hosts are single-homed (e.g. PC computers typically are connected
> to a wall plug or switch and that's it. Personally, I think this will
> hold true for the future for various reasons such as cost (cable,
> switch ports etc.)). Using the DHCP extensions and a particular gateway
> router configuration works perfectly fine (we did trials and it was
> easy to configure the router but that is all described in the draft).
> >
> > Best,
> >
> > Rolf
> >
> >

---

From: <[email-masked]>
Date: Wed, 18 Apr 2012 13:33:34 +0100

Suggest we include the single-homed idea to the extent it's in the draft charter at the moment, ie as Info. The work can analyse what the relationship is with MIF and what new mechanism might be needed. Although there is a Milestone for the Info work, it's of course OK for (some of) it to be done earlier - which might trigger new mechanism work in mptcp or another wg.

I clarified the single-homed sentence in the charter:
Another scenario is to enable, without changing the MPTCP protocol, operation of a single-homed, MPTCP end host on a campus network that has multiple providers.

Let's see what the iesg makes of it
Thanks,

-----Original Message-----
From: Rolf Winter [mailto:[email-masked]] 
Sent: 13 April 2012 14:30
To: [email-masked]
Cc: Eardley,PL,Philip,DUB8 R; [email-masked]
Subject: RE: [multipathtcp] MPTCP recharter - revised text

Olivier,

Best,

Rolf