[Iccrg] review of high-speed proposals?

lars.eggert@nokia.com (Eggert Lars (Nokia-NRC/Espoo)) Wed, 26 January 2011 13:29 UTC

From: lars.eggert@nokia.com
Date: Wed, 26 Jan 2011 13:29:14 +0000
Subject: [Iccrg] review of high-speed proposals?
In-Reply-To: <EF5EF2B13ED09B4F871D9A0DBCA463C20111A4A1@tk5ex14mbxc105.redmond.corp.microsoft.com>
References: <8D9EBD48-531F-4FF2-9C0C-2D13AD89E2DD@nokia.com> <EA7E7B46-6350-4D39-9DFE-7C3D9773B2E6@ifi.uio.no> <4ABCAE6E-6437-49ED-AD01-00DD9F092F16@nokia.com> <BCCC2DF2-798D-450B-9603-136FEDFBA7D0@nokia.com> <EF5EF2B13ED09B4F871D9A0DBCA463C20111870F@tk5ex14mbxc105.redmond.corp.microsoft.com> <AANLkTi=SpFhoE9-DK1+hk=k4vvWcUiv61CoWWtnugcr0@mail.gmail.com> <EF5EF2B13ED09B4F871D9A0DBCA463C20111A4A1@tk5ex14mbxc105.redmond.corp.microsoft.com>
Message-ID: <A3B35F2E-8006-44CD-9137-9E0C68B3FDA2@nokia.com>
X-Date: Wed Jan 26 13:29:14 2011

Hi,

to reiterate one more time:

The IETF cannot start the process of publishing these IDs on high-speed congestion control as Experimental until they have actually been submitted to the TCPM WG for adoption. Author action is required for this to happen.

Specifically, I'm talking about:

	* draft-rhee-tcpm-cubic, last updated Aug 2008
	* draft-leith-tcp-htcp, last updated Apr 2008
	* draft-sridharan-tcpm-ctcp, last updated Nov 2008

Lars
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20110126/266d5cc4/smime.bin
>From Michael.Tuexen@lurchi.franken.de  Wed Jan 26 23:25:20 2011
From: Michael.Tuexen@lurchi.franken.de (=?iso-8859-1?Q?Michael_T=FCxen?=)
Date: Wed Jan 26 23:21:33 2011
Subject: [Iccrg] Re: [multipathtcp] Please review "Coupled Congestion
 Control for Multipath Transport Protocols"
In-Reply-To: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net>
References: <9510D26531EF184D9017DF24659BB87F3275F300AE@EMV65-UKRD.domain1.systemhost.net>
Message-ID: <B4B1E8D9-EB6D-4E65-BCF9-E8AE3B68CA87@lurchi.franken.de>

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@bt.com> <philip.eardley@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@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp