Re: [multipathtcp] MPTCP Architecture Draft available

[Kurt Tutschku <[e-mail]>]

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:

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

---
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: [phone] Mobile: [phone]

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

mailto:[e-mail] or mailto:[e-mail]