Re: [multipathtcp] MPTCP Architecture Draft available

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 <alan.ford@roke.co.uk> 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:dokaspar.ietf@gmail.com]
>> Sent: 20 October 2009 17:57
>> To: Ford, Alan
>> Cc: multipathtcp@ietf.org
>> 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 <alan.ford@roke.co.uk>
> 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
>> > multipathtcp@ietf.org
>> > https://www.ietf.org/mailman/listinfo/multipathtcp
>> >
>