Re: [multipathtcp] MPTCP Architecture Draft available

[Dominik Kaspar <[e-mail]>]

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