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

From: <[email-masked]>
Date: Wed, 19 Jan 2011 14:25:54 +0000

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.

---

From: Michael Welzl <[email-masked]>
Date: Thu, 20 Jan 2011 07:13:06 +1100

I'll do it!

Cheers,
Michael

On Jan 20, 2011, at 1:25 AM, <[email-masked]> <[email-masked] 
 > wrote:

> The Multipath TCP WG has developed a congestion control algorithm  
> that enables a TCP connection to use multiple paths.
> 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
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Michael Welzl <[email-masked]>
Date: Mon, 24 Jan 2011 16:23:58 +1100

Hi,

Here's my review:

This is, on the whole, a very well written document - short and  
concise, and clear and to the point. I noticed just a few issues:

- On page 6, when you first introduce alpha, you call it "a  
parameter .. that describes the aggressiveness of the multipath flow"
(missing "s" in "aggressive" in that sentence BTW).
... so this gives the impression that this is a per-aggregate  
parameter. Yet, later, on page 7, you state that "alpha must be  
computed for each multipath flow". Indeed I have a hard time imagining  
how alpha can ensure that you send at least as much as TCP would send  
on the best path while just having a single constant across all sub- 
flows. So I assume it's a per-subflow-variable - but then it should  
get an index i.
I would strongly suggest giving a simple example where MPTCP is used  
across two very different paths, just to show how alpha indeed ensures  
the throughput of TCP on the best path because that seems to be hard  
to grasp with intuition.

The formula presented on page 7 is hard to read. I have no problem  
with the formula that's similar in style on page 9 - but in this  
particular one, things just seem to get into the way of each other,  
and presenting it in a different style would be better. e.g.: what is  
max_i? Is this a function, traversing all i's, like sum_i below? But  
then it looks as if that's a function covering the whole fraction on  
the right, but the denominator (rtt_i^2) at  the same time seems to be  
connected the larger fraction... I don't get it. Or does max_i just  
refer to the numerator perhaps?

Also, upon reading this bit, I immediately began to wonder when and  
how often this is calculated. You answer this later, but the reader  
really expects an answer right here, where the formula appears - so  
you could, for instance, provide a forward reference, saying that this  
will be discussed in the next section.

Which brings me to the "when is it calculated" text on page 8. The  
paragraph starting with "It is possible to implement":
here you say that it's costly to update tot_cwnd on each ack, but  
later you say that "...implementation will update (missing 'the')  
tot_cwnd value whenever the individual subflows' windows are  
updated."  Please explain how this is not the same as updating on each  
ack? I would expect that these windows ARE updated on each ack... so  
what's the difference?

Next par.: "We propose alpha _to_ be a per-connection variable, ..."

section 5 par 1:
"...allocate _a_ zero window..."
"resulting rate _will_ fluctuate unpredictably...."
par 2:
"algorithm will allocate _a_ window to the subflows..."
"When the loss rates differ, _a_ progressively _larger_ window will be  
allocated..."

section 6: "_A_ detailed security analysis..."

That's it! I hope it's helpful.

Cheers,
Michael

---

From: Mark Handley <[email-masked]>
Date: Mon, 24 Jan 2011 09:50:07 +0000

On 24 January 2011 05:23, Michael Welzl <[email-masked]> wrote:
> Hi,
>
> Here's my review:
>
> This is, on the whole, a very well written document - short and concise, and
> clear and to the point. I noticed just a few issues:
>
>
> - On page 6, when you first introduce alpha, you call it "a parameter ..
> that describes the aggressiveness of the multipath flow"
> ... so this gives the impression that this is a per-aggregate parameter.
> Yet, later, on page 7, you state that "alpha must be computed for each
> multipath flow". Indeed I have a hard time imagining how alpha can ensure
> that you send at least as much as TCP would send on the best path while just
> having a single constant across all sub-flows. So I assume it's a
> per-subflow-variable - but then it should get an index i.
> I would strongly suggest giving a simple example where MPTCP is used across
> two very different paths, just to show how alpha indeed ensures the
> throughput of TCP on the best path because that seems to be hard to grasp
> with intuition.

Alpha is computed for each connection - the same alpha applies to all
subflows, so as to control the overall aggressiveness.  It is not a
per-subflow variable.

Obviously our text is unclear on this - is there somewhere in
particular that made you think it was per-subflow?  Or is it just the
wording on page 7 ("alpha must be computed for each multipath flow")
which could be rephased "for each multipath connection" if that helps.

 - Mark

---

From: Michael Welzl <[email-masked]>
Date: Mon, 24 Jan 2011 21:05:33 +1100

>> parameter ..
>> parameter.

It's really only this wording. and yes, this simple change does the  
trick - i guess it was just me, the word "flow" made me think of sub- 
flows.

About another sentence I wrote above: "Indeed I have a hard time  
imagining..."  - now I wonder what gave me this hard time? It actually  
seems clear enough.
Still, an example would be nice to have, but I take back the "strongly  
suggest". Sorry, I must have been tired.

Cheers,
Michael

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 10:48:29 +0100

Dear all,

Could you elaborate on the behaviour of MPTCP when the paths have 
significant bit rate differences, such as PPP on WCDMA and WiFi ?

 From my personal experimentation, i have in short:

WCDMA path only => 700 Kbits/s
WiFi path only => 21 Mbits/s
WCMDA+WiFi paths => 15 Mbits/s

The traffic kind is of Uplink nature.

My feeling is that the balancing algorithm is not suited to such bit 
rates differences.
Because the paths are unequal, passing data on the slowest path 
necessary slows the fastest path.
Although difference in bit rates matter, the same would be expected with 
differences in RTT.

Thanks for your answers.
Bruno

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 11:04:11 +0100

Dear All,

Could you elaborate on the path addition time of MPTCP ?

What i call "path addition time" is the elapsed time between arrival of 
TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate 
path (understanding for the same MPTCP connection).

What i see from my personal experimentation is that the TCP SYN on the 
alternate path fails and needs retransmission. This leads to an almost 3 
seconds "path addition time". Why does the TCP SYN fails ? My current 
explanation is that there is already a high traffic load on the main 
path (upload kind).

Although this might be "experimentation" specific, i guess there might 
be a design problem, in the sense that MPTCP relies on regular TCP SYN 
behavior to make an alternate path ready. This is critical if MPTCP is 
used for handoff purposes.

Thanks for your answers.
Bruno

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 25 Jan 2011 12:04:28 +0200

Hi Bruno,

We've tested the algorithm across a wide range of differences in RTTs and bandwidth between paths in simulation; there we found that MPTCP throughput was what it should be, except when one or both paths were experiencing frequent timeouts. 
We've also tested it in practice with 3g/wifi and found MPTCP was within 10-15% of what it should get.

I am interested to find more details about your setup. Have you looked at the number of timeouts in your test? What implementation are you using? 
Thanks,
Costin

On 25 Jan 2011, at 11:48, Bruno Mongazon-Cazavet wrote:

> Dear all,
> 
> Could you elaborate on the behaviour of MPTCP when the paths have significant bit rate differences, such as PPP on WCDMA and WiFi ?
> 
> My feeling is that the balancing algorithm is not suited to such bit rates differences.
> Because the paths are unequal, passing data on the slowest path necessary slows the fastest path.
> Although difference in bit rates matter, the same would be expected with differences in RTT.
> 
> Thanks for your answers.
> Bruno
> 
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Jan 2011 11:10:16 +0100

Bruno,
> explanation is that there is already a high traffic load on the main

Could you elaborate a bit on the experimental setup that you used ?

Olivier
-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 25 Jan 2011 12:11:41 +0200

Hi,

From your emails, it seems you are using the userland mptcp implementation - that one used to lose the first packet on the subsequent subflows. That is just an implementation quirk (some weird interaction between libpcap and raw sockets), and has nothing to do with MPTCP.
By the way, people from UCL Belgium and Aalto university have been bug fixing the Linux kernel implementation of MPTCP; as far as I know this now runs the coupled congestion controller. Please use that for further tests; the underlying stack is much more robust than the one used by the userland stack, which is an old 2.3.xx stack.

As for the path addition time, MPTCP waits for the first subflow to be established before it opens the additional ones. After the initial flow is setup, all additional subflows can be opened simultaneously, and will be as fast to open as regular TCP connections. What would you like to optimize exactly?

Cheers,
Costin

On 25 Jan 2011, at 12:04, Bruno Mongazon-Cazavet wrote:

> What i call "path addition time" is the elapsed time between arrival of TCP SYN-ACK on the main path and arrival of TCP SYN-ACK on the alternate path (understanding for the same MPTCP connection).
> 
> What i see from my personal experimentation is that the TCP SYN on the alternate path fails and needs retransmission. This leads to an almost 3 seconds "path addition time". Why does the TCP SYN fails ? My current explanation is that there is already a high traffic load on the main path (upload kind).
> 
> Although this might be "experimentation" specific, i guess there might be a design problem, in the sense that MPTCP relies on regular TCP SYN behavior to make an alternate path ready. This is critical if MPTCP is used for handoff purposes.
> 
> Thanks for your answers.
> Bruno
> 
> 
>

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 11:14:31 +0100

Dear All,

Could you elaborate on the possible relationship between MPTCP paths and 
weights assigned to paths in IP source routing ?

Giving the setup of your implementation, a weight needs to be given to 
each interface.
 From my WCDMA/WiFi experimentation, it looks like it requires a higher 
value for WCDMA than WiFi for WCDMA to be really used.
More precisely, if the weight of wcdma is lower than Wifi, wcdma is 
never used by MPTCP as an alternate path.

The question is:
Is there a relationship ?
Or does MPTCP requires a convenient setting of IP source routing 
regarding weight ?

Thanks,
Bruno

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 11:18:59 +0100

Le 25/01/2011 11:04, Costin Raiciu a écrit :
> I am interested to find more details about your setup. Have you looked at the number of timeouts in your test?

Which timeouts ?

>   What implementation are you using?

Linux 2.6.28 vanilla + MPTCP 0.4 kernel.

Thanks,
Bruno

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Jan 2011 10:19:54 +0000

> The traffic kind is of Uplink nature.

Can you elaborate on your experiment setup?  One possible cause would
be too little socket buffer space, at either the sender or receiver.
If the receive window fills because you're waiting for a packet on the
long RTT WCDMA path, then you'd miss sending opportunities on the WiFi
path.

If this is the problem, there are two solutions:

 - add more buffering at the sender and/or receiver.
 - detect the condition, and switch to the WiFi-only path when it occurs.

Cheers,
Mark

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 11:22:10 +0100

> Could you elaborate a bit on the experimental setup that you used ?

Linux 2.6.28 vanilla + MPTCP 0.4 kernel patch.
The MPTCP system is using a HSPA dongle (up to 7 Mbits download) and a 
54Mbits WiFi integrated.
Both 3G and WiFi are connected to a common IP core. End systems are 
either internet or intranet.

I use ttcp to test upload traffic.

Bruno.

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Jan 2011 10:22:48 +0000

> Linux 2.6.28 vanilla + MPTCP 0.4 kernel.

If I recall correctly, MPTCP 0.4 doesn't include the linked congestion
control mechanism.  So the results aren't really indicative of what
you should be able to receive.

 - Mark

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 25 Jan 2011 11:34:30 +0100

Hello,

> either internet or intranet.
Could you try out the recent 0.5 kernel patch?

I just did a quick check, and the SYNs that come in are processed directly.

Is your first SYN really arriving at the box, or may it be dropped on it's 
path?

If you believe it's a bug in the implementation, may you move the discussion 
to the mptcp-developpers mailing-list? 
(https://listes-2.sipr.ucl.ac.be/sympa/info/mptcp-dev)

Cheers,
Christoph

--
Christoph Paasch
PhD Student

IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain

www.rollerbulls.be
--

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 25 Jan 2011 11:37:29 +0100

> weights assigned to paths in IP source routing ?
We do not consider the weights associated to a path in the subflow-selection.
Due to the coupled congestion control (since version 0.5), we automatically 
switch traffic away from congestioned paths.

> Or does MPTCP requires a convenient setting of IP source routing
You need to configure policy-routing. Have a look at our website:
https://scm.info.ucl.ac.be/trac/mptcp/wiki/install - Configure routing rules

Christoph

--
Christoph Paasch
PhD Student

www.rollerbulls.be
--

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 25 Jan 2011 11:47:15 +0100

> you should be able to receive.

Exact, you should upgrade to MTCP 0.5. MPTCP 0.4 uses Reno by default
while 0.5 includes the coupled congestion control

Olivier

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 25 Jan 2011 11:48:47 +0100

Hello,

> you should be able to receive.
Right, the 0.4 release doesn't include the ccc.
However, as it does not include it, the subflows have regular congestion 
control installed (reno, cubic,... or whatever has been configured), and thus 
are generally more agressive than with ccc.

What may slow down is the difference in the rtt of the different paths, 
because we then have a huge reordering-overhead and thus the receive-buffer 
will fill up. Try to increase your maximum receive-buffer size to handle this 
case (as Mark already mentioned).

What are your rtt's of the different paths?

Christoph

--
Christoph Paasch
PhD Student

www.rollerbulls.be
--

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 25 Jan 2011 11:50:34 +0100

Hi Bruno,

(cc'ing mptcp-dev)

Just a small note: a simple test with MPTCP v0.4/5 to check if the 
receive buffer is responsible for this (which is what I would think as 
well) is to increase the linux max allowed receive buffer, that way:
echo "4096 87380 8388608" > /proc/sys/net/ipv4/tcp_rmem

then retry the experiment. In the above line, the important number is 
the third one, which I have set here to twice the default value. That 
third value is the max allowed received buffer. MPTCP will automatically 
tune its receive buffer, taking into account delay differences (bw 
differences should not change anything) *up to* the configured max 
receive buffer.

Hope that will solve the problem,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 12:41:17 +0100

> By the way, people from UCL Belgium and Aalto university have been bug fixing the Linux kernel implementation of MPTCP; as far as I know this now runs the coupled congestion controller. Please use…

No i use kernel patch MPTCP 0.4.
Going to switch to 0.5 soon ;-)
With Linux 2.6.28 vanilla.

> As for the path addition time, MPTCP waits for the first subflow to be established before it opens the additional ones. After the initial flow is setup, all additional subflows can be opened simult…

Just understanding, not optimizing ;-)

Bruno.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 13:40:38 +0100

> What are your rtt's of the different paths?

Yes that's what i mentioned in my previous emails.

Bit rates differ and RTT's also.
wcdma => 40ms (best)
wifi => 5ms (best)

Agree with your explanation.
So the question is how does MPTCP handles such differences  (in 0.5) ?

Thanks
Bruno.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 13:45:02 +0100

Le 25/01/2011 11:50, Sébastien Barré a écrit :
> echo "4096 87380 8388608">  /proc/sys/net/ipv4/tcp_rmem
>

OK i will do that in the near future.

One question related to this:
Does this increase also increase the buffer loss in case of handoff with 
MPTCP (one the path is dropped) ?

Bruno.

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 25 Jan 2011 13:58:27 +0100

> Bit rates differ and RTT's also.
Oh... Well, this is really really fast for wcdma (and even for wifi).
Are you sure that these are the rtt's experienced during your experimentation? 
Congestion in routers increases the rtt due to buffers filling up.

> So the question is how does MPTCP handles such differences  (in 0.5) ?
In 0.5 the reordering-issue is still present. But increasing your receive-
buffer should improve the performance (as sébastien said).

The new feature of 0.5 is the Coupled Congestion Control, which handles the 
increase of the congestion windows of the individual subflows. It tries to 
slower increase the congestion windows of those paths that experience 
congestion.

Christoph

--
Christoph Paasch
PhD Student

www.rollerbulls.be
--

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 25 Jan 2011 14:12:36 +0100

> Congestion in routers increases the rtt due to buffers filling up.

Yes good numbers, ranges are:

wcdma => 40ms to 200ms
wifi => 5ms to 10ms

Yes i am almost confident with the numbers. The networks (3G+WiFi) are 
ours and there are few routers in between.
There is no congestion in routing.
End-systems are not on the Internet.

> buffer should improve the performance (as sébastien said).

So does this also increase the data loss in case of abrupt handoff (one 
path dropped) ?

> slower increase the congestion windows of those paths that experience

I need to try it then.
Thanks, Bruno

---

From: Costin Raiciu <[email-masked]>
Date: Tue, 25 Jan 2011 15:17:51 +0200

> 
> So does this also increase the data loss in case of abrupt handoff (one path dropped) ?
> 

No. This only allows the receiver to buffer more data, waiting for out of order segments.
When a path is dropped, there is an undelivered window (cwnd) of data. On the first timeout, this window will be moved to the connection level retransmit queue, and will be sent as soon as the other subflows have space for it.

Costin

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Jan 2011 13:55:21 +0000

Seb,

With your MPTCP code, do you also need to increase the sender-side
buffering?  With regular TCP, you can't use a large receive buffer
unless you'd got the same size send buffer (because you need to buffer
all unacked data at the sender).  I'd imagine this is the same with
your MPTCP implementation.

 - Mark

2011/1/25 Sébastien Barré <[email-masked]>:
> Hi Bruno,
>
> (cc'ing mptcp-dev)
>
> Just a small note: a simple test with MPTCP v0.4/5 to check if the receive
> buffer is responsible for this (which is what I would think as well) is to
> increase the linux max allowed receive buffer, that way:
> then retry the experiment. In the above line, the important number is the
> third one, which I have set here to twice the default value. That third
> value is the max allowed received buffer. MPTCP will automatically tune its
> receive buffer, taking into account delay differences (bw differences should
> not change anything) *up to* the configured max receive buffer.
>

---

From: Mark Handley <[email-masked]>
Date: Tue, 25 Jan 2011 14:00:12 +0000

On 25 January 2011 11:41, Bruno Mongazon-Cazavet
<[email-masked]> wrote:
>> As for the path addition time, MPTCP waits for the first subflow to be
>> established before it opens the additional ones. After the initial flow is
>> setup, all additional subflows can be opened simultaneously, and will be as
>> fast to open as regular TCP connections. What would you like to optimize
>> exactly?
>

:-)

I don't think anything in the existing implementations has been
optimized (just achieving stability isn't trivial).  I'm sure there's
a lot of tuning that can be done to improve performance in the WiFi/3G
case, but no-one's attempted that yet.  When you find something that
performs strangely, please do mail the implementers list to let them
know.

 - Mark

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 25 Jan 2011 15:17:30 +0100

Hi Mark,

Right. Indeed there is the sending side equivalent:

echo "4096 16384 8388608">  /proc/sys/net/ipv4/tcp_wmem

This is normally not needed, however, because for what I remember (I 
have not done this yesterday, so I should recheck :-)) :
*The max receive buffer is understood as a max value for the whole 
connection.
*The max send buffer is understood as a max contribution of each subflow 
to the whole connection. Hence the real limit is max_sndbuf*nb_subflows

They should be aligned of course in the future to have the same semantic.

thanks for the remark !

regards,

Sébastien.

Op 25-01-11 14:55, Mark Handley schreef:
> 2011/1/25 Sébastien Barré<[email-masked]>:
>> Hi Bruno,
>>
>> (cc'ing mptcp-dev)
>>

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 27 Jan 2011 00:25:20 +0100

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:

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

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 1 Feb 2011 08:27:03 +0100

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