Re: [multipathtcp] MPTCP Architecture Draft available

[Costin Raiciu <[e-mail]>]

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:

> 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
>
> On Wed, Oct 21, 2009 at 1:44 PM, Dominik Kaspar  
> <[e-mail]> wrote:
>> 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  
>> <[e-mail]> 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.
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> On 21 Oct 2009, at 09:36, Dominik Kaspar wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> On Tue, Oct 20, 2009 at 7:34 PM, Ford, Alan  
>>>> <[e-mail]> wrote:
>>>>>
>>>>> 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:[e-mail]]
>>>>>> Sent: 20 October 2009 17:57
>>>>>> To: Ford, Alan
>>>>>> Cc: [e-mail]
>>>>>> Subject: Re: [multipathtcp] MPTCP Architecture Draft available
>>>>>>
>>>>>> 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  
>>>>>> <[e-mail]>
>>>>>
>>>>> 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
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> multipathtcp mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>>>>>>
>>>>>
>>>> _______________________________________________
>>>> multipathtcp mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>>>
>>>
>>