As a “sequel” to yesterday’s Vendor Chronicle‘s post, I’m going to tell a story about what happens when a client is stuck in the middle between multiple vendors. This is when the finger pointing really gets bad, and the blamestorms escalates to the “galactic” level.

So once upon a time, in a galaxy not so far away, we ran into a customer in the transportation business that moved a lot of files across the network. A lot of important shipping related documents are stored in NetApp storage devices and acessed via LANs and WANs, routing out through Cisco switches. Similar to our etailer from yesterday, they started seeing major performance issues, and was able to narrow it down to somewhere between the NetApp storage devices and the Cisco switches.

This is when the vendor wars started. Of course Cisco says, it’s clearly the NetApp’s fault, and Read more on Vendor Wars Episode II: A New Hope…

“We surveyed 100 people, and the top answers are on the board.” Ok, so the Internet Society (ISOC) didn’t really say that, but they did survey their members regarding IPv6 and found that “specific business-case drivers did not yet exist” for IPv6. But what if you run out of address spaces? Aren’t you worried about that? (An event that’s widely projected to happen in 2012.) Well that’s ok, we’ll just use NATs more! (Great, leading to other possible management challenges.)

Read more on Survey Says: No Business Case for IPv6, We'll Use NATs instead…

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”.

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 Read more on To Nagle or Not to Nagle, That is the Question…