Re: [multipathtcp] MPTCP Architecture Draft available

[Costin Raiciu <[e-mail]>]

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