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

[Michael Welzl]

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


On Jan 20, 2011, at 1:25 AM, <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