[Iccrg] Comments about CUBIC draft

[Lisong Xu]

Dear Dino,

Sorry for my late response. Thank you for your interest and comments on 
CUBIC. Please see my reply below.

Dino-Martin LOPEZ-PACHECO wrote:
> Hi all,
> 
> My name is Dino and I'm a new member in this group.
> 
> I have read the draft about the CUBIC protocol and here you are some
> comments that I think can be useful for future discussions.
> 
> ****** Comments concerning the writing quality ******
> 
> The CUBIC draft  (draft-rhee-tcpm-cubic-00.txt) is in general clear and
> understandable. But
> 
> 1. The draft is missing standards language (SHOULD, MUST, etc)

Thanks. Yes, we will revise the draft accordingly.

> 2. The used parameters must be clearly documented (the C parameter needs
> more explanation - why C = 0.4?).

Since it is hard to give the mathematical proof in the draft, we give 
only the intuitive reason in the draft. More detailed explanation and 
analysis are given in our CUBIC paper.

> 3. In Section 2.2 (TCP-friendly region) the authors write: "If cwnd is
> less than W_tcp(t), then the protocol is in the TCP friendly region...",
> while in the paper "CUBIC: A New TCP-Friendly High-Speed TCP Variant",
> the authors say that CUBIC is in the TCP-friendly region when W(t+RTT)
> is less than W_tcp(t). Since cwnd is not equal to W(t+RTT) I think both
> arguments are different and a clarification about this point is needed.

Our CUBIC paper reads "If Wtcp is larger than Wcubic (in eqn. 1), then 
we set the window size to Wtcp.", which is consistent with the CUBIC draft.

> 
> ****** Comments concerning the CUBIC protocol mechanisms ******
> 
> CUBIC in an extension of the current standard TCP, to improve the
> performance of TCP in wire-based large bandwidth * delay product
> networks. The new mechanisms proposed by CUBIC modify only the window
> increase function in the sender side, to get high link utilization in a
> large variety of network conditions. Thus, CUBIC does not impact the
> Internet security and reacts as standard TCP in case of congestion
> collapses, routing changes, link disconnections, intermittent links or
> mobility events.
> 
> Moreover, CUBIC directly impact the throughput and the fairness. On the
> one hand :
> 
> 1. Some experiments (http://netsrv.csc.ncsu.edu/highspeed/) show that
> CUBIC flows sharing the bottleneck converge to the fairness point, but
> the needed time for converging can be large. For instance, in the paper
> "Experimental Evaluation of CUBIC-TCP", the authors show that 2 flows
> could need up to 500s before getting fairness in a 500Mbps bottleneck
> link, with an RTT of 200ms. This phenomenon can be also observed in the
> experiences presented in the web address before cited.

Injong has written a rebuttal to "Experimental Evaluation of CUBIC-TCP", 
which discusses and explains the results shown in that paper. Basically,
   1. There is no absolute performance metric for "slow" and "fair" that 
are all relative terms. Performance evaluation without proper comparison 
with other protocols may be misleading.
   2. We should discuss whether an observation is a behavior of a 
protocol in a specially designed case or in a more realistic case.
   3. We should discuss whether an observation is an unique behavior of 
a highspeed TCP variant, or a common behavior of all TCP variants.

For more information, please refer to 
http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf

> 2. Experiments about CUBIC show also that, in many cases, CUBIC flows
> degrade the performance of standard TCP. The unfairness between CUBIC
> and TCP increases as the RTT increases
> (http://netsrv.csc.ncsu.edu/wiki/index.php/Testing_between_Korea_and_Japan,
> http://netsrv.csc.ncsu.edu/highspeed/).

This is not "the unfairness between CUBIC and TCP", and it should be 
"the difference between CUBIC and TCP". The reason is that TCP cannot 
efficiently use the available bandwidth in a network with a long RTT, 
and CUBIC is designed to achieve more throughput than TCP in such a network.

Thanks
Lisong

> 
> But on the other hand, there are some important arguments to consider
> CUBIC as a congestion protocol which can be safely deployed in the Internet:
> 
> 1.- It has been proved mathematically and experimentally that CUBIC is
> less aggressive than High Speed TCP, and HSTCP hasn't been known
> to exhibit severe issues in deployment or testing experiences (HSTCP has
> already an experimental RFC status).
> 2.- Several experiments have shown that CUBIC is less aggressive than
> BIC, and BIC is used by most Linux-based systems since year 2005.
> (Currently I don't know severe problems derived from the use of BIC in
> Internet...)
> 
> Even if high speed protocols, like High Speed TCP, BIC or CUBIC, can
> potentially introduce serious congestion and unfairness problems due to
> their aggressiveness, the throughput of such high speed protocols stay
> limited by the TCP buffer size (and the link capacity in the end hosts).
> Now, we must consider that in most cases, such buffer size is
> initialized with a very small value (e.g. the default maximum TCP buffer
> size is 128KB in most Linux-based systems). Thus, I believe the damaged
> caused by CUBIC to standard TCP flows, which is less aggressive than
> HSTCP and BIC, will be very limited. Therefore, I believe this protocol
> can be safely deployed in the Internet.
> 
> ******************
> 
> Cheers,
> 
> Dino M. LOPEZ P.
> 
> _______________________________________________
> Iccrg mailing list
> Iccrg at cs.ucl.ac.uk
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

-- 
Lisong Xu, Assistant Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu