Where Packets Never Die

I talked with a fairly large service provider yesterday regarding quality of service(QoS) possibilities for a particular network. Essentially, we were trying to figure out what was available from a queues perspective so that we could make sure we were able to classify traffic as effectively as possible.

I had been told that the existing QoS policy was defined as a 75/24 ratio with 3 queues. I didn’t think that could be right. Who runs 75% EF, 24% AF, and 1% BE on their network? Every other enterprise class network I had worked on had somewhere between 4 and 6 queues with 10% at the most dedicated to EF.

A phone call with this provider verified that they were in fact dedicating 75% to EF traffic. Once my brain processed that, I asked what other queue models were available. To my surprise, the following models were available:

 

Class(DSCP) Policy 1 Policy 2 Policy 3 Policy 4 Policy 5
EF(46) 75 75 90 50 25
AF41(34) 24 20 9 25 40
AF21(18) N/A N/A N/A 24 30
BE(0) 1 5 1 1 5

 

I didn’t see anything that made me jump for joy, but at least there were a couple of models that gave me the 4 queues I wanted. EF, per RFC 3246, is designed for the following:

“EF is intended to provide a building block for low delay, low jitter and low loss services by ensuring that the EF aggregate is served at a certain configured rate.”

That sounds a lot like voice traffic, but not too much like all the other types of traffic that need to traverse the WAN. You could consider putting video in the EF queue, but it has been my experience that you leave EF just for voice. Video tends to go in one of the AF buckets.

For the rest of the afternoon, I was trying to understand why a service provider would do something like this. I have to be honest and state that I have no idea. I’ve read a few things that mentioned service providers in other countries only having 3 queues for high, medium, and low traffic, so service providers in the US who have global networks try to match the lowest common denominator. In this case, I don’t know that we can make that assumption. I wasn’t aware of any service from this provider outside of the US.

Is this a case of “just because you can doesn’t mean you should”? Or, am I missing something here and not considering the bigger picture? I see an EF queue value of 90% and I think this must be the network sprinkled with unicorn dust where packets never die. Tail drop is non-existent and all packets fly first class. Nerdvana indeed.

This entry was posted in data center, qos and tagged , . Bookmark the permalink.

6 Responses to Where Packets Never Die

  1. Alexandra Stanovska says:

    Is it like they really dedicate that amount of BW to ef or is it “up to”? Because where I work, we offer various profiles with COS1 up to 80% or 90% depending on link speed, ie. only ef 90% and 10% default. Although I have never seen anybody using it this way, it’s mostly really 10% and various amounts of remaining classes. (Well OK maybe 30% on really slow speeds like 64k or 128k.) Maybe this SP has really good highly overprovisioned network and does not need to do cap checks when they guarantee 70% just like that to everyone 🙂

    • Alexandra,

      That’s a good question. In any event, it is COS5/DSCP46 up to 90%, which is very large on links with high bandwidth. As far as I know, they do not have an overprovisioned network. It may be that there haven’t been any problems, so they are able to offer 90% EF. I don’t presume to be an expert on QoS matters, but something just seemed odd about being able to get EF traffic that exceeded AF and BE rates.

  2. stretch says:

    We have plenty of customers with MPLS circuits which are used primarily for voice traffic. In these cases, it makes perfect sense to go with a high-percentage priority queue for EF like policy three offers.

    • Well then that would make sense. However, these are sites with bandwidth approaching fractional DS-3 levels(ie 20Mbps). That’s a LOT of voice traffic even using G.711!

  3. Daniel G says:

    Based on some experience I’m guessing this is Paetec/Windstream?

Comments are closed.