When a Broadcom customer couldn’t achieve the desired quality of service (QoS) behavior they expected from their Broadcom chipset, they were advised by Broadcom to upgrade their SDK. That’s when the customer came to us at IP Infusion to handle their SDK upgrade problem and solve the QoS issue. They wanted to offload the risk of upgrading the older SDK and needed their own staff to focus on current product features. The challenge was that we were given only six weeks to upgrade the SDK and solve the QoS issue. When the new SDK didn’t fix the QoS issue, we knew that the problem lay in the traffic management configuration of the application.
IMAGE
In only one to two days, I found the underlying issue – the traffic scheduling wasn’t configured correctly. Buffer allocation and Queue mapping of traffic based on Class of Service (CoS), wasn’t set up according to the specifications. This was causing lower priority packets to drain the resources of higher priority packets. The fix was to classify packets to two different pools of buffers and add a custom limitation on usage of buffers per priority. Further limits were applied on lower priority packets from draining the buffer resources, making it available to higher priority packets – solving the customer’s issue in record time.
How did I find the issue so quickly? My passion in software development is traffic scheduling. I’ve had the chance to work with industry standard chipsets for switching and routing, from vendors such as Juniper, Cavium, Broadcom and HP Enterprise in developing applications and troubleshooting. As an expert in classification, policing, scheduling and shaping, I was able to reproduce the problem and look for the root cause. We upgraded the SDK and were able to satisfy QoS up to the customer’s expectations because of our experience and expertise in SDKs, switching, routing and especially traffic management which I’ve focused on for years.