Subject: [multipathtcp] draft-ietf-mptcp-congestion-02

From: Stein Gjessing <[email-masked]>
Date: Sun, 3 Apr 2011 12:01:34 +0200

Hi,

I have read  draft-ietf-mptcp-congestion-02, without really trying to understand the algorithm.  Anyhow I think I found some inconsistencies in the text, and I also have a few suggestions for easier readability.

1.
The term "path" is used so much in this paper that I  have a problem with it in Goal 2:

  o  Goal 2 (Do no harm) A multipath flow should not take up more
      capacity on any one of its paths than if it was a single path flow
      using only that route.  This guarantees it will not unduly harm
      other flows.

I mean it would be more precise (and even more important, easier to understand) if you write:

   o  Goal 2 (Do no harm) A multipath flow should not take up more
      capacity from any of the resources shared by its different paths, than if it was a single flow
      using only one of these paths.  This guarantees it will not unduly harm
      other flows.

2.
It is strange that you write (notice "the same bandwidth"):

  Our solution sets the multipath flow's aggregate bandwidth to be the
  same bandwidth a regular TCP flow would get on the best path
  available to the multipath flow

when you in the next paragraph write (notice "the multipath flow throughput will be strictly higher than"):

   We note that in cases with low statistical multiplexing (where the
   multipath flow influences the loss rates on the path) the multipath
   throughput will be strictly higher than a single TCP would get on any
   of the paths.  In particular, if using two idle paths, multipath
   throughput will be sum of the two paths' throughput.

I think  you should modify or quantify the statement about "the same bandwidth" in the former paragraph.

The latter paragraph also conflicts with a later paragraph (notice "equal to"):

   "alpha" is a parameter of the algorithm that describes the
   aggresiveness of the multipath flow.  To meet Goal 1 (improve
   throughput), the value of alpha is chosen such that the aggregate
   throughput of the multipath flow is equal to the rate a TCP flow
   would get if it ran on the best path.

3. 
Before the definition of alpha at the end of section 3, you write:

   Hence, alpha must be
   computed for each multipath flow, based on the observed properties of
   the paths.

It is very easy to read this as "for each multipath subflow", and then think there should be an alpha_i.
I suggest you remove "for each" , and write simply:

   Hence, alpha must be computed  based on the observed properties of the paths.

Stein

---

From: Scott Brim <[email-masked]>
Date: Sun, 3 Apr 2011 08:20:33 -0400

>      using only one of these paths.  This guarantees it will not unduly harm

Why should MPTCP cripple itself like this?  The requirement is that
MPTCP do no more harm to any individual TCP connection than if it were
a single TCP connection itself, and a TCP connection only follows (and
thus can only experience 'harm' on) a single path.

Thanks ... Scott

---

From: Sébastien Barré <[email-masked]>
Date: Mon, 04 Apr 2011 15:20:58 +0200

Hi,

Here are some comments for Section 4:
*===

alpha*bytes_acked*mss_i/tot_cwnd/alpha_scale

===
I guess you meant (alpha*bytes_acked*mss_i/tot_cwnd)/alpha_scale.
This is logical from the context, but the current writing is ambiguous 
if read alone.

*Now in section 4.1:
===

In the multipath case, cwnd_cnt_i is maintained for each subflow as
    above, and cwnd_i is increased by 1 when cwnd_cnt_i>  alpha_scale *
    tot_cwnd / alpha.

===

This does not correspond to the formula in section 3. IMO, it should be:
"Increment cwnd_i by 1 when:
cwnd_cnt_i > max(alpha_scale*tot_cwnd*mss_i/alpha, cwnd_i*mss_i)"

Note that this solves two mistakes: One is that the max() should be 
used, the other is that we should multiply by mss_i on the right size to 
get byte units on both sizes of the inequality.

*Finally a typo: Just before section 5:
cwnd_max*mss_max*mss_max -> cwnd_max*mss_max

regards,

Sébastien.

Op 03-04-11 14:20, Scott Brim schreef:
> On Sun, Apr 3, 2011 at 06:01, Stein Gjessing<[email-masked]>  wrote:
>> Hi,
>>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

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

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 11 Apr 2011 14:24:26 +0300

Hi Stein,

Thanks for all your comments - we've updated the draft to take them into account.
Costin

---

From: Costin Raiciu <[email-masked]>
Date: Mon, 11 Apr 2011 14:45:58 +0300

Seb, thanks for your suggestions.

> cwnd_cnt_i > max(alpha_scale*tot_cwnd*mss_i/alpha, cwnd_i*mss_i)"

I agree with the max - well spotted. However, there is no need to include mss here. snd_cwnd_cnt is simply the count of the number of segments acked since the last cwnd increase.

> cwnd_max*mss_max*mss_max -> cwnd_max*mss_max
Actually this is correct.
If you look at the formula, it has mss^2 both an the numerator and the denominator, so they cancel out, which is what we want. 

Thanks,
Costin

---

From: Sébastien Barré <[email-masked]>
Date: Wed, 13 Apr 2011 13:22:31 +0200

Hi Costin,

Op 11-04-11 13:45, Costin Raiciu schreef:
>> cwnd_cnt_i>  max(alpha_scale*tot_cwnd*mss_i/alpha, cwnd_i*mss_i)"
Then there is another (small) problem... Indeed you define snd_cwnd_cnt 
before, as a count of the number of segments.
However, you also say in section 3 the following :
===

    We assume appropriate byte counting (ABC, [RFC3465  <http://tools.ietf.org/html/rfc3465>]) is used, hence
    the bytes_acked variable records the number of bytes newly
    acknowledged.  If ABC is not used, bytes_acked SHOULD be set to
    mss_i.
====

Since there is no further ABC mention later in the document, I was 
assuming that your statement "we assume ABC is used" was valid 
throughout the document.
If you count snd_cwnd_cnt in segments, you are not doing ABC.
Still this formula is interesting IMO, but I think it should be 
mentioned that this is not doing ABC, and the equivalent formula for ABC 
should be put next to it (using bytes_acked instead of snd_cwnd_cnt to 
avoid ambiguities).

What do you think ?

> If you look at the formula, it has mss^2 both an the numerator and the denominator, so they cancel out, which is what we want.
Absolutely right. I was just reading too fast, and it was tempting to  
see such a repetition as a typo :-). Maybe mss_max^2 would be clearer ?

thanks,

Séb.