The slow convergence of CUBIC had been addressed through CUBIC v2.1
and CUBIC v2.2 by removing the clamping of CUBIC growth function and
making CUBIC more aggressive for fast convergence.
So, I expect you talk about the latest update (CUBICv2.3) which
integrates a new slow start, called HyStart.

The second parameter of HyStart, which is a delay parameter, is
designed to respect the existing flows.
Which means that the later joining flow starts from the congestion
window where it is believed to be safe not incurring packet losses to
the existing flows.
After that, it tries to share the link progressively (not depriving
all of others bandwidth at once during slow start).

My comments related to the current cubic implementation, not the  
proposed new version.   I (not anyone else I don't think) has carried  
out any tests on this new version yet.

That said, even under best case circumstances is not at all clear  
that *any* change in slow start can properly address the slow  
convergence issues in cubic (or other proposals for that matter).   
All it needs is for an early packet loss to lead to an exit from slow  
start and then convergence is back to being determined by congestion  
avoidance behaviour, which remains slow.    Similarly, recovery to  
fairness following a UDP disturbance (or anything else that does not  
cause slow start to kick in) will be determined by the congestion  
avoidance behaviour, and so remain slow.

That is under best case conditions.  If the modified slow start makes  
a mistake (which seems like a reasonable concern since its trying to  
so dome quite fancy stuff based on limited information about the  
network, often early in the flow lifetime) then its not clear what  
the impact on convergence might be even when everything is otherwise  
going our way.

--snip-

Could you try your testings with the following changes? We definitely
will have testings like you mentioned and post the results.

Will do.  Got a deadline this week but I'll try to make some time  
next week.

Doug