Subject: [tcpm] Questions and comments about draft-ietf-tcpm-cubic-02

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Sep 2016 15:42:36 +0200

Hi,

I have been reading draft-ietf-tcpm-cubic-02 and I have a few questions 
and comments about it that I attach below.

In general, I found the draft easy to follow and overall in good shape.

Dont want to open a can of worms here. If this has been debated before, 
point me to the proper thread and i will check it. I am not sure I 
understand why the intended status of this document is Informational if 
the status of RFC 5681 is Standards Track. Shouldnt this be standards 
track, or experimental if the WG feels that more experience is needed?

In the Introduction, it reads:

    CUBIC maintains the same window growth rate independent of RTTs
    outside of the TCP-friendly region, and flows with different RTTs
    have the similar window sizes under steady state when they operate
    outside the TCP-friendly region.  This ensures CUBIC flows with
    different RTTs to have their bandwidth shares linearly proportional
    to the inverse of their RTT ratio (the longer RTT, the smaller the
    share).

I find this part a bit confusing. I mean, the first two sentences seem to say that in cubic, the rate is almost independent of the RTT and then the last sentence, seem to conclude from the two previous sentences that the longer the RTT, the smaller the rate.

I understand what is meant is that cubic is less biased than classic TCP in terms of RTT but it is still somehow biased, but in the same sense than TCP. If this is the case, the last sentence should be in oposition to the two previous one maybe?

In section 3.1, the formula for K is presented. I understnad this results from including in Eq.1 that W(t=0) is equal to W_max*beta_cubic. Maybe it would be worthwhile stating that explicitly.

Later in section 3.1 it talks about W_cubic(t+RTT). How do you calculate RTT? Is it the RTT of the last ACK? do you do some kind of weighted average?

Section 3.2.
I would like to understand when is the sender int he TCP-friendly region.
If we call t=0 the moment of the last congestion notification (i.e. last loss) and we call t=K the moment when the cwnd is Wmax, then at which point in time is the sender in the TCP-friendly region? I would assume that in an interval centered in t=K, is that the case?
I mean, the way it is described i.e. first the TCP-friendly region and then the concave region and then the convex region, made me thought initially that they were sequential (i.e. at t=0 it starts in the TCP-friendly region and then it moves to the concave region and then to the convex) but I understand this is not the case?
Maybe stating explicitly when the different regions occur may facilitate the reading?

Section 3.3 and 3.4.
I understand that the function that governs the growth in both regions is the same and that the difference is conceptual rather than in the algorithm, correct? Maybe it would be clearer to state this explicitly and maybe merge these two sections.

Also, I think that having one section with a summary of the algorithm, where all the congestion control algorithm is described toghether would be beneficial. Maybe an appendix?

Section 4.3 reads:

    CUBIC is designed to remedy the poor performance of TCP in fast long-
    distance networks.  It is not designed for wireless networks.

I find this very wierd. does this means that cubic doesnt work well if my first link is a wifi or a cellular link?
This is probably/hopefully not what you mean. Maybe you are referring to wireless mesh/ad-hoc networks? If so, I suggest making it more explicit.

Anyway, good work, thanks for doing it.

Regards, marcelo

---

From: Yoshifumi Nishida <[email-masked]>
Date: Mon, 12 Sep 2016 15:13:58 -0700

Hi Marcelo,
Thanks for the review.

On Mon, Sep 12, 2016 at 6:42 AM, marcelo bagnulo braun
<[email-masked]> wrote:
> Hi,
>
>
> I have been reading draft-ietf-tcpm-cubic-02 and I have a few questions and
> comments about it that I attach below.
>
> understand why the intended status of this document is Informational if the
> status of RFC 5681 is Standards Track. Shouldnt this be standards track, or
> experimental if the WG feels that more experience is needed?

Yes, we had discussed it before and I believe it is our consensus.
Please check the following threads.

https://www.ietf.org/mail-archive/web/tcpm/current/msg09600.html
https://www.ietf.org/mail-archive/web/tcpm/current/msg09639.html

--
Yoshi

---

From: Lisong Xu <[email-masked]>
Date: Mon, 12 Sep 2016 20:22:51 -0500

Dear Marcel,

Thanks for your comments! I will revise the draft accordingly. Below are 
some short and quick answers.

Lisong

On 9/12/2016 8:42 AM, marcelo bagnulo braun wrote:
> Hi,
>
>
> I have been reading draft-ietf-tcpm-cubic-02 and I have a few 
> questions and comments about it that I attach below.
>
> Dont want to open a can of worms here. If this has been debated 
> before, point me to the proper thread and i will check it. I am not 
> sure I understand why the intended status of this document is 
> Informational if the status of RFC 5681 is Standards Track. Shouldnt 
> this be standards track, or experimental if the WG feels that more 
> experience is needed?
>
>
> I find this part a bit confusing. I mean, the first two sentences seem 
> to say that in cubic, the rate is almost independent of the RTT and 
> then the last sentence, seem to conclude from the two previous 
> sentences that the longer the RTT, the smaller the rate.
>

I will revise it to make it more clearly. The first two sentences are 
about the congestion window size, and the last sentence is about the 
throughput=window/RTT.

> I understand what is meant is that cubic is less biased than classic 
> TCP in terms of RTT but it is still somehow biased, but in the same 
> sense than TCP. If this is the case, the last sentence should be in 
> oposition to the two previous one maybe?
>
> In section 3.1, the formula for K is presented. I understnad this 
> results from including in Eq.1 that W(t=0) is equal to 
> W_max*beta_cubic. Maybe it would be worthwhile stating that explicitly.

Thanks
>
> Later in section 3.1 it talks about W_cubic(t+RTT). How do you 
> calculate RTT? Is it the RTT of the last ACK? do you do some kind of 
> weighted average?

We just use the average RTT estimated by TCP.

> If we call t=0 the moment of the last congestion notification (i.e. 
> last loss) and we call t=K the moment when the cwnd is Wmax, then at 
> which point in time is the sender in the TCP-friendly region? I would 
> assume that in an interval centered in t=K, is that the case?
> I mean, the way it is described i.e. first the TCP-friendly region and 
> then the concave region and then the convex region, made me thought 
> initially that they were sequential (i.e. at t=0 it starts in the 
> TCP-friendly region and then it moves to the concave region and then 
> to the convex) but I understand this is not the case?
Thanks, I will revise the draft to clearly explain it. Basically, 
TCP-friendly region is determined based on whether W_tcp(t)>W_cubic(t).

> Section 3.3 and 3.4.
> I understand that the function that governs the growth in both regions 
> is the same and that the difference is conceptual rather than in the 
> algorithm, correct? Maybe it would be clearer to state this explicitly 
> and maybe merge these two sections.
>
> Also, I think that having one section with a summary of the algorithm, 
> where all the congestion control algorithm is described toghether 
> would be beneficial. Maybe an appendix?

Yes, Thanks, I will revise draft to clearly explain it.

> I find this very wierd. does this means that cubic doesnt work well if 
> my first link is a wifi or a cellular link?
> This is probably/hopefully not what you mean. Maybe you are referring 
> to wireless mesh/ad-hoc networks? If so, I suggest making it more 
> explicit.
>

The traditional TCP does not work well in fast long-distance networks, 
and does not work well in wireless networks. CUBIC only addresses the 
first issue.

Thanks again for your comments.
Lisong

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 Sep 2016 07:50:20 +0200

Thanks for the quick answer.
some replies below...

El 13/09/16 a las 03:22, Lisong Xu escribió:
>> I mean, the way it is described i.e. first the TCP-friendly region 
>> and then the concave region and then the convex region, made me 
>> thought initially that they were sequential (i.e. at t=0 it starts in 
>> the TCP-friendly region and then it moves to the concave region and 
>> then to the convex) but I understand this is not the case?

I understood that much :-)
But I would like to have a more intuitive perspective when does that happen.
Maybe an example of a window evolution over time that goes through all 
the 3 phases would be enough?

>> I find this very wierd. does this means that cubic doesnt work well 
>> if my first link is a wifi or a cellular link?
> and does not work well in wireless networks.

This last one seems like a too broad statement to me. Maybe including a 
few references about what problems are you referring to and maybe point 
to some solutions that have been developped and deployed would make it 
clearer what you mean?

Thanks again.
Regards, marcelo

> CUBIC only addresses the first issue.
>