I have had an opportunity to work through the years with exceptionally talented people, and have had quite a few good discussions around different technologies. One area that we tend to go back and forth over is around the value of a good buffering system within the network to ensure a high level of service. This initially was a topic I had a lot of experience with from my service provider days, when we had extremely expensive equipment, with significant reserves available for buffering traffic, and had to strike a balance between optimizing latency for voice (smaller is better), and preserving bursty TCP traffic (larger is better, up to a point).
In the past decade I’ve been interested in the concept of bufferbloat, which is similar to what I had experienced in my earlier days in the SP arena, where increasing the buffers beyond a certain point has diminishing returns, and eventually, it negatively impacts applications, especially latency sensitive ones. These are documented @ bufferbloat.net and you can google bufferbloat for a rundown. Tools have been made available to help with this.
This problem is very much like solving a problem of congestion at a breakfast buffet. When you are at a breakfast buffet some people want custom made omelets. And others, just want to eat muffins. Imagine there is a single waiting area for these people. The people that want custom made breakfasts, may make up only 20% of the people, but take up 80% of the time in the line. And the people waiting to grab those muffins, they are quick to serve but make up 80% of the people.
Now imagine this line is getting full and people are lining up into the dining area. You want to ensure everyone is served, and have an idea… what if I increase the waiting area? What if I increase the waiting buffer, so it can hold more people? This definitely helpful in ensuring all the people can fit into the line for breakfast, but is it the best approach? There are going to be an awful lot of people that still need to wait to grab their muffins, waiting behind those slow moving omelet people. Certainly there could be benefits for the muffin lovers (like myself) to waiting in line… we could use the time to do something like air squats, or lunges, to pass the time and prepare the body for the onslaught of carbohydrate goodness. But for most muffin lovers, it’s a real slowdown. And some may even just walk away, or retry later.
Would a better option potentially be to impelement an intelligent option that ensures the people who just want to grab their muffins, are able to just, go get them… without being in line with the omelet lovers? So if you require a long wait, you can wait for your omelet… and people who just want a quick muffin can just go get their muffin and get on with their day.
This is the idea behind intelligent buffering in a system. Just adding more space in the waiting area doesn’t address the fact that 80% of traffic are small packets, and a lot of times, these small packets, are critical to the system. DNS and name resolution queries, ack’s, kerberos/authentication/KMS… every time an app wants to use a resource, no matter what resource, it likely is using all three of these protocols, and making them wait in a queue slows down all applications.
There are certainly use cases for large buffers. Especially in a fairly homogenous system, where a singular application or application type is more than predominant and bursty in nature. Where there aren’t a lot of… muffin eaters. If everyone wants omelets, there is little use for differentiation of the two… just make a big omelet line. In these cases (fairly homogenous traffic type, but very bursty in nature), large buffers can be helpful. However, most enterprises are much more heterogenous, lots of applications, large flows, but very critical small flows (authentication, resolution), of which latency can greatly affect the application performance.
I encourage you to read about buffer bloat, and understand, big queues can be good for a small set of use cases, but in my experience where there are a lot applications sharing an infrastructure, adding more queue to serve a particular application can come at the expense of all the others, and treating the traffic intelligently at the outset, can benefit all the applications and is typically a superior approach.
Strongedge.io 