Linux TCP Congestion Control

<<Previous Page                Next Page>>

Typical procedure to check, change Congestion Control algorithm

View currently configured Congestion Control Algorithm
Optionally list available (pre-compiled) Congestion Control algorithms
Load new Pluggable Congestion Control Algorithm
View currently configured Congestion Controlled Algorithm

View currently configured Congestion Control Algorithm

# cat /proc/sys/net/ipv4/tcp_congestion_control

List available (pre-compiled) Congestion Control Algorithms along with various other network related Loadable Kernel Modules (LKM)

# ls /lib/modules/`uname -r`/kernel/net/ipv4/

The typical output for kernel 2.6.34.7 listing available congestion control modules, excluding other modules


 tcp_htcp.ko     tcp_scalable.ko  
 tcp_hybla.ko
 tcp_vegas.ko  tcp_ip.ko
 tcp_bic.ko 
 tcp_illinois.ko  tcp_veno.ko
 tcp_diag.ko  tcp_westwood.ko  
 tcp_highspeed.ko  tcp_probe.ko  tcp_yeah.ko

Load new Congestion Control Algorithm (effective immediately without reboot)

Note: the prefix “tcp_” as displayed when listing is not required, substitute "newalgorithm" with the new algorithm of your choice

Using sysctl (preferred method)

# sysctl -w net.ipv4.tcp_congestion_control=newalgorithm

Using echo to write directly to file (alternate method)

# echo "newalgorithm" > /proc/sys/net/ipv4/tcp_congestion_control


Brief thumbnail descriptions of the alternate Congestion Control algorithms,

most pre-compiled and available immediately in kernel 2.6.34.7, others available but require compilation.

First, a brief but important reminder:

 Choice should depend on where you believe the congestion bottleneck exists. For example, if the connection is WiFi but the Access Point is high quality with strong signal and line of sight across a small room with no EMF and not sharing the connection with any other machine, then for practical purposes the network link is high quality and any congestion issues aren't likely caused by the wireless network link. In this case veno might not be your best choice, something else more appropriate to what may be happening upstream will likely yield better results

tcp_bic Binary Increase Congestion control is an implementation of TCP with an optimized congestion control algorithm for high speed networks with high latency (called LFN, long fat networks, in RFC 1072). BIC is used by default in Linux kernels 2.6.8 through 2.6.18. (wikipedia)

tcp_cubic CUBIC is a less aggressive and more systematic derivative of BIC, in which the window is a cubic function of time since the last congestion event, with the inflection point set to the window prior to the event. CUBIC is used by default in Linux kernels since version 2.6.19 (wikipedia)

tcp_highspeed HSTCP defined in RFC 3649 for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation. wikipedia

tcp_htcp optimized congestion control algorithm for high speed networks with high latency (LFN: Long Fat Networks). (wikipedia)

tcp_hybla aims to eliminate penalization of TCP connections that incorporate a high-latency terrestrial or satellite radio link, due to their longer round trip times. (wikipedia)

tcp_illinois It is especially targeted at high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, (wikipedia)

tcp_lp Objective is opposite normal, to achieve low priority utilizing only excess network bandwidth (ece.rice.edu)

tcp_htcp-lp Not available by default. Like tcp_lp except for long distance high bandwidth networks

tcp_scalable Scalable TCP is a simple change to the tradtional TCP congestion control algorithm (RFC2581) which dramatically improves TCP performance in highspeed wide area networks. (deneholme.net)

tcp_vegas Until the mid 1990s, all TCPs set timeouts and measured round-trip delays were based upon only the last transmitted packet in the transmit buffer. University of Arizona researchers Larry Peterson and Lawrence Brakmo introduced TCP Vegas, in which timeouts were set and round-trip delays were measured for every packet in the transmit buffer. In addition, TCP Vegas uses additive increases in the congestion window. This variant was not widely deployed outside Peterson's laboratory. (wikipedia)

tcp_veno Tries to determine whether packet loss is due to congestion or random packet loss then modifies, good for wireless networks (ieee). May not be appropriate for highes congestion, initial appears to enlarge windows (>1518 bytes) and longer TTL. Can result in frozen condition.

tcp_westwood is a sender-side-only modification to TCP NewReno that is intended to better handle large bandwidth-delay product paths (large pipes), with potential packet loss due to transmission or other errors (leaky pipes), and with dynamic load (dynamic pipes). (wikipedia)

tcp_westwood+ not a default option, like Westwood but for both wireline and wireless. Like westwood, starts more slowly


<<Previous Page                Next Page>>

Comments