Sec 5.6

[larseggert]

Markku Kojo said:

Sec 5.6

Competing CUBIC flows will converge but it happens very slowly and requires a large amount of data to send, i.e., short flows are more unlikely to live long enough to converge. This seems to be case at least according to the results in original paper [HRX08, Fig 4 b].
Summary and citing some performance data would be very useful and much more convincing.

[bbriscoe]

See my comment under #89, part of which duplicates this issue.

[larseggert]

@lisongxu, any update?

[lisongxu]

Thanks, Markku! How about the following revised paragraphs?

CUBIC ensures convergence of competing CUBIC flows with the same RTT in the same bottleneck links to an equal throughput. When competing flows have different RTT values, their throughput ratio is linearly proportional to the inverse of their RTT ratios. This is true independently of the level of statistical multiplexing on the link. The convergence time depends on the network environments (e.g., bandwidth, RTT) and the level of statistical multiplexing, as mentioned in Section 3.4. Generally, Cubic converges faster than Reno in fast and long-distance networks mainly due to its faster window increase function.

[larseggert]

@markkukojo, please comment on the above?

[markkukojo]

Thanks for the update and apologies for the delay (not now able to do this as a day job :(

There is a number of claims in this para. Each of them calls for evidence, i.e., performance data to summarise and cite that shows this really is the case. Otherwise, these claims do not have much value.

The last sentence starting "Generally" is not quite true. Convergence happens in two directions: 1) for acquiring more capacity when such capacity becomes available, and 2) for relinquishing capacity when congestion is encountered (e.g., more flows join to share the common bottleneck.
In the latter case (case 2), CUBIC is significantly slower due to larger beta and therefore CUBIC actually is unfair against Reno. But, the last sentence discusses CUBIC vs. Reno which actually is not in scope in Sec 5.6.

[lisongxu]

Thanks, @markkukojo. We will add some citations related to the convergence of cubic.

[bbriscoe]

The best ref I know is below. Altho' it's a general Cubic evaluation, it focuses a lot on convergence, including insightful critique.

Leith, D. J.; Shorten, R. N. & McCullagh, G. "Experimental evaluation of Cubic-TCP" Proc. Int'l Wkshp on Protocols for Future, Large-scale & Diverse Network Transports (PFLDNeT'07), 2007

Here's my BiBTeX in case useful:

@InProceedings{Leith07:Cubic_Eval,
author = {Douglas J. Leith and Robert N. Shorten and G. McCullagh},
title = {{Experimental evaluation of Cubic-TCP}{}},
booktitle = {Proc. Int'l Wkshp on Protocols for Future, Large-scale & Diverse Network Transports (PFLDNeT'07)},
year = {2007},
url = {https://www.hamilton.ie/net/pfldnet2007_cubic_final.pdf},
affiliation = {Hamilton Inst.},
keywords = {Data Communication, Networks, Internet, Quality of Service, QoS, Congestion Control, Rate Control, Algorithms, Protocols, Probing, Convergence},
owner = {RJB},
timestamp = {2010.10.07},
}

[larseggert]

@lisongxu could we get a PR for this, please?

[lisongxu]

Thanks, Bob! @bbriscoe That paper evaluated an earlier version of Cubic. The latest Cubic (since around 2008) has removed the window clamping for both the concave and convex regions, and thus improved the convergence for high BDP networks.