[Iccrg] A review of the CUBIC draft

[Lisong Xu]

Dear Kashif and Lachlan,

Thank you for your comments on CUBIC! Sorry for my late reply, and I 
have been traveling for the past two weeks.

We do not have any results of CUBIC in wireless networks yet. We expect 
that in wireless networks, CUBIC should also "behave relatively less 
aggressive to the standard TCP flows (in other words more TCP friendly) 
than some of the other high speed protocols."

Yes, you made a good point. We will perform some experiments to evaluate 
the performance of CUBIC in wireless networks.

Regarding the sentences on page 13 of the draft, you are right that the 
sentences are not accurate. The first sentence should be "CUBIC ensures 
convergence of competing CUBIC flows with the same RTT in the same 
bottleneck links to an equal bandwidth share."

Thank you again for your comments!
Lisong

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

Kashif Munir wrote:
> 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
>