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

From: Costin Raiciu <[email-masked]>
Date: Tue, 1 Feb 2011 17:01:00 +0200

Hi Michael, 

Sorry for the late reply - we haven't slept much lately because of the Sigcomm deadline.

When aiming for the same throughput as tcp on the best path, we equalize rates in bytes per second.

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.

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.

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, <[email-masked]> <[email-masked]> 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
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/multipathtcp
>> 
>> 
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>> 
>> 
> 
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 1 Feb 2011 21:30:34 +0100

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

---

From: Thomas Dreibholz <[email-masked]>
Date: Wed, 23 Feb 2011 11:20:46 +0100

Dear all,

see my comments inline.

On Dienstag 01 Februar 2011, Costin Raiciu wrote:
> 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.
> 

I do not understand why you use cwnd_i * mss_i here. If cwnd_i is given in 
bytes, then cwnd_i / mss_i gives the cwnd in MSS.

I can reconstruct the train of thought for the formula for alpha from 
"Practical Congestion Control for Multipath Transport Protocols". It is given 
in MSS instead of bytes.

To reconstruct the formula of the I-D, I have
- replaced  \hat{w}_r by (cwnd_i / mss_i) and
- used i instead of r as index variable.

The result is
alpha = tot_cwnd *
   ( max_i (sqrt(cwnd_i/mss_i) / rtt_i) /
     ((sum_i ((cwnd_i/mss_i) / rtt_i))^2) ).

To get rid of the square root function, it can be transformed to:
alpha = tot_cwnd *
   ( max_i ((cwnd_i / mss_i) / (rtt_i^2)) /
     ((sum_i ((cwnd_i/mss_i) / rtt_i))^2) ).

That is, that fomula in the I-D has to:
- replace "cwnd_i * mss_i" by "cwnd_i / mss_i" and
- "mss_i^2" by "mss_i".

Also, I am wondering why the fraction term is multiplied by tot_cwnd to 
compute alpha. The only place alpha is used is to compute the increase:

alpha*bytes_acked*mss_i/tot_cwnd

Since (tot_cwnd/tot_cwnd)=1, tot_cwnd may be simply cancelled out.

Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================