NEW

2024 True Cost of a Security Breach

Arrow pointing right
ExtraHop Logo
  • Productschevron right
  • Solutionschevron right
  • Why ExtraHopchevron right
  • Blogchevron right
  • Resourceschevron right

Arrow pointing leftBlog

To Nagle or Not to Nagle, That is the Question

Justin Baker

February 25, 2009

laurence6-4439
In our work with customers, we've come across the question of Nagling quite a few times. When we show network engineers that they have a relatively high number of Nagle Delays, it's not unusual to hear this response "That Nagle's algorithm, I don't know what it's good for. I've never seen it do anything but cause trouble, we should just always turn it off".

Well should you? As is true for almost any meaningful question, the answer is, "it depends".

NEW: Check out our TCP Optimization Guide, featuring Nagle's Algorithm TCP RTOs, and more TCP troubleshooting tips.

Nagle's algorithm, named after John Nagle, is way to improve TCP efficiency by reducing the # of packets sent over the network. The idea is that when an application repeatedly send small packets, for each packet, TCP still tacks on a 40 byte header, that's a lot of potential overhead. So the Nagle's Algorithm just combines them, and send them out in larger-sized packets. Sounds reasonable, right?

Unfortunately since Nagle's algorithm effectively only allows one packet to be actively transporting on the network at any given time, this tends to hold back traffic due to the interactions between the Nagle's algorithm and delayed ACKs. This is especially the case if you have an interactive application, or chatty protocols with a lot of handshakes. In general, Nagle will kill the performance for SSL, Citrix and CIFS (Common Internet File System).

Well then couldn't you always leave it off? No, because such a simplistic recommendation would then lead to the overhead and wasteful packet problem Nagle was trying to solve in the first place.

Although there is no simple rule of thumb as this is very dependent on your traffic patterns and application mix, this is generally what we recommend to our customers:

ui3
1. Leave the ExtraHop box running to get some baseline data (we provide a comprehensive set of TCP stats as well as application- and transaction-level metrics)

Look up the TCP stat under your key switches. If you show minimal to no Nagle Delay, and you know that Nagle is turned on, then great, Nagle is not causing any problems, continue to leave it on.

Alternatively, if you see high number of Nagle Delays as a percentage of overall traffic, then you might consider turning it off.

In the 3rd scenario, if you started out with Nagle's left off, and see a high Tinygram number, then you may consider turning it on. After which, soak in more data, as in go back to step 1, rinse, repeat.

As you can see, tuning tends to be an iterative process. So that wraps up this post, and if you haven't guessed it by now, yes Nagle Delay is our Metric of the Day.

Got a Nagle story you want to share? Definitely leave us a note in the comments!

  • Helen

Experience RevealX NDR for Yourself

Schedule a demo