* How service providers use the queuing algorithms found in Juniper routers to implement class-of-service functionality
In our last newsletter, we continued the discussion of MPLS service-level agreements that we started in late April.The focus of the last newsletter was a description of how service providers typically implement the queuing mechanisms supported in Cisco routers to support class-of-service functionality in their MPLS service offerings. In this newsletter, we will look at the same topic from the perspective of service providers that use routers from Juniper. We will also look at other key issues that enterprise IT organizations need to be aware of as they implement MPLS services.
As we mentioned in our last newsletter, we have been getting a lot of feedback from readers on this topic – one of whom was Nathan Wilkes, the principal network architect at Virtela. Nathan explained that Juniper has a concept of low-, high-, and strict-high-priority queue scheduling. He stated that Juniper routers service all queues using Weighted Round Robin (WRR) techniques that add Priority Queuing. Juniper creates guaranteed servicing of their Strict-High queue through a system of credits. While High and Low priority queues can fall into ‘negative’ credits during WRR, the Strict-High always has positive credit and always has the opportunity to be serviced.
Nathan mentioned that there are other factors that must be looked at when implementing MPLS. An example of this is the amount of buffer reserved in memory on the router for a given queue. For example, an IT organization may want a 256Kbps link to support a number of applications. However, if there is a considerable amount of priority traffic on that link, then it is important to have a lot of buffer space because having a lot of priority traffic means that the traffic from other applications will have to be queued for longer periods of time. Having a lot of buffer space means that it is unlikely that the non-priority traffic will be dropped. However, it also means that the delay associated with the non-priority traffic will likely increase.
Nathan also reinforced a theme that we touched on in an earlier newsletter. That theme is that most IT organizations do not have a good handle on their applications and the network requirements of those applications. As such, when MPLS is first being implemented few IT organizations are able to accurately establish a class-of-service profile and assign all of their applications to the appropriate service class. Instead, most companies get started with the best estimate that they have and refine that estimate over time as they get a better understanding of their applications and the network requirements of those applications.
The bottom line is clear. IT organizations that are considering deploying an MPLS service need to get a thorough understanding of the queuing mechanisms that the service provider uses to implement class-of-service functionality. IT organizations then need to translate abstract queuing algorithms into what that means for their supporting their company’s key applications, based on the requirements of those applications.
