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

From: Lisong Xu <[email-masked]>
Date: Fri, 2 Dec 2016 10:06:20 -0600

Greetings,

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

https://tools.ietf.org/html/draft-ietf-tcpm-cubic-03

In this new version, we made the following changes based on the comments 
received on [email-masked] in September and October 2016.

* Updated the contact information of two authors

* Section 1: Briefly explain that the throughput of a TCP is equal to 
"approximately, window/RTT". As there was some confusion about the 
window size and throughput of TCP.

* Section 3.1:
    + Add explanation of W_cubic(0)=W_max*beta_cubic
    + Add explanation about RTT "where RTT is the weighed average RTT 
calculated by the standard TCP"

* Section 3.2: Add a new paragraph to explain intuitively about the TCP 
friendly region. "Standard TCP performs well in certain types of 
networks, for example, under short RTT and small bandwidth (or small 
BDP) networks. In these networks, we use the TCP-friendly region to 
ensure that CUBIC achieves at least the same throughput as the standard 
TCP."

* Sections 3.3 and 3.4: Add "where W_cubic(t+RTT) is calculated using 
Eq. 1".

* Section 3.5: add slow start threshold calculation "ssthresh = cwnd * 
beta_cubic; // new slow start threshold"

* Section 4.3: Remove sentence "It is not designed for wireless 
networks" to avoid some confusion about the types of wireless networks, 
types of problems in wireless networks, and the potential problems of 
CUBIC in wireless networks.

* Section 4.5: changes
   from "In case that there is congestion collapse, CUBIC behaves likely 
standard TCP"
    to "With regard to the potential of causing congestion collapse, 
CUBIC behaves like standard TCP"

* Section 4.8: changes
   from "In cases of idle periods, t in Eq. 1 should not include the 
idle time"
   to "In cases of idle periods, t in Eq. 1 MUST NOT include the idle time"

* Revised the whole draft to clearly distinguish between the loss events 
detected by dup ack and the timeouts.
    + Section 1: from "after a loss event" to "during congestion avoidance"
    + Section 1: from "following a loss event" to "following a loss 
event detected by duplicate ACKs"
    + Section 1: from "since the last loss event" to "since the 
beginning of congestion avoidance"
    + Section 3.1: from "when a packet loss occurs" to "when a packet 
loss (detected by duplicate ACKs) occurs"
    + Section 3.5: from "when a packet loss occurs" to "when a packet 
loss (detected by duplicate ACKs) occurs"
    + Add a new section 3.7 to describe the behavior of CUBIC in 
timeout: "In case of timeout, CUBIC follows the standard TCP to reduce 
cwnd, but sets ssthresh using beta_cubic (same as in Section 3.5)."

Thanks
Lisong

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 2 Dec 2016 09:25:43 -0800

Hi Lisong,

The new draft looks much better. For clarity, I suggest the draft
explicitly mentions the interactions with (classic) ECN, even RFC3168
already mandates treating ECN as a loss. If Cubic only
reset the elapsed time "t" only on loss but not (classic) ECN, then even if it
reduces window by beta on ECE ACKs, it'll still grow the window too
rapidly afterwards.

Current draft says:

  The window growth function of CUBIC uses the following function:

       W_cubic(t) = C*(t-K)^3 + W_max (Eq. 1)

   where C is a constant fixed to determine the aggressiveness of window
   growth in high BDP networks, t is the elapsed time from the last
   window reduction (measured right after the fast recovery)
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Fortunately, Linux does implement this tricky part correctly. Not sure
about other implementations tho.

On Fri, Dec 2, 2016 at 8:06 AM, Lisong Xu <[email-masked]> wrote:
> "approximately, window/RTT". As there was some confusion about the window
> size and throughput of TCP.
>
> * Section 3.1:
> friendly region. "Standard TCP performs well in certain types of networks,
> for example, under short RTT and small bandwidth (or small BDP) networks. In
> these networks, we use the TCP-friendly region to ensure that CUBIC achieves
> at least the same throughput as the standard TCP."
>
> * Sections 3.3 and 3.4: Add "where W_cubic(t+RTT) is calculated using Eq.
> 1".
>
> * Section 4.3: Remove sentence "It is not designed for wireless networks" to
> avoid some confusion about the types of wireless networks, types of problems
> in wireless networks, and the potential problems of CUBIC in wireless
> networks.
>
> * Section 4.5: changes
>    to "With regard to the potential of causing congestion collapse, CUBIC
> behaves like standard TCP"
>
> * Section 4.8: changes
>   from "In cases of idle periods, t in Eq. 1 should not include the idle
> time"
>    + Section 1: from "following a loss event" to "following a loss event
> detected by duplicate ACKs"
>    + Section 1: from "since the last loss event" to "since the beginning of
> congestion avoidance"
>    + Section 3.1: from "when a packet loss occurs" to "when a packet loss
> (detected by duplicate ACKs) occurs"
>    + Section 3.5: from "when a packet loss occurs" to "when a packet loss
> (detected by duplicate ACKs) occurs"
>    + Add a new section 3.7 to describe the behavior of CUBIC in timeout: "In
> case of timeout, CUBIC follows the standard TCP to reduce cwnd, but sets
> ssthresh using beta_cubic (same as in Section 3.5)."
>
> Thanks
> Lisong
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Lisong Xu <[email-masked]>
Date: Fri, 2 Dec 2016 13:21:37 -0600

Thanks, Yuchung. Will change it in the next version.

Lisong