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

Michael Tüxen Michael.Tuexen at lurchi.franken.de
Tue Feb 1 20:30:34 GMT 2011


On Feb 1, 2011, at 4:01 PM, Costin Raiciu wrote:

> Hi Michael, 
> 
> Sorry for the late reply - we haven't slept much lately because of the Sigcomm deadline.
Hi Costin,

no problem...
> 
> When aiming for the same throughput as tcp on the best path, we equalize rates in bytes per second.
So you want the same throughput in bytes/sec as TCP for the best path, not the
same packets/sec as TCP for the best path, right?
> 
> I have analyzed the formula in the draft again, and it is wrong for that context. The draft keeps the cwnd in bytes, and the correct formula in that case completely excludes MSS from 
> the calculation of alpha. This is also the formula derived in the document you mention.
Doesn't that formula considers the cwnd on packets? My understanding is that
the formula in the paper wants to get the same packet/sec since the cwnd is
measured in packets, not bytes. Or am I missing something?
> 
> The formula for stacks that keep cwnd in packets needs to include MSS, hence the term cwnd_i *mss_i. 
> 
> We will update the draft to include both versions of the formula; also, I will recheck the formula for packet based stacks.
Great, thanks. I'll take a look at the formulas as soon as you resubmit the ID...

Thanks for the answer.

Best regards
Michael
> 
> Thanks for the comments, and well spotted!
> Costin
> 
> On 1 Feb 2011, at 09:27, Michael Tüxen wrote:
> 
>>> 
>>> 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
>>> 
>>> 
>> 
>> _______________________________________________
>> multipathtcp mailing list
>> multipathtcp at ietf.org
>> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> 




More information about the Iccrg mailing list