TCP Tuning and Behaviour

Question

I have the following questions about TCP:

Regarding the following two parameters related to TCP connection in sysctl in Linux. Which one of them does the Linux TCP stack consider for the receive window when it establishes a connection:

I. net.ipv4.tcp_rmem

II. net.core.rmem_max

The first parameter contains 3 values (Min, Default and Max). Whereas the second one contains only one value.

Additionally how does TCP calculate the initial MSS during the Handshake? My initial guess is TCP considers the MTU and it subtracts the TCP/IP/LLC Headers Length, is it correct?
Does the two ends agree on one MSS to use during the handshake? Or each side can his own MSS?
What would be the reason behind having only one congestion control in the Linux Kernel? i.e when I execute the following command:
sysctl .net.ipv4.tcp_available_congestion_control

I only get reno. Even-though I have Linux Kernel 3.14.0 , should not I get Cubic too? Or do I need to have specific configuration while compiling the Kernel?

Accepted Answer

http://www.psc.edu/index.php/networking/641-tcp-tune explains that TCP Autotuning automatically adjusts socket buffer sizes as needed to optimally balance TCP performance and memory usage... Autotuning is now enabled by default in current Linux releases (after 2.6.6 and 2.4.16).

net.core.rmem_max defines the TCP max buffer size that and application can set using setsockopt()

net.ipv4.tcp_rmem define the Linux autotuning TCP buffer limits min, default, and max number of bytes

Let me start with 3)

If the desired algorithm is not yet available the following command can be used to see which algorithms are installed:

ls /lib/modules/`uname -r`/kernel/net/ipv4/tcp_*.ko

and you can issue a modprobe command to activate those

sudo modprobe tcp_westwood

2) Does the two ends agree on one MSS to use during the handshake? Or each side can his own MSS?

Each side has has its own MSS that it offers in its SYN packet, it is based on the MTU size of the route towards the destination and tries to avoid ip fragmentation by substracting 40 bytes.
The sender remembers the incoming SYN's MSS and should not exceed the segment size when sending data. Not necessarily do both MSS values have to match but they better do ...

1) As per http://www.cdnplanet.com/blog/tune-tcp-initcwnd-for-optimum-performance/
Linux kernel 2.6 offers 3xMSS typically 5840 bytes in its initial rwin offering
Linux kernel 3.0 offers 10xMSS typically 14600 bytes.

If TCP timestamp option was negotiated you will see 10X1448 or 3X1448 bytes ...