Subject: [tcpm] A new Internet draft for TCP Cubic - Version 05

From: Lisong Xu <[email-masked]>
Date: Mon, 17 Jul 2017 23:28:09 -0500

Greetings,

We just submitted a new Internet draft for TCP CUBIC available at the 
following link

https://datatracker.ietf.org/doc/draft-ietf-tcpm-cubic/

In this version, we made the following changes based on the comments 
received on [email-masked] between February 2017 and July 2017.

* Sections 1 and 4.1: change the SACK reference from RFC2018 to RFC6675

* Section 4.2: more clearly explain TCP friendly region.
 From "If W_cubic(t) is less than W_aimd(t), then the protocol is in the 
TCP friendly region"
to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether 
cwnd is greater than or less than W_max), then the protocol is in the 
TCP friendly region"

* New Section 4.8: Slow start behavior of CUBIC
"CUBIC MUST employ a slow start algorithm, when the cwnd is no more than 
ssthresh.
Among the slow start algorithms, CUBIC MAY choose the standard TCP slow 
start [RFC5681] in general networks,
or the limited slow start [RFC3742] or hybrid slow start [HR08] for 
high-bandwidth and long-distance networks."

* Section 4.6: more clearly explain fast convergence
Add "The fast convergence is designed for network environments with 
multiple CUBIC flows. In network environments with only a single CUBIC 
flow and without any other traffic, the fast convergence SHOULD be 
disabled."

* Section 5.4: briefly mention the standing queue issue
"Because CUBIC is designed to be more aggressive (due to faster window 
growth function and bigger multiplicative decrease factor) than Standard 
TCP in fast and long distance networks, it can fill large drop-tail 
buffers more quickly than Standard TCP and increase the risk of a 
standing queue[KWAF16]. In this case, proper queue sizing and management 
[RFC7567] could be used to reduce the packet queueing delay."

* Section 5.8: revise the application limited flows
 From "CUBIC does not raise its congestion window size if the flow is 
currently limited by the application instead of the congestion window. 
In cases of idle periods, t in Eq. 1 MUST NOT include the idle time; 
otherwise, W_cubic(t) might be very high after restarting from a long 
idle time."
to "CUBIC does not raise its congestion window size if the flow is 
currently limited by the application instead of the congestion window. 
In case of long periods when cwnd is not updated due to the application 
rate limit, such as idle periods, t in Eq. 1 MUST NOT include these 
periods; otherwise, W_cubic(t) might be very high after restarting from 
these periods"

Thanks

Lisong

---

From: Yoshifumi Nishida <[email-masked]>
Date: Wed, 19 Jul 2017 16:43:57 -0700

Hi Lisong,

Thank you so much for updating the draft and sorry for my very slow
response.
It looks almost good to me, but one thing I am still thinking is choosing
the value for C.
I still cannot see strong reason for C=0.4. It seems to me it could be 0.3
or 0.5 or other values.
Is there any design rationale here? Or, was it just heuristically
determined?
Sorry for a picky question, but I guess I might not be the only one..

Thanks,
--
Yoshi

On Mon, Jul 17, 2017 at 9:28 PM, Lisong Xu <[email-masked]> wrote:

> to "If W_cubic(t) is less than W_aimd(t) (it does not matter whether cwnd
> is greater than or less than W_max), then the protocol is in the TCP
> friendly region"
>
> multiple CUBIC flows. In network environments with only a single CUBIC flow
> and without any other traffic, the fast convergence SHOULD be disabled."
>
> TCP in fast and long distance networks, it can fill large drop-tail buffers
> more quickly than Standard TCP and increase the risk of a standing
> queue[KWAF16]. In this case, proper queue sizing and management [RFC7567]
> could be used to reduce the packet queueing delay."
>
> currently limited by the application instead of the congestion window. In
> cases of idle periods, t in Eq. 1 MUST NOT include the idle time;
> otherwise, W_cubic(t) might be very high after restarting from a long idle
> time."
> currently limited by the application instead of the congestion window. In
> case of long periods when cwnd is not updated due to the application rate
> limit, such as idle periods, t in Eq. 1 MUST NOT include these periods;
> otherwise, W_cubic(t) might be very high after restarting from these
> periods"
>
> Thanks
>
> Lisong
>

---

From: Yoshifumi Nishida <[email-masked]>
Date: Sun, 23 Jul 2017 22:49:18 -0700

Hi Lisong,

Thanks for the clarification. I am fine with the current draft as an INFO
doc.
I will prepare a write-up for this in a couple of days unless there's any
other last minute comments/questions.
--
Yoshi

On Wed, Jul 19, 2017 at 7:28 PM, Lisong Xu <[email-masked]> wrote:

> Hi Yoshi,
>
> The choice of 0.4 is a tradeoff between the aggressiveness (throughput)
> and tcp friendliness. It was manually selected based on our extensive
> experiments, and there is no magic formula for it :-)
>
> Thanks
>
> Lisong
>
> On 7/19/2017 6:43 PM, Yoshifumi Nishida wrote:
>
> Hi Lisong,
>