Networking-Blog

My WordPress Blog

Cisco TCP Tuning

ip tcp ecn
ip tcp chunk-size 65535
ip tcp window-size 750000
ip tcp queuemax 500
ip tcp synwait-time 20
ip tcp selective-ack
ip tcp timestamp
ip tcp path-mtu-discovery

ip tcp ecn

The TCP Explicit Congestion Notification (ECN) feature provides a method for an intermediate router to notify the end hosts of impending network congestion. It also provides enhanced support for TCP sessions associated with applications that are sensitive to delay or packet loss including Telnet, web browsing, and transfer of audio and video data. The benefit of this feature is the reduction of delay and packet loss in data transmissions.

ip tcp selective-ack

The TCP selective acknowledgment mechanism helps improve performance. The receiving TCP host returns selective acknowledgment packets to the sender, informing the sender of data that have been received. In other words, the receiver can acknowledge packets received out of order. The sender can then resend only the missing data segments (instead of everything since the first missing packet).

ip tcp window-size 12384

This is where you set the Rwin. This is the single most important tweak, and raising the value from the Windows default will greatly improve download speeds. My Rwin is set to 65535.

ip tcp queuemax 15

The queue for outgoing TCP packets
Default
5 for TTY (async and console) interfaces; 20 for others
This command sets the size of the outgoing TCP queue to packets. The queue is maintained per-connection; i.e., every connection has its own queue.

ip tcp mss

Interacts with the ip tcp path-mtu-discovery command and not the ip tcp header-compression command. The ip tcp path-mtu-discovery command changes the default MSS to 1460 even for nonlocal nodes.

The maximum segment size (MSS) is an option of the TCP protocol that specifies the largest amount of data, specified in bytes, that a computer or communications device can receive in a single, unfragmented piece. It does not count the TCP header or the IP header[1]. For optimum communications, the number of bytes in the data segment and the headers must not add up to more than the number of bytes in the maximum transmission unit (MTU).

The MSS is an important consideration in Internet connections. As data is routed over the Internet, it must pass through multiple gateway routers. Ideally, each TCP segment can pass through every router without being fragmented. If the data segment size is too large for any of the routers through which the data passes, the oversized segments are fragmented. This decreases throughput and increases latency, in some cases dramatically[2]. The likelihood of such fragmentation can be minimized by keeping the MSS as small as reasonably possible. Every host is required to be able to handle an MSS of at least 536 bytes.

For most computer users, the MSS option is set automatically by the operating system on the SYN packet during the TCP handshake. Each direction of data flow can use a different MSS.

Linux TCP Tuning

To change TCP settings in Linux, add the entries below to the file /etc/sysctl.conf, and then run sysctl -p. The system will also set these values at boot time.

# increase TCP maximum buffer size
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

# increase Linux autotuning TCP buffer limits
# min, default, and maximum number of bytes to use
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Set the maximum buffer sizes to a value large enough to handle the longest, fastest network link you think that host will encounter (16MB in the example above). Windows does not require any modifications, as the default maximum TCP buffer size (GlobalMaxTcpWindowSize) is not defined. My TCP Tuning Guide web site has information on how to set the maximum buffer size for other OSes.

Tuning TCP for Linux 2.4 and 2.6

NB: Manually adjusting socket buffer sizes with setsockopt() disables autotuning. Application that are optimized for other operating systems may implicitly defeat Linux autotuning.

The following values (which are the defaults for 2.6.17 with more than 1 GByte of memory) would be reasonable for all paths with a 4MB BDP or smaller (you must be root):

	echo 1 > /proc/sys/net/ipv4/tcp_moderate_rcvbuf
       	echo 108544 > /proc/sys/net/core/wmem_max
       	echo 108544 > /proc/sys/net/core/rmem_max
       	echo "4096 87380 4194304" > /proc/sys/net/ipv4/tcp_rmem
       	echo "4096 16384 4194304" > /proc/sys/net/ipv4/tcp_wmem

    
All standard advanced TCP features are on by default. You can check them by: cat /proc/sys/net/ipv4/tcp_timestamps cat /proc/sys/net/ipv4/tcp_window_scaling cat /proc/sys/net/ipv4/tcp_sack Linux supports both /proc and sysctl (using alternate forms of the variable names) Eg. net.core.rmem_max) for inspecting and adjusting network tuning parameters. The following is a useful shortcut for inspecting all tcp parameters: sysctl -a | fgrep tcp To detect network errors and signaling connection problems, You can enable TCP keep alive feature. It will increase signaling bandwidth used, but as bandwidth utilized by signaling channels is low from its nature,the increase should not be significant.Moreover, you can control it using keep alive timeout. The problem is that most system use keep alive timeout of 7200 seconds, which means the system is notified about a dead connection after 2 hours. You probably want this time to be shorter, like one minute or so. On each operating system, the adjustment is done in a different way. After settings all parameters, it's recommended to check whether the feature works correctly - just make a test call and unplug a network cable at either side of the call. Then see if the call terminates after the configured timeout. Here are some hints: Linux systems: Use sysctl -A to get a list of available kernel variables and grep this list for net.ipv4 settings (sysctl -A | grep net.ipv4). There should exist the following variables: - net.ipv4.tcp_keepalive_time - time of connection inactivity after which The first keep alive request is sent - net.ipv4.tcp_keepalive_probes - number of keep alive requests retransmitted before the connection is considered broken - net.ipv4.tcp_keepalive_intvl - time interval between keep alive probes You can manipulate with these settings using the following command: sysctl -w net.ipv4.tcp_keepalive_time=60 net.ipv4.tcp_keepalive_probes=3 net.ipv4.tcp_keepalive_intvl=10 This sample command changes TCP keepalive timeout to 60 seconds with 3 probes, 10 seconds gap between each. With this, your application will detect dead TCP connections after 90 seconds (60 + 10 + 10 + 10).
You can decrease the net.ipv4.netfilter.ip_conntrack_tcp_timeout_established, by half, at least. You can decrease also the following. net.ipv4.netfilter.ip_conntrack_tcp_max_retrans = 3 net.ipv4.netfilter.ip_conntrack_tcp_be_liberal = 0 net.ipv4.netfilter.ip_conntrack_tcp_loose = 1 net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans = 300 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close = 10 net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack = 30 net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait = 120 net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 14400 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60 net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent = 120 sysctl -w net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=14400 (14400 = 4hours)