Subject: [multipathtcp] MPTCP Architecture Draft available

From: "Ford, Alan" <[email-masked]>
Date: Mon, 19 Oct 2009 19:32:39 +0100

Hi all,

We have started work on the beginnings of an Multipath TCP architecture
draft, combining some of the implementation separation that featured in
the -01 of the mptcp/multiaddressed draft with some architectural
considerations from Tng.

http://www.ietf.org/id/draft-ford-mptcp-architecture-00.txt

Comments welcome - but please remember this is very early days!

Cheers,
Alan

---

From: Dominik Kaspar <[email-masked]>
Date: Tue, 20 Oct 2009 18:56:36 +0200

Dear authors,

In my opinion, MPTCP has a great potential benefits for resource
pooling when a single, long-lasting, high-bitrate transport stream is
present. On the other hand, MPTCP's use of multiple paths might risk
performance degradation, which seems not to be addressed in this
draft.

For example, in our testbed, we have a host with two wireless
interfaces, a WLAN (IEEE 802.11b) interface and an HSDPA interface
with roughly the following access network characteristics:

WLAN: 600 KB/s, 10 ms RTT
HSDPA: 300 KB/s, 100 ms RTT

MPTCP would be perfect for aggregating both links, achieving 900 KB/s
and providing a better user experience for "bulk" data transfers, such
as video streaming and large file downloads.

However, if the goal is to download a large number of small-sized
files (for instance downloading and displaying a thumbnail image
gallery), a new problem arises. Due to the large difference in access
latency, the WLAN interface might be able to finish the entire
download of a single file even before a connection can be established
of the HSDPA interface. In this case, opening an MPTCP connection for
each file may result in performance degradation and it may be much
more efficient to let the WLAN interface download 67% of the files and
the HSDPA the remaining 33%...

Except from a short paragraph on "support for small transactions",
this draft seems to lack a motivation for when MPTCP should be used,
when it should not be used, and how such a decision can be made. Are
such decisions made by the Path Managers or left to the application
developer?

Best regards,
Dominik

On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan <[email-masked]> wrote:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: "Ford, Alan" <[email-masked]>
Date: Tue, 20 Oct 2009 18:34:12 +0100

Dominik,

Many thanks for your comments. The question of "when" to use MPTCP is
indeed an important one, which we will be discussing further in later
versions of this draft. The Path Manager has the task of choosing when
to use additional paths, and so I would suggest that it is the
appropriate place to take into account the needs of different types of
traffic. This could be signalled to it from the application layer, or it
could infer needs from session length, type of traffic, etc. It is at
least partially an implementation-specific issue, however. We shall
definitely take this into account in the next version of this document.

You may find some of the discussion in the Application Considerations
draft is more relevant to this topic, and we would of course be very
interested in hearing your thoughts these topics, such as the
"application requirements".

http://www.ietf.org/id/draft-scharf-mptcp-api-00.txt

Regards,
Alan

> -----Original Message-----
> From: Dominik Kaspar [mailto:[email-masked]]
> Sent: 20 October 2009 17:57
> To: Ford, Alan
> Cc: [email-masked]
> Subject: Re: [multipathtcp] MPTCP Architecture Draft available
> 
> Dear authors,
>

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 21 Oct 2009 10:36:10 +0200

Hi Alan,

True, the question of "when" to use MPTCP may largely be an
implementation-specific issue. However, in the case of resource
pooling of multiple interfaces (bandwidth aggregation), I do not yet
see how MPTCP will be able to decide how much data to send over which
interface. Of course, each subflow will naturally adapt to the
available bandwidth, but how can it be decided for a given data
segment over which path it is to be sent?

Is there a general requirement for MPTCP to monitor each path's
"absolute" bandwidth/latency/loss characteristics in order to
proportionally and optimally distribute data? I don't think such
scheduling decisions can be left to developers who might have no
knowledge about the heterogeneity of the environment their
applications will run in. The main challenge of MPTCP is not the
number of network interfaces or the type of traffic, but mostly on the
heterogeneity of the paths' characteristics.

Best regards,
Dominik

---

From: Kurt Tutschku <[email-masked]>
Date: Wed, 21 Oct 2009 11:17:47 +0200

Dear Dominik,

you are absolutely right. The heterogeneity of the paths'  
characteristics has severe impact on the performance of current  
multipath transmissions.

We demonstrated the effects with simulations and an analytical model.  
The preliminary results are available at:

K. Tutschku et al.: "Network Virtualization: Implementation Steps  
Towards the Future Internet.", KiVS 2009, Kassel, March 2009.
http://eceasst.cs.tu-berlin.de/index.php/eceasst/article/viewFile/216/218

T. Zinner et al.: "Performance Evaluation of Packet Re-ordering on  
Concurrent Multipath Transmissions for Transport Virtualization". 20th  
ITC Specialist Seminar, Hoi An, Viet nam, May 2009.
http://www.itcspecialistseminar.com/paper/itcss09_Zinner.pdf

K. Tutschku et al.: "Influence of Packet Re-ordering on Concurrent  
Multipath Transmissions for Transport Virtualization".
Technical Report No. 452, 2009. (This report is also available as a  
Paper at KIVS 2009).
http://www3.informatik.uni-wuerzburg.de/TR/tr452.pdf

A fourth, more comprehensive paper will be available soon.

Best Regards
Kurt and Thomas

Am 21.10.2009 um 10:36 schrieb Dominik Kaspar:

>>>> draft, combining some of the implementation separation that  
>>>> featured
>> in

---
Prof. Dr. Kurt Tutschku
Chair of Future Communication (Endowed by Telekom Austria)
Institute of Distributed and Multimedia Systems, Faculty of Computer  
Science
University of Vienna, Universitaetsstrasse 10/T11, 1090 Wien, Austria.

Tel: +43/1/4277-39611 Mobile: +43/664/60277-39611

http://www.cs.univie.ac.at/fc

mailto:[email-masked] or mailto:[email-masked]

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 21 Oct 2009 10:42:22 +0100

Hi Dominik,

Please have a look at our proposed congestion control draft for  
multipath, it answers some of your questions for the case when there  
is always data to send, i.e. mptcp is not application limited.

Deciding which path to choose when mptcp is application limited is  
unclear yet.

Let me briefly summarize your questions and answer them:
1. How much traffic should a multipath flow get in aggregate?
We answer this by saying it should do no worse than a single tcp on  
its best path, and it shouldn't take more path on any of its paths  
than a single TCP would. With this in mind, we compute the overall  
aggressiveness of the multipath flow (parameter alfa) dynamically,  
based on the instantaneous congestion windows and rtts of the  
individual paths.

2. How much traffic should go on individual paths, out of this  
aggregate? It is desirable to put more traffic on less congested  
paths, because this helps spread congestion better in the network  
(this is resource pooling). Our algorithm, in the long run, will  
allocate proportionally more window to paths with lower drop  
probabilities. For instance, if a path has loss rate 1% and another  
0.1% percent, our algorithm will put 10 times more window on the  
second path than on the first path. All this, while conforming to the  
stuff detailed in question 1.

Cheers,
Costin

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 21 Oct 2009 13:44:53 +0200

Hi Costin,

I see. In other words, are you assuming that the "throughput
proportion" of the paths is always equal to the "loss proportion"? If
so, is that a generally valid assumption?

For instance, continuing your example with a Path A that has a loss
rate of 1% and Path B that experiences 0.1% loss: let's also assume
that Path A has an average TCP throughput of 1 Mbit/s and Path B
achieves 2 Mbit/s. Why should the "reliable but slow" Path B get a 10
times larger window than the "unreliable but fast" Path A?

Greetings,
Dominik

On Wed, Oct 21, 2009 at 11:42 AM, Costin Raiciu <[email-masked]> wrote:
> Hi Dominik,
>
> Please have a look at our proposed congestion control draft for multipath,
> it answers some of your questions for the case when there is always data to
> send, i.e. mptcp is not application limited.
>
> Deciding which path to choose when mptcp is application limited is unclear
> yet.
>
> We answer this by saying it should do no worse than a single tcp on its best
> path, and it shouldn't take more path on any of its paths than a single TCP
> would. With this in mind, we compute the overall aggressiveness of the
> multipath flow (parameter alfa) dynamically, based on the instantaneous
> congestion windows and rtts of the individual paths.
>
> 2. How much traffic should go on individual paths, out of this aggregate? It
> is desirable to put more traffic on less congested paths, because this helps
> spread congestion better in the network (this is resource pooling). Our
> algorithm, in the long run, will allocate proportionally more window to
> paths with lower drop probabilities. For instance, if a path has loss rate
> 1% and another 0.1% percent, our algorithm will put 10 times more window on
> the second path than on the first path. All this, while conforming to the
>>>> On Mon, Oct 19, 2009 at 8:32 PM, Ford, Alan <[email-masked]>
>>>
>>> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> We have started work on the beginnings of an Multipath TCP
>>>
>>> architecture
>>>>>
>>>>> draft, combining some of the implementation separation that featured
>>>
>>> in
>>>>>

---

From: Dominik Kaspar <[email-masked]>
Date: Wed, 21 Oct 2009 13:47:13 +0200

Oops, my mistake, the example should be like this:

Path A: 1.0% loss, 2 Mbit/s
Path B: 0.1% loss, 1 Mbit/s

Dominik

---

From: Costin Raiciu <[email-masked]>
Date: Wed, 21 Oct 2009 15:09:43 +0100

Hi Dominik,

In this case the controller will allocate ten times more window on  
average to flow B. That's actually good (since B is less congested)  
as long as the multipath flow does not lose throughput in doing so.

But remember that window and throughput is not the same - in the case  
you give, the second path will probably have a much higher rtt.
In your example, if path a has one tcp flow and the multipath  
subflow, and path b the same, on aggregate mptcp will get roughly  
1mbps throughput.
To do this, mptcp controls the overall aggressiveness of the  
multipath flow by taking into account the different rtts on the two  
paths, and loss rates.
The details of how this is achieved are in the draft.

We plan to release a version of a simulator soon containing this  
implementation, so you can play with it there and see what it does.
Costin

On 21 Oct 2009, at 12:47, Dominik Kaspar wrote:

>>> multipath,
>>> aggregate? It