Hello,

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‎]www.ietf.org/rfc/rfc2883.txt‎[/url]) and is described in detail there and elsewhere.

tcp_sack 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. tcp_sack also allows tcp_fack (Forward Acknowledgment, deals a bit with congestion) and tcp_dsack (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 tcp_sack 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 tcp_sack - 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?

Think you just answered your own question.



Perhaps this is the reason you think this