
Author Profile - Ray Tompkins is the Founder and CEO of Gearbit. Ray is a Senior Network Specialist with over 28 years experience in troubleshooting, design, and implementation. His background includes 911 emergency consulting, and identifying the root cause of critical network problems. His knowledge of network protocols (LAN, VoIP, WAN and WLAN) and how they work within the enterprise networks are the key in providing customer service though knowledge transfer and education.
As I imagine most of you are, I’m always looking for performance tuning ideas, something that really helps improves performance, preferably with minimal cost. Recently, while reviewing trace files, I discovered the cause of an issue I was troubleshooting: Nagle’s algorithm had struck again.
Don’t get me wrong, I’m not against Nagle or his algorithm, but I don’t like it when things work against you, like my wife’s car, which has an alarm system that locks all the doors, usually when you least expect it. I like the thought of safety, but lock all the doors but mine. I’ll lock my own door, thank you.
Nagle's Congestion Control in IP/TCP Internetworks (RFC 896) describes what he called the "small packet problem," where an application repeatedly emits data in small chunks, frequently only one byte in size. Since TCP packets have a 40 byte header (20 bytes for TCP, 20 bytes for IP) and Ethernet 18 byte (14 bytes source and destination, type and 4 bytes CRC), this results in a 59 byte packet for one byte of useful information, a huge and usually unnecessary overhead.
This situation often occurs in Telnet sessions, where most key presses generate a single byte of data that is transmitted immediately. Worse yet, over slow links, many such packets can be in transit at the same time, potentially leading to congestion collapse.
Just as my wife’s car locks all the doors, with good intentions, Nagle’s Congestion Control can have a negative effect. In Figure 1, a 200 millisecond delay interrupts the flow of data being transmitted. Using IO Graphs within Wireshark it become more obvious.
Correcting the problem was straight forward by turning off Nagle’s setting, a registry setting with Microsoft.
One last word of wisdom: always monitor the results of any tuning configuration changes carefully to be absolutely sure that it has a positive impact. I always look through the trace file that is measuring the results to confirm that the change had a positive effect.
Author's Note: If you enjoy technology as much as I do, please take a moment and sign up for the gearbit monthly newsletter. You won't be disappointed.
We'll cover technical topics such as,
- How to script those repeated tasks
- How to decode those ugly problems
As well as other tech news of what's happening in the tools market.
So please take this time and fill out the newsletter request form.








Recent Comments