Last year I wrote about the tradeoffs embedded in Nagle's algorithm. I also described our "AutoNagle" setting, which meant to take some of the pain out of figuring out what to do with this feature. Beginning in TMOS® version 13.0, we've substantially improved the logic to make the right decision for your application, without you having to get involved.
But first, a refresher. Nagle's Algorithm seeks to reduce the number of packets TCP sends by sacrificing latency. When it has less than one full packet to send, it will wait for additional data until all data in flight is acknowledged. This reduces the waste of sending more headers, and saves power on mobile devices, but it also means that the last packet of a message tends to wait at least a few milliseconds and hold up the next step in the transaction. Whether or not that trade is worth it depends a lot on the specifics of your network.
Our Autonagle algorithm already handled some common cases to make a smart decision. But now, the logic covers a much wider range of circumstances.
If there is an HTTP or SSL profile installed on the virtual server*, Autonagle will enable Nagle's algorithm. This is because F5 implementations of both protocols now signal TCP when they have no more data to send, so it doesn't wait around for data that will never arrive. This eliminates the latency penalty, so there is little cost to aggregating packets.
If there is no such profile, Autonagle starts with Nagle's algorithm disabled. It will turn Nagle on if it meets two criteria: (1) it detects that the peer is not using delayed acks, as in the original Autonagle; and (2) that the measured Round-trip-time (RTT) is less than 20ms. Under these conditions, Nagle's latency penalty is low enough to make packet reduction worthwhile for the vast majority of applications.
As before, the Autonagle setting always concatenates packets in the buffer regardless of Nagle's algorithm. the auto-enabled mode also allows one undersized packet in flight at a time, which often lets the last packet of a message to go out immediately.
When autonagle disables Nagle's algorithm, it now prevents the BIG-IP from splitting incoming packets into multiple smaller ones in most cases. Even if users prioritize speed over packet counts, actually increasing the number of packets over what the server would do on its own is undesirable, and does not really help with message latency.
There are users out there that want to always minimize packet counts, or always minimize latency. For them, we still have the choice to enable or disable Nagle's algorithm altogether. For everyone else, you're probably best off just letting F5 figure out this setting for you.
*If there is an HTTP/2 profile present as well, it will not enable Nagle.
This is a really great article, and I'm really glad you guys decided to implement this feature. I've worked for a number of companies that used F5 equipment, and only at one of them was there a good understanding of what Nagle's algorithm was, and only at that company did anyone attempt to correctly turn it on or off. Even still, a lot of the time we didn't have the time to try to figure out whether Nagle was beneficial for a given application, so we just defaulted to leaving it off, accepting that we'd not be optimized. Having this be handled automatically is great and should benefit almost everybody.
