Mac Geekery

Answer

That’s a longer answer than you wanted. There are a lot of other options for tweaking the network stack in Mac OS X, mostly by setting some kernel variables.

Selective Acknowledgements

Darwin 8.2 (Tiger) does not support Selective Acknowledgments. As for getting around it, well, unless you want to take the code from a BSD networking stack and wire it into xnu and build yourself a new kernel, that’s where we stand. I suppose the best you could do is place a network device that supports SACKs in-between you and the lossy source, presuming that source isn’t your wireless base station. Not to say there aren’t alternatives…

net.inet.tcp.newreno implements the New Reno modification to the TCP Fast Recovery Protocol (RFC 2582). New Reno is the name given to an enhancement to TCP partial acknowledgments that is used in the absence of a stack that supports SACKs. Keep in mind that while this shouldn’t cause problems in the normal case, it’s only really useful over a congested link like, say, checking mail while streaming NPR or similar. Even then, it’s not a magic bullet. No harm in turning it on, but understand what it is and isn’t, first. It’s off by default.

Window Sizes

net.inet.tcp.recvspace and net.inet.tcp.sendspace control how much buffer space is allotted per socket connection, per direction. This is how much data the kernel will cache on a socket while the application chews on it. For large data streams like downloads this won’t matter. For lots of little requests, this is golden. Defaults to 32K each way but moving that higher lets the system get larger graphics cached and ready for your web browser if it falls behind the network traffic, and Safari always does.

Stack Sizes

net.inet.tcp.sockthreshold sets the number of open sockets needed for the system to actually obey your sendspace and recvspace marks. If the number of open sockets is below this number then the buffers are set to 64K, regardless of what you’ve set them to. This means that the system allocates 64K of buffer space to each socket connection direction, or 128K total, until you get to 256 open sockets, at which point they’re set to 32K (the default send/recvspace values). Set to 0 to disable and always use your custom sizes (not really a good idea).

kern.ipc.somaxconn controls the size of the connection listening queue and typically only needs to be adjusted in high-performance server environments. The default value of 128 is more than adequate for a home/work machine and most workgroup servers. If, however, you are running a high-volume server and connections are getting refused at a TCP level, then you want to increase this. This is a very tweakable setting in such a case. Too high and you’ll get resource problems as it tries to notify a server of a large number of connections and many will remain pending, and too low and you’ll get refused connections.

net.inet.tcp.mssdflt sets the default Maximum Segment Size, or the largest that the system will set the data portion of a TCP packet to. By default, many BSD-derivatives will set this to 512 bytes. Bad. Ethernet supports a frame size of 1,500 bytes on links up to 100 Mb so if that’s what you’re connected to then up this bad boy to the size of your frame minus the size of a TCP header and options (60 bytes) and get set it to 1,440.