[Iccrg] Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols"

[Michael Tüxen]

Dirceu,

no, I have not received any feedback. I pinged the authors of the
ID directly yesterday.

Best regards
Michael

On Feb 1, 2011, at 3:31 AM, Dirceu Cavendish wrote:

> Michael,
> 
> Did you get off (iccrg) list response to your point (2) below? I have similar concerns to yours...
> 
> Dirceu
> 
> From: Michael Tüxen <Michael.Tuexen at lurchi.franken.de>
> Cc: multipathtcp at ietf.org; iccrg <iccrg at cs.ucl.ac.uk>
> Sent: Wed, January 26, 2011 3:25:20 PM
> Subject: [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion Control for Multipath Transport Protocols"
> 
> Hi Philip,
> 
> I have some questions regarding section 3:
> 
> (1) It is stated:
>     "Since we require that the total throughput is no worse
>     than the throughput a single TCP would get on the best path..."
>     and later:
>     "The formula is derived by equalizing the rate of the multipath flow
>     with the rate of a TCP running on the best path, and solving for
>     alpha."
>     So what is considered here:
>     * throughput in bytes/sec
>     * rate in packets/sec
>     * rate in bytes/sec
> 
> (2) I don't understand the formula for alpha completely. I understand how
>     the corresponding formula in "Practical Congestion Control for Multipath
>     Transport Protocol" is derived. However, there the congestion windows
>     are measured in MTUs (or MSS or packets). So it is more packet rate
>     based. I could understand the formula in the ID if cwnd_i / mss_i would
>     be used instead of cwnd_i * mss_i. So is it a typo or could someone provide
>     a hint why cwnd_i * mss_i is used.
> 
> Best regards
> Michael
> 
> On Jan 19, 2011, at 3:25 PM, <philip.eardley at bt.com> <philip.eardley at bt.com> wrote:
> 
> > The Multipath TCP WG has developed a congestion control algorithm that enables a TCP connection to use multiple paths.  
> > http://tools.ietf.org/html/draft-ietf-mptcp-congestion
> >  
> > We’re hoping to WG Last Call this document in February, so it would be great if anyone from ICCRG could review it
> >  
> > Thanks,
> > Phil & Yoshifumi
> > MPTCP WG Chairs
> >  
> > Abstract
> >  
> >    Often endpoints are connected by multiple paths, but communications
> >    are usually restricted to a single path per connection.  Resource
> >    usage within the network would be more efficient were it possible for
> >    these multiple paths to be used concurrently.  Multipath TCP is a
> >    proposal to achieve multipath transport in TCP.
> >  
> >    New congestion control algorithms are needed for multipath transport
> >    protocols such as Multipath TCP, as single path algorithms have a
> >    series of issues in the multipath context.  One of the prominent
> >    problems is that running existing algorithms such as TCP New Reno
> >    independently on each path would give the multipath flow more than
> >    its fair share at a bottleneck link traversed by more than one of its
> >    subflows.  Further, it is desirable that a source with multiple paths
> >    available will transfer more traffic using the least congested of the
> >    paths, hence achieving resource pooling.  This would increase the
> >    overall utilization of the network and also its robustness to
> >    failure.
> >  
> >    This document presents a congestion control algorithm which couples
> >    the congestion control algorithms running on different subflows by
> >    linking their increase functions, and dynamically controls the
> >    overall aggresiveness of the multipath flow.  The result is a
> >    practical algorithm that is fair to TCP at bottlenecks while moving
> >    traffic away from congested links.
> >  
> > _______________________________________________
> > multipathtcp mailing list
> > multipathtcp at ietf.org
> > https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
>