[Iccrg] Comments about CUBIC draft

[Dino-Martin LOPEZ-PACHECO]

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)
2. The used parameters must be clearly documented (the C parameter needs
more explanation - why C = 0.4?).
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.

****** 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.
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/).

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.