Subject: [Iccrg] New co-chair
From: [email-masked] (Michael Welzl)
Date: Mon Feb 28 20:08:10 2011

Hi all,

ICCRG has a new co-chair, replacing Wes Eddy:  Murari Sridharan !

Short bio:

Dr. Sridharan is a Principal Development Lead in Microsoft. He leads  
the development of the Windows networking stack including TCP/IP and  
Winsock protocol development. In recent years he has been instrumental  
in the design & implementation of Compound TCP, high-speed congestion  
control in Windows, hardware assisted protocol acceleration, multi- 
processor scalability using technologies such as Receive Side Scaling  
and more recently advanced protocols for datacenter networks  
(Datacenter TCP). His recent interests include datacenter networking,  
multi-tenancy and network/server virtualization.

Welcome Murari, and thanks so much to Wes for all his energy over the  
years!

Michael
(co-chair who stays  :-)  )

From: [email-masked] (Thomas Dreibholz)
Date: Wed Feb 23 10:20:22 2011
Subject: [multipathtcp] [Iccrg] Re: Please review "Coupled Congestion  Control for Multipath Transport Protocols"
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Dear all,

see my comments inline.

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

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
=======================================================================
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110223/a88eda21/attachment.bin
>From [email-masked]  Thu Feb 24 10:59:23 2011
From: [email-masked] (michawe)
Date: Thu Feb 24 10:58:36 2011
Subject: [Iccrg] Prague IETF meeting planning
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Reminder

On Feb 1, 2011, at 3:12 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:

> Hello ICCRGers, we've requested a meeting slot for ICCRG co-located with the next IETF meeting in Prague:
> http://www.ietf.org/meeting/80/index.html
> 
> So that we can start planning an agenda, please let us know if you'd like to have a presentation slot (what the title is, who the presenter will be, and how long you need).
> 
> --
> Wes Eddy
> MTI Systems
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (=?iso-8859-1?Q?Michael_T=FCxen?=)
Date: Tue Feb  1 20:25:55 2011
Subject: [multipathtcp] [Iccrg] Re: Please review "Coupled Congestion  Control for Multipath Transport Protocols"
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

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, <[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: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Tue Feb  1 14:08:04 2011
Subject: [Iccrg] Prague IETF meeting planning
Message-ID: <[email-masked]>

Hello ICCRGers, we've requested a meeting slot for ICCRG co-located with the next IETF meeting in Prague:
http://www.ietf.org/meeting/80/index.html

So that we can start planning an agenda, please let us know if you'd like to have a presentation slot (what the title is, who the presenter will be, and how long you need).

--
Wes Eddy
MTI Systems

From: [email-masked] (Dirceu Cavendish)
Date: Tue Feb  1 02:26:44 2011
Subject: [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion  Control for Multipath Transport Protocols"
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Michael,

Did you get off (iccrg) list response to your point (2) below? I have similar 
concerns to yours...

Dirceu

________________________________
From: Michael T?xen <[email-masked]>
Cc: [email-masked]; iccrg <[email-masked]>
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, <[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

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110131/0db1eabc/attachment.html
>From [email-masked]  Tue Feb  1 07:27:03 2011
From: [email-masked] (=?iso-8859-1?Q?Michael_T=FCxen?=)
Date: Tue Feb  1 07:22:28 2011
Subject: [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion 
	Control for Multipath Transport Protocols"
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

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 <[email-masked]>
> Cc: [email-masked]; iccrg <[email-masked]>
> 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, <[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
> 
>