Subject: [multipathtcp] draft charter for Multipath TCP

From: Scott Brim <[email-masked]>
Date: Sat, 25 Jul 2009 11:17:50 +0200

As a starting point for a draft charter, see
http://trac.tools.ietf.org/area/tsv/trac/wiki/MpTcpBofDescription

It lacks milestones, but those can be filled in once we agree on the
work.  Comments please.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 26 Jul 2009 19:38:34 +0300

Scott,

> Recent research has suggested that by making better use of the 
> multiple paths between endpoints we can better utilise the resources 
> within the network and thus improve resource pooling. In particular, 
> recent results include models of how multipath-capable end-systems 
> might respond to congestion signals, and what the potential benefits 
> might be (see [1] for a more details and references).
>
> If end systems could spread their load across multiple paths in the 
> right way, with the right reaction to the right congestion signals 
> from the network, then traffic would quickly move away from congested 
> or failed links in favor of available uncongested links.
>
> It is fairly intuitive to see that when multipath transport is used in 
> conjunction with congestion-dependent load-distribution, it is 
> possible to push more traffic through the network and to achieve 
> enhanced fault tolerance. Traffic will flow throught any available 
> path that has spare capacity, filling unused resources, while moving 
> away from failures and congested resources. The result is a more 
> flexible network, capable of functioning well, even when the actual 
> traffic matrix differs substantially from the traffic matrix envisaged 
> when the network was designed for.
>
> Currently used transport protocols use only one path at a time for 
> sending data. In particular TCP and DCCP use only one path and they 
> respond to congestion reducing their sending rate. SCTP on the other 
> hand, is aware of multiple paths, but it uses only one at the time, 
> reserving the alternative paths as backups in case of failure.

All good.

> The proposed work is to define the mechanisms to enable transport 
> protocols to use multiple paths simultaneously and to distribute the 
> load among the subflows of each path based on congestion.

I know that you are going to be more specific in the next paragraph, but 
the above sounds like a general purpose transport work, and I would 
really like to see the MP-TCP work be specific to TCP. We have a very 
specific proposal that has the potential to be useful. Lets be clear 
about the focus being on that.

The draft charter does not mention the ability/requirement for multipath 
TCP to pass through legacy NATs and work with legacy applications. These 
are important, and I think they should be mentioned.

> In particular, the proposed work is to extend TCP to support 
> simultaneous data exchange through multiple paths. Two complementary 
> approaches are proposed: On one hand, to define a two-ended multipath 
> TCP that uses multiple addresses a-la SCTP to obtain multiple paths 
> and that requires support from both endpoints to use them. On the 
> other hand, single ended multipath TCP, where only one of the 
> endpoints involved in the communication is multipath aware and relies 
> on multipath routing capabilities provided by the IP routing to 
> deliver data towards a legacy TCP endpoint. These two approaches 
> provide a smooth deployment model, starting with the one-ended 
> multipath TCP, that only requires one end to deploy it and it results 
> in immediate benefits, and then when multipath TCP support becomes 
> pervasive, using the two-ended multipath TCP to obtain all the 
> potential benefits.

I have my doubts about the one ended approach, but this is a good topic 
for the BOF to talk about -- what type of multipath TCP do we want to 
specify?

> The proposed work items are:
>
>     * A set of architectural guidelines for congestion dependent 
> multipath transport protocols. Since different transport protocols can 
> potentially benefit from this approach, this document describes the 
> motivations and the general approach that should be followed to enable 
> congestion dependent multipath transport.
>     * Extensions to current TCP to support the one-ended mutipath TCP.
>     * Extensions to current TCP to support the two-ended mutipath TCP.

"mutipath"

>     * A threat analysis for multipath TCP

Perhaps this should come first, and it should be understood that the two 
solution documents above need to include security mechanisms that deal 
with the threats.

>     * An extended API describing how applications can use multipath 
> transport. The API should also provide access to multipath information 
> and enable the control of the usage.

Is this a mandatory or optional piece of the architecture? I think it 
would be very useful to have an API, but I also think it is central for 
the deployment of multipath TCP that it can work with unchanged 
applications.

> The initial goal is that the documents produced by the WG will be 
> either experimental or informational. However, if when the documents 
> are ready the technology seems mature enough, the WG will consider if 
> it is appropriate to ask the IESG to advance the document as a 
> Proposed Standard.

This is a little handwavy, but may be OK at this stage.

One way to make progress in this question is to break down the required 
work into components, and see how ambitious they are. I suspect there 
are pieces which might be stable enough to become PS. But there 
certainly are other pieces that are for sure experimental at this stage.

Here's one way to break the work down:

- framework for understanding multipath transports (informational)
- threats analysis (informational)
- TCP extensions to support two-sided multipath TCP
- security mechanisms
- simple congestion algorithm, e.g., follow regular TCP for each subpath
- advanced congestion algorithm

> With respect to the work on the support for multipath in TCP, the only 
> acceptable modifications to the TCP packet format are in the form of 
> new TCP options.
Ok

Jari