[Iccrg] A review of the CUBIC draft

[Kashif Munir]

Dear Lachlan,

Thanks for the comments. Basically, I am asked to comment on two things.

One of them is the protocol's impact on competing flows. I believe, it is
"mainly" about the protocol's fairness to standard TCP in difficult and
typical scenarios (like those mentioned in your paper "Towards a Common TCP
Evaluation Suite"). It can only be a relative comparison and by seeing the
results in the draft and in the CUBIC related papers, it is shown to behave
relatively less aggressive to the standard TCP flows (in other words more
TCP friendly) than some of the other high speed protocols. However, it is
one of the metrics that must be considered along with other metrics. In the
case of the networks having more loss rate, the performance of CUBIC is no
worse than that of standard TCP and relatively less aggressive to standard
TCP than some of the other variants. 

Although the authors mention that in the case of wireless networks, CUBIC's
performance is no worse than that of regular TCP; it would be interesting to
see some results showing its impact on competing flows in that sort of
environments.

Regarding RTT-fairness, I agree that there is no point in calling a protocol
as RTT-fair if it is just for the exceptional case when all RTTs are equal.
The CUBIC draft does explain it on page numbers 3, 4 and 13 of the draft.
However, the explanation may further be refined. For example, on page 13 of
the draft it is mentioned, "CUBIC ensures convergence of competing CUBIC
flows in he same bottleneck links to an equal bandwidth share. When
competing flows have different RTTs, their bandwidth shares are linearly
proportional to the inverse of their RTT ratios." If I have understood
correctly, the sentences are contradicting. It is possible that two flows
having different RTTs sharing a same bottleneck link. According to the first
sentence both flows would share the bandwidth equally but according to the
second they would not. I would not say that this is not strength of the
protocol as according to the RFC 5166 (Metrics for the Evaluation of
Congestion Control Mechanisms), a congestion control mechanism should be
evaluated in terms of trade-offs between a range of metrics and not just
only for a single metric.  



Best Regards,
Kashif Munir
-------------------
PhD Candidate
Institute of Computer Science
University of Innsbruck, Austria
Homepage: http://dps.uibk.ac.at/~kashif/

 
 
 
-----Original Message-----
From: Lachlan Andrew [mailto:lachlan.andrew at gmail.com] 
Sent: Monday, May 26, 2008 8:00 PM
To: Kashif Munir
Cc: iccrg
Subject: Re: [Iccrg] A review of the CUBIC draft

Greetings Kashif,

Thanks for the review.

2008/5/26 Kashif Munir <kashif.munir at uibk.ac.at>:
> The CUBIC protocol can be considered safe for
> deployment as it does not perform worse than TCP in difficult environments
> like wireless networks.

My understanding was that being "safe" is normally about the
algorithm's impact on *competing* flows, rather than its own
performance.  Could you please comment on how well other flows fare in
difficult (and typical) environments when CUBIC is used?

> the explanation must be clear
> and consistent throughout the document. It must be clearly specified that
> the CUBIC flows are only RTT-fair when they have same RTT

What does RTT fairness mean if all RTTs are equal?

> and by taking some
> time for convergence to fair share otherwise the CUBIC flows have their
> bandwidth shares linearly proportional to the inverse of their RTT ratio.

Good.  That is more RTT fair than Reno.

Cheers,
Lachlan

-- 
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/lachlan