Re: [multipathtcp] MPTCP Architecture Draft available

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