Subject: [multipathtcp] One more version of the charter

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Sep 2009 18:31:27 +0200

Hi,

I have received some private comments plus reviewed the list discussion.
 Thus I have made a number of changes. There are quite some re-ordering
of text. Anyway I have included a wdiff to help you see the changes
compared to the previous version I sent out.

I have removed the text about single end being out of scope. I don't see
there being a point of having that text present. If the WG will pick it
up, it anyway requires a recharter. So lets take that discussion when we
have completed the charter items.

Please comment on 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: 090915 
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. Initially the WG will only produced documents that is 
either experimental or informational. 

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. A long term goal is to gather 
experience whether 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. 

To reach 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. 

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. The impact on different 
classes of applications must be considered and documented. An extended 
API is to 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 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 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 analyse how MPTCP interacts with existing infrastructure elements 
and address agility mechanisms, such as HIP and SHIM6. Results of 
experiment performed during the development should also be included or 
referenced. 

b. A security threat analysis for multipath TCP. Using multiple sub-
flows over multiple paths and addresses opens up for new types of 
vulnerabilities and attacks, these and their mitigations needs to be 
documented. 

c. 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 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, 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 and mitigation of threats 
introduced by these specific MPTCP extensions.

e. Application considerations This will be a 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 
enables the control of the 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
Multipath TCP Working Group Charter (Draft)
===========================================
Version: 090907 090915
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 Initially the WG will only produced documents that is
either experimental or informational.

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. A long term goal is to gather
experience whether 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.

To reach 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

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 modification. The impact on different
classes of applications must be considered and documented. In due course, an An extended
API is expected to be defined to allow applications to express particular
preferences over for how MPTCP
operation, operates, and gather get additional 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.
MPTCP- specific run-time events.

It is also essential that all new security 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 It will
also include a summary analyse how MPTCP interacts with existing infrastructure elements
and address agility mechanisms, such as HIP and SHIM6. Results of
experiment performed during the results of experiments carried out. development should also be included or
referenced.

b. A security threat analysis for multipath TCP. Using multiple sub-
flows over multiple paths and addresses opens up for new types of
vulnerabilities and attacks, these and their mitigations needs to be
documented.

c. 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 pursue additional
work in these areas.

c.

d. Extensions to current TCP to support mutli-addressed mutipath 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, 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 and mitigation of threats
introduced by these specific MPTCP extensions.

d.

e. 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
enables 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:

Mar 2010 - Established WG consensus on the Architecture
Aug 2010 - Submit to IESG Architectural Guidelines and Security Threat Analysis as an informational RFC 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: Scott Brim <[email-masked]>
Date: Tue, 15 Sep 2009 12:50:01 -0400

These suggestions are all editorial ...

Excerpts from Magnus Westerlund on Tue, Sep 15, 2009 06:31:27PM +0200:
> 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. Initially the WG will only
> produced documents that is either experimental or informational. 

-> Initially the WG will only produce documents that are experimental
or informational.

> protocol modifications are deployable in an unmodified Internet and
> work with existing unmodified applications. A long term goal is to
> gather experience whether 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. 

This paragraph seems to say the same thing twice.  How about replacing
it all with:

  Key goals of the working group are to gather experience whether
  MPTCP can be deployed and used without significant changes to
  existing Internet infrastructure, be used with unmodified
  applications, and is stable and congestion safe over the wide range
  of existing Internet paths. 

> 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. 
> 
> 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. The impact on
> different classes of applications must be considered and documented.

must -> will    (this is not a protocol spec, it's a charter)

> An extended API is to be defined to allow applications to express

is to be -> will

> particular preferences for how MPTCP operates, and get additional
> information about MPTCP- specific run-time events. 

MPTCP- specific -> MPTCP-specific

> The following components will be defined:

The application considerations draft is not a "component", so how
about this instead of the heading here:

> a. An architectural framework for congestion dependent multipath 

congestion dependent -> congestion-dependent

> 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 analyse how MPTCP interacts with existing infrastructure
> elements and address agility mechanisms, such as HIP and SHIM6.

address -> other address   (MPTCP offers address agility)

> Results of experiment performed during the development should also

experiment -> experiments

> be included or referenced. 
> 

up for new -> up new

> vulnerabilities and attacks, these and their mitigations needs to be

vulnerabilities and attacks.  These and their mitigations need to be

> documented. 
> 
> c. 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 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, 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

This document will also include   (must -> will; no "an")

> analysis and mitigation of threats introduced by these specific
> MPTCP extensions.
> 

An application considerations document, presenting the

> changes, and will include an extended API describing how

and including

> 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 enables the control of the 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:
> 

Thanks ... Scott

---

From: "Laganier, Julien" <[email-masked]>
Date: Tue, 15 Sep 2009 10:23:55 -0700

Hi,

May I suggest: s/HIP and SHIM6/MIPv6, SHIM6, and HIP/

--julien

> -----Original Message-----
> From: [email-masked] [mailto:multipathtcp-
> [email-masked]] On Behalf Of Magnus Westerlund
> Sent: Tuesday, September 15, 2009 9:31 AM
> To: [email-masked]
> Subject: [multipathtcp] One more version of the charter
> 
> Hi,
> 
> I have removed the text about single end being out of scope. I don't
> see there being a point of having that text present. If the WG will
> pick it up, it anyway requires a recharter. So lets take that
> discussion when we have completed the charter items.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Sep 2009 10:02:36 +0200

Thanks for the quick comments

I have introduced your suggested changes into this version. A Wdiff
compared with the previous version is included.

I think this charter is good enough to send to the IESG. However, if you
have more suggestions for improvements then there is still time to
introduce them.

Cheers

Magnus Westerlund

Version: 090916 

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. Initially the WG will only produce documents that are 
experimental or informational. 

Key goals of the working group are to gather experience whether MPTCP 
can be deployed and used without significant changes to existing 
Internet infrastructure, be used with unmodified applications, and is 
stable and congestion safe over the wide range of existing Internet 
paths. 

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. 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. 

The following documents will be defined:

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 analyse how MPTCP interacts with existing infrastructure elements 
and other address agility mechanisms, such as Mobile IP, HIP and SHIM6. 
Results of experiment performed during the development should also be 
included or referenced. 

b. A security threat analysis for multipath TCP. Using multiple sub-
flows over multiple paths and addresses opens up new types of 
vulnerabilities and attacks. These and their mitigations needs to be 
documented. 

This document will also include analysis and mitigation of threats 

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 the 
control of the usage. 

Goals and Milestones:

Version: 090915 090916

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. Initially the WG will only produced produce documents that is
either are
experimental or informational.

A key measure

Key goals 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. A long term goal is to gather experience whether MPTCP
can be deployed and used without significant changes to existing
Internet infrastructure, be used with unmodified applications, and is
stable and congestion safe over the wide range of existing Internet
paths.

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. The impact on different
classes of applications must will be considered and documented. An extended
API is to will be defined to allow applications to express particular
preferences for how MPTCP operates, and get additional information about
MPTCP- specific
MPTCP-specific run-time events.

The following components documents will be defined:

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 analyse how MPTCP interacts with existing infrastructure elements
and other address agility mechanisms, such as Mobile IP, HIP and SHIM6.
Results of experiment performed during the development should also be
included or referenced.

b. A security threat analysis for multipath TCP. Using multiple sub-
flows over multiple paths and addresses opens up for new types of
vulnerabilities and attacks, these attacks. These and their mitigations needs to be
documented.

This document must will also include an analysis and mitigation of threats

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

Goals and Milestones:

---

From: <[email-masked]>
Date: Wed, 16 Sep 2009 12:30:01 +0100

Some comments:

I would replace the second paragraph with something like:

"A key goal of the working group is to ascertain (through suitable experimentation) whether MPTCP can be deployed and used safely in the existing Internet. E.g. without significant changes to existing infrastructure, with unmodified applications and is stable over the wide range of existing Internet paths."

Then the 3rd para needs tweaking to match:

"This goal will be achieved in part through the provision of a modular architecture ..."

Having said that I think I disagree that the modular architecture is actually related specifically to the goal of ensuring deployability and congestion safety. To me the main point of the modular architecture is that it enables much more precise experiments to be run to test the behaviour of each element of the system. And it allows for multiple solutions to co-exist peacefully (well hopefully peacefully...)

"...potentially provide multiple paths between the endpoints." Doesn't quite seem to me to express what is really meant. I guess what is important is that if at least 1 endpoint has >1 address then there is >1 logical path between the endpoints, at least from the perspective of the end-systems. So the "potentially" here is presumably meant to mean that the multiple paths may be actually different. {Incidentally what do we do if both ends have different local use addresses but actually both are connecting through  a home gateway type device?}

" Whilst this will require modifications to the TCP stack at the endpoints," --> " Whilst this will require modifications to the TCP 
stack at both endpoints,"

Should we add a "but" to the API section (e.g. "but the use of this API is not required to benefit from MPTCP")

Surely we are going to WRITE the documents, not define them? 

Last sentence of document a. "Results of experiment" --> either "Results of experiments" or "The results of any experiments"

Missing full stop between summary of document c and description (e.g. b "algorithm This" --> "algorithm. This". Might it be clearer to say "Initially this will specify..."?

Document d. there seems to be a repetition/conflict: "include a basic security model" and "analysis and mitigation of threats". These should perhaps be replaced with a single sentence...

Application considerations sounds wrong somehow. I can see exactly what is meant, but considerations doesn't quite seem the perfect word. Having said that I can't think what word would be better...

Also does the API doc need to give examples of the different cases in which MPTCP might provide new functionality? I believe Iljitsch had some thoughts in this area to do with things like: improving throughput, selecting shortest RTT, selecting lowest power, lowest cost, etc). Or is this out of scope?

Toby

> Sent: 16 September 2009 09:03
> To: Magnus Westerlund
> Cc: [email-masked]
> Subject: Re: [multipathtcp] One more version of the charter
> 
> I think this charter is good enough to send to the IESG. However, if
> you have more suggestions for improvements then there is still time to
> introduce them.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Sep 2009 17:10:17 -0700

Hi, all,

I reviewed both the original charter and the updated version, and don't
see the concerns I raised in Stockholm addressed. This work is solving
three independent problems, and it remains useful to address these
independently, as solutions are independently useful:

	- multiple paths
	- multiple addresses used in serial
	- multiple addresses used concurrently

As noted in Stockholme, the charter perpetuates the fallacy that paths
correlate to endpoint addresses; addresses can be aliased, and single
addresses can experience multiple paths (in sequence or concurrently). I
do appreciate attempts to separate path discovery from the rest of the
solution, but this is *both* multipath and multiendpoint, and the two
are not necessarily coupled - that needs to be clear.

This could be noted in the charter and the milestones. Further, it
suggests that the group name continues to be misleading - AFAICT, it the
focus is on multiple addresses and their possible implications, rather
than focusing on multiple paths.

Further, and perhaps more importantly, if both endpoints are modified,
and thus backward compatibility is not addressed, this can - and should
- - use a different protocol number (and name) than TCP, as it has no
benefit from being TCP. One possble solution is to either require
backward compatibility (and then a half-deployed solution needs to be
included), or to define compatibility as being at the API.

I.e., if this mechanism is inside TCP just to save a handshake (i.e., to
ask for TCP-MP and to get TCP as a consolation prize if not supported),
that's a poor reason to work inside the constraints of a legacy
protocol. If you want to define compatibility at the API, you do not
need to call this solution TCP, nor do you need to use much of the rest
of TCP. E.g., it might be useful to fix other aspects of TCP, such as
allowing negotiation of which end holds TIME-WAIT, increasing the option
space, etc.

Some other specific items that should be addressed in addition to
congestion control, and would be useful to include (and again, for which
a solution unencumbered by legacy TCP might be useful if both ends are
modified anyway):

	- MTU discovery
	- NAT interactions
	- API issues (and whether the original endpoint pair needs to be
	active to allow other endpoints to be used or not)

Joe

---

From: John Leslie <[email-masked]>
Date: Thu, 17 Sep 2009 12:50:30 -0400

> are not necessarily coupled - that needs to be clear.

   Joe raises an important point: that the correlation of multiple IP
addresses to multiple paths is often not 1:1.

   In fact, we recognize this: and we treat it in the congestion-control
algorithm; but this is not obvious from the charter text.

   At this point, MPTCP is on the September 24 agenda for the IESG, under
"Proposed for IETF Review".

https://datatracker.ietf.org/iesg/agenda/

   The text the IESG will consider is pretty much frozen, but it can be
modified before the charter goes out for External Review (which is
almost certain to be the next step. 

   Thus, it's perfectly reasonable for us to discuss how to make this
clearer in the charter, and recommend text that Magnus could suggest to
the IESG for the charter which goes for external review.

> This could be noted in the charter and the milestones.

   Send text...

> Further, it suggests that the group name continues to be misleading -
> AFAICT, it the focus is on multiple addresses and their possible
> implications, rather than focusing on multiple paths.

   I would disagree there: IMHO the focus is on what can be gained from
multiple paths, but recognizing that it may be difficult to tell whether
we actually have multiple paths.

   (I, BTW, envision MPTCP to lead into situations where we're quite
confident multiple paths _do_ exist.)

> and thus backward compatibility is not addressed, this can - and
> should - - use a different protocol number (and name) than TCP, as it
> has no benefit from being TCP.

   I thoroghly disagree with Joe here. TCP over the years has had many
enhancements that require "modification" of both ends. Further, we
expect that most applications will be able to use it exactly as they
now use TCP -- just as applications have done for a steady stream of
TCP modifications over the years.

> One possble solution is to either require backward compatibility
> (and then a half-deployed solution needs to be included), or to
> define compatibility as being at the API.

   I appreciate that Joe is looking towards a satisfactory path.

> If you want to define compatibility at the API, you do not need to
> call this solution TCP, nor do you need to use much of the rest of
> TCP. E.g., it might be useful to fix other aspects of TCP, such as
> allowing negotiation of which end holds TIME-WAIT, increasing the
> option space, etc.

   There are certainly other features of TCP that could use work...

   But this project seems to be a poor match for that work. We're
looking towards experimenting in multiple paths, which will certainly
include how to tell _whether_ multiple paths exist and how to "find"
shared bottlenecks -- even though we're not sure we'll ever progress
beyond using the congestion-control algorithm to end-run those issues.

> congestion control, and would be useful to include (and again, for
> which a solution unencumbered by legacy TCP might be useful if both
> ends are modified anyway):
> 
> - MTU discovery

   This is indeed a mess, and I'd love to see a world in which less
than a dozen WGs need to be looking for independent "fixes"!

> - NAT interactions

   I am really pessimistic about that ever folding into a TCPbis
API. If it ever does, I expect the solution to come from Locator-EID-
split work.

>   active to allow other endpoints to be used or not)

   An excellent point! Perhaps we can fit it into our work; but I
think it _really_ premature to put it into our original charter.

--
John Leslie <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 17 Sep 2009 10:13:04 -0700

John Leslie wrote:
Point of clarification below.

...
> looking towards experimenting in multiple paths,...

The list of items I suggest are those for which multiple paths affects
existing - though not perfect - solutions. I'm not suggesting this is a
place for a new mechanism per se, but it is definitely a place where the

>> - MTU discovery

The MTU is a path property that having multiple paths complicates -
especially when a segment needs to be retransmitted on a different path
than originally sent (because the original path no longer exists, e.g.).

>> - NAT interactions

If you got through a NAT, it's very possible that your multiple
endpoints are no longer multiple.

> think it _really_ premature to put it into our original charter.

IMO, addressing the API -- and MTU and NAT issues - should be in the
milestones. It need not be solved or limited in the charter, though.

Joe

---

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

> "A key goal of the working group is to ascertain (through suitable experimentation) whether MPTCP can be deployed and used safely in the existing Internet. E.g. without significant changes to exist…

I think this text may be indicating that the WG will perform
experiments. Rather than produce specifications that allow people to
perform experiments. It might be that already the current text is
pointing to much in the direction. I think the goal of the design is in
the text.

> "This goal will be achieved in part through the provision of a modular architecture ..."

I think removing the initial part of that paragraph is a better solution
and resolves your next issue at the same time.

> stack at both endpoints,"

Yes, will add.

> Should we add a "but" to the API section (e.g. "but the use of this API is not required to benefit from MPTCP")

No, but I will clarify the first sentence that the unchanged
applications will get some benefit from multipath.

> Surely we are going to WRITE the documents, not define them?

I have changed this to:
"The following items will be worked on:" as I don't want to require a
strict point for for point document structure.

> Last sentence of document a. "Results of experiment" --> either "Results of experiments" or "The results of any experiments"

Ok.

> Missing full stop between summary of document c and description (e.g. b "algorithm This" --> "algorithm. This". Might it be clearer to say "Initially this will specify..."?

Yes, I have made other changes see, new proposal.

> Document d. there seems to be a repetition/conflict: "include a basic security model" and "analysis and mitigation of threats". These should perhaps be replaced with a single sentence...
Yes, changed that also.

> Application considerations sounds wrong somehow. I can see exactly what is meant, but considerations doesn't quite seem the perfect word. Having said that I can't think what word would be better...

Well, it stays like this until someone suggest something better.

> Also does the API doc need to give examples of the different cases in which MPTCP might provide new functionality? I believe Iljitsch had some thoughts in this area to do with things like: improvin…

I don't think the charter needs to be detailed in this area.

Cheers

Magnus Westerlund

---

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

Hi Joe,

Thanks for the comments. See comments inline.

> are not necessarily coupled - that needs to be clear.

So, multi-end-point can result in multipath, at least partial but not
guaranteed so. Thus if you are doing multi-end-point, you needs to
handle multipath, but also the failure to get multi-path. But, yes we
are going to currently exclude the cases where you get multi-path from a
single address.

My question is shouldn't a solution for multi-end-point handle most
cases of multi-path behavior and allow for future extensions around
using multiple paths achieved from a single address?

> than focusing on multiple paths.

Yes, I thinks some clarification should be added. I have a draft, but
would appreciate comments or suggestion for improvements.

> - use a different protocol number (and name) than TCP, as it has no

I think you are correct with the exception for one thing. NAT traversal!
The alternative as I see it is to build the concurrent multi-end-point
reliable byte stream protocol directly on top of UDP. Are you suggesting
we should do that? Because building it on a new protocol number is the
same as saying, you can't experiment with it over current Internet.

> 	active to allow other endpoints to be used or not)

I think these are all issues that the WG can and need to discuss. Do you
really think they need to be explicitly mentioned in the charter?

Cheers

Magnus Westerlund

---

From: "SCHARF, Michael" <[email-masked]>
Date: Tue, 22 Sep 2009 08:56:15 +0200

> > Also does the API doc need to give examples of the 
> different cases in which MPTCP might provide new 
> functionality? I believe Iljitsch had some thoughts in this 
> area to do with things like: improving throughput, selecting 
> shortest RTT, selecting lowest power, lowest cost, etc). Or 
> is this out of scope?
> 

I agree. Of course, the document on the API should address exactly these
issues, and I think that it will propose a small number of "profiles" to
deal with potentially different application requirements or preferences.
But this is to be discussed. Any ideas are welcome...

Michael

---

From: Joe Touch <[email-masked]>
Date: Tue, 22 Sep 2009 10:32:57 -0700

Hi, Magnus,

> are going to currently exclude the cases where you get multi-path from a

That needs to be stated, and the reason for it stated as well. I don't
understand the reason for it - I'm guessing you're all thinking that
"correlates to address" means that the path can be "controlled by
selection of the address" - which isn't a given either.

> using multiple paths achieved from a single address?

The former is true, but the latter is not. If you want it to be, you
need to state that as a requirement.

> same as saying, you can't experiment with it over current Internet. 

I've had this debate on numerous lists before.

YNAT traversal is not a good reason to modify both ends of an existing
protocol rather than using a new protocol number.

You won't get past NATs just by using the TCP or UDP protocol numbers.
when you change the protocol itself, you change other things NATs do to
packets. If the goal is NAT traversal, the only solution is that all
protocols ought to be developed not only on TCP, but on HTTP on TCP.

> really think they need to be explicitly mentioned in the charter?

They need to be mentioned, and included in the charter. If the WG is
creating a solution that fails to address any of the above, it will be
useless in the current Internet.

Joe