Last Call Review of draft-ietf-tcpm-cubic-06

Request Review of draft-ietf-tcpm-cubic
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-10-02
Requested 2017-09-18
Authors Injong Rhee, Lisong Xu, Sangtae Ha, Alexander Zimmermann, Lars Eggert, Richard Scheffenegger
Draft last updated 2017-09-26
Completed reviews Opsdir Last Call review of -06 by Qin Wu (diff)
Secdir Last Call review of -06 by Sean Turner (diff)
Genart Last Call review of -06 by Joel Halpern (diff)
Assignment Reviewer Qin Wu 
State Completed
Review review-ietf-tcpm-cubic-06-opsdir-lc-wu-2017-09-26
Reviewed rev. 06 (document currently at 07)
Review result Serious Issues
Review completed: 2017-09-26


Reviewer: Qin Wu

Review results: One major issue, a few minor issues and a few nits


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments.


This informational document introduced CUBIC congestion control scheme and discussed several the safety features of CUBIC. It is well written and in good shape, I think it is almost ready for publication.


Major issues: It is not clear to me how CUBIC enabled sender works together with standard TCP client? How this cubic protocol is deployed together with standard TCP? I think section “Incremental Deployment” should potentially to talk about that, but I fail to see it.


Minor issues:


1.       Section 3, 1st paragraph, 2nd sentence:

It looks to me what you highlight here is alternative algorithms to standard TCP use a convex increase function while Cubic uses both the concave and convex profile of a cubic function. But what is confusing me is the sentence “where during congestion avoidance the windows increment is always increasing”, when to uses a convex increase, where to use convex increase function?


2.       Section 3

How many design principles do you introduce in this section? I assume each paragraph is corresponding to one design principles, no? Would it be clear if you can add a short paragraph at the top of section 3 to summarize the design principles overall.


3.       Section 3 2nd paragraph said:

“   Another notable feature of CUBIC is that its window increase rate ismostly independent of RTT, and follows a (cubic) function of the elapsed time from the beginning of congestion avoidance.”

Why mostly? In which case the windows increase rate is dependent on RTT?

4.       Section 3 3rd paragraph said:

“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.”

What is the difference between window growth rate and window increase rate?

Which function in this document is the window increase rate applied to

When we say “CUBIC maintains the same window growth rate independent of RTTs

outside of the TCP-friendly region”,  who you compare with CUBIC? Standard TCP? Or CUBIC used in TCP-friendly region, I think the last sentence in previous paragraph is disconnected with first sentence in the 3 paragraph? Lack clarity.


5.       Section3 3rd paragraph

Difference between linear share, equal share and higher order share? Either add definition or add reference to these terms.


6.       Section 5.1

7.       Both table shows average window size of standard TCP, HSTCP, and CUBIC. Why the first three column names in table1 is different from the first three column name in the table 2?



1.Section 1, 2nd paragraph


2. Section 1, last paragraph

s/ensuing sections/following sections


3. section 2


“After a window reduction

   following a loss event detected by duplicate ACKs,”


“After a window reduction

   following a loss event is detected by duplicate ACKs,”


-Qin Wu