Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

cc_cubic(4) [freebsd man page]

CC_CUBIC(4)						   BSD Kernel Interfaces Manual 					       CC_CUBIC(4)

NAME
cc_cubic -- CUBIC Congestion Control Algorithm DESCRIPTION
The CUBIC congestion control algorithm was designed to provide increased throughput in fast and long-distance networks. It attempts to main- tain fairness when competing with legacy NewReno TCP in lower speed scenarios where NewReno is able to operate adequately. The congestion window is increased as a function of the time elapsed since the last congestion event. During regular operation, the window increase function follows a cubic function, with the inflection point set to be the congestion window value reached at the last congestion event. CUBIC also calculates an estimate of the congestion window that NewReno would have achieved at a given time after a congestion event. When updating the congestion window, the algorithm will choose the larger of the calculated CUBIC and estimated NewReno windows. CUBIC also backs off less on congestion by changing the multiplicative decrease factor from 1/2 (used by standard NewReno TCP) to 4/5. The implementation was done in a clean-room fashion, and is based on the Internet Draft and paper referenced in the SEE ALSO section below. MIB Variables There are currently no tunable MIB variables. SEE ALSO
cc_chd(4), cc_hd(4), cc_htcp(4), cc_newreno(4), cc_vegas(4), mod_cc(4), tcp(4), mod_cc(9) Sangtae Ha, Injong Rhee, and Lisong Xu, CUBIC for Fast Long-Distance Networks, http://tools.ietf.org/id/draft-rhee-tcpm-cubic-02.txt. Sangtae Ha, Injong Rhee, and Lisong Xu, "CUBIC: a new TCP-friendly high-speed TCP variant", SIGOPS Oper. Syst. Rev., 5, 42, 64-74, July 2008. ACKNOWLEDGEMENTS
Development and testing of this software were made possible in part by grants from the FreeBSD Foundation and Cisco University Research Pro- gram Fund at Community Foundation Silicon Valley. HISTORY
The cc_cubic congestion control module first appeared in FreeBSD 9.0. The module was first released in 2009 by Lawrence Stewart whilst studying at Swinburne University of Technology's Centre for Advanced Inter- net Architectures, Melbourne, Australia. More details are available at: http://caia.swin.edu.au/urp/newtcp/ AUTHORS
The cc_cubic congestion control module and this manual page were written by Lawrence Stewart <lstewart@FreeBSD.org> and David Hayes <david.hayes@ieee.org>. BSD
September 15, 2011 BSD

Check Out this Related Man Page

CC_CDG(4)						   BSD Kernel Interfaces Manual 						 CC_CDG(4)

NAME
cc_cdg -- CDG Congestion Control Algorithm DESCRIPTION
CAIA-Delay Gradient (CDG) is a hybrid congestion control algorithm which reacts to both packet loss and inferred queuing delay. It attempts to operate as a delay-based algorithm where possible, but utilises heuristics to detect loss-based TCP cross traffic and will compete effec- tively as required. CDG is therefore incrementally deployable and suitable for use on shared networks. During delay-based operation, CDG uses a delay-gradient based probabilistic backoff mechanism, and will also try to infer non congestion related packet losses and avoid backing off when they occur. During loss-based operation, CDG essentially reverts to cc_newreno(4)-like be- haviour. CDG switches to loss-based operation when it detects that a configurable number of consecutive delay-based backoffs have had no measurable effect. It periodically attempts to return to delay-based operation, but will keep switching back to loss-based operation as required. MIB Variables The algorithm exposes the following variables in the net.inet.tcp.cc.cdg branch of the sysctl(3) MIB: version Current algorithm/implementation version number. beta_delay Delay-based window decrease factor as a percentage (on delay-based backoff, w = w * beta_delay / 100). Default is 70. beta_loss Loss-based window decrease factor as a percentage (on loss-based backoff, w = w * beta_loss / 100). Default is 50. exp_backoff_scale Scaling parameter for the probabilistic exponential backoff. Default is 2. smoothing_factor Number of samples used for moving average smoothing (0 means no smoothing). Default is 8. loss_compete_consec_cong Number of consecutive delay-gradient based congestion episodes which will trigger loss-based CC compatibility. Default is 5. loss_compete_hold_backoff Number of consecutive delay-gradient based congestion episodes to hold the window backoff for loss-based CC compatibility. Default is 5. alpha_inc If non-zero, this enables an experimental mode where CDG's window increase factor (alpha) is increased by 1 MSS every alpha_inc RTTs during congestion avoidance mode. (Setting alpha_inc to 1 results in the most aggressive growth of the window increase factor over time. Use higher alpha_inc values for slower growth.) Default is 0. SEE ALSO
cc_chd(4), cc_cubic(4), cc_hd(4), cc_htcp(4), cc_newreno(4), cc_vegas(4), h_ertt(4), mod_cc(4), tcp(4), khelp(9), mod_cc(9) D. A. Hayes and G. Armitage, "Revisiting TCP Congestion Control using Delay Gradients", Networking 2011 Proceedings, Part II, 328-341, May 2011. N. Khademi and G. Armitage, Minimising RTT across homogeneous 802.11 WLANs with CAIA Delay-Gradient TCP (v0.1), CAIA Technical Report 121113A, http://caia.swin.edu.au/reports/121113A/CAIA-TR-121113A.pdf, November 2012. ACKNOWLEDGEMENTS
Development and testing of this software were made possible in part by grants from the FreeBSD Foundation and The Cisco University Research Program Fund, a corporate advised fund of Silicon Valley Community Foundation. HISTORY
The cc_cdg congestion control module first appeared in FreeBSD 9.2. The module was first released in 2011 by David Hayes whilst working on the NewTCP research project at Swinburne University of Technology's Centre for Advanced Internet Architectures, Melbourne, Australia. More details are available at: http://caia.swin.edu.au/urp/newtcp/ AUTHORS
The cc_cdg congestion control module was written by David Hayes <david.hayes@ieee.org>. This manual page was written by Lawrence Stewart <lstewart@FreeBSD.org> and Grenville Armitage <garmitage@swin.edu.au>. BUGS
The underlying algorithm and parameter values are still a work in progress and may not be optimal for some network scenarios. BSD
July 2, 2013 BSD
Man Page