Re: [multipathtcp] MPTCP Architecture Draft available

[Dominik Kaspar <[e-mail]>]

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