TCP_SACK - On or off?
Whenever it comes time for me to do some kernel tuning, I always enter a debate in my mind around tcp_sack. It was introduced to TCP in ([url]
tcpsack was introduced to deal with especially unreliable connections. It's a selective acknowledgement that enables parts of a missed packet to be retransmitted. This requires additional resources (memory and CPU) on both sides to handle this. tcpsack also allows tcpfack (Forward Acknowledgment, deals a bit with congestion) and tcpdsack (Duplicate SACK, tells the transmitter when a packet was received twice) to be enabled.
Within a data center - or some other high controlled environment - it does not make sense to have tcpsack enabled. Within these environments, any significant packet loss is indicative of a more serious problem that a simple kernel parameter might work around, but will not solve. Over the general internet, I'm not too sure. One does experience some levels of packet loss (especially over cellular networks, but is this handled by a lower level protocol? I'm not all too familiar with 3G, EDGE, etc). Our networks are far more reliable that what they used to be, so I see no real application for tcpsack - at least in my world. Disabling tcp_sack allows for a little bit (not sure how much) more of the kernel network memory to be used for queuing, rather than for something that was designed with dial-up in mind.
The thing that perturbs me the most is that tcp_sack is enabled by default on every distro that I've encountered. Sure, most kernels shipped with a distro include modules that most people would almost never use. Or maybe I'm obsessing over one little thing too much.
What are your thoughts?
1 Reply
> tcp_sack was introduced to deal with especially unreliable connections.
…
This requires additional resources (memory and CPU) on both sides to handle this.
…
Within a data center - or some other high controlled environment - it does not make sense to have tcp_sack enabled.
…
Over the general internet, I'm not too sure. One does experience some levels of packet loss
Perhaps this is the reason you think this
> Our networks are far more reliable that what they used to be