VoIP, QoS and MPLS ... Wanna buy a bridge?

[sil]

John, Jane and George work at the Empire State Building in New York City, they each leave work at 5PM and are always in a rush to get home. One day while rushing to get home, all three individuals rush into the revolving door, they're now jammed into the door. On the way out, they can only exit one person at a time. To alleviate this problem, the building's owner decided to place a doorman in the lobby to direct traffic out the door in order to avoid having that congestion. He decided it would be best to let them out in order of importance. John, Jane and George again rushed home one day.

When arriving at the door, the doorman stopped them all. “I will let you each out in the order of importance. John, since you're going to the doctor on a daily basis, you'll always go first; Jane, since you rush home to your children, you'll be second; George since you simply rush to get out of work, you're entry and exiting is not that important, you'll go third." Welcome to MPLS, traffic shaping.

MPLS and VoIP is such an overrated and misunderstood technology its scary. To me its nothing more then a vendor selling you hype, here's why. Imagine having say a T1 connection in one of two offices, you pay more for MPLS services to deliver VoIP first, everything else second. Is one packet of data more important then the next? If you answered yes!, I have some news for you. Time to wake up and smell the coffee. You don't need MPLS/traffic shaping. What you need is more bandwidth period. So you buy into MPLS and send voice first. On your T1 you allocated 75% of the traffic for voice. Your offices are now sending payroll, billing information data through the circuit. Bills need to be paid, monies need to be collected, workers need their paychecks. This is what keeps your business going just as much as your phone calls. Is this data less important? Let's be realistic here.

Your office is sending this financial data, they now have to get some critical data through to a vendor who is creating a product to bring more revenue to the business. Wait... Sorry, not at this point in time, you see, Joanne the receptionist is on a call with the nail salon making an appointment for lunch, Jerry in sales is making some golf arrangements with his client, Mike the boss is on a conference call with some vendor who is pitching a product that Mike doesn't really care about. T1? Data? Not important. Right? MPLS vendors have tons of nice talk, well thought out pie charts, a barrage of "parallel vector reverse hyperdynamic" verbiage, but I'll take more bandwidth over shaping any time, save me the dread of pie charts and acronyms please.

Data is just as important as voice traffic, so while you will kid yourself over the pros over the cons on MPLS, the truth is, MPLS and QoS is nothing more then hype. So what's the solution. More bandwidth and or better policies. Better policies though mean more configuration on your equipment, minimize P2P and other unnecessary services, you'll be surprised at how much more bandwidth you could save. MPLS? It means higher prices for fuzzy services. If you think that by configuring QoS on your own, you're doing something special, I suggest you go read some RFC's on what QoS really is. I suggest you ask those in the know before you waste time painting packets so a connected provider strips out your tags.

QoS... So a local government created a special highway. On this highway they make a rule, “red cars always go first followed by yellow cars, then blue.” Works fine when driving down that highway, but what happens when you leave that state. There isn't a rule or a law in the next state which makes it a mandatory rule that “red cars go first, yellow second, blue last”. This is QoS or “painting your packets”. So you decided you were going to send your packets marked and you thought what? Every provider was going to honor this. Think again. By the time your packet reaches their routers, information in your packet headers will be stripped and that speed you thought you gained, that “head start” you swore you had is lost. Did you take the time to sign up for "MPLS" prioritized services. Everyone has to make money somehow, if they can't get you to buy more bandwidth, they'll introduce MPLS services! You're solution to not buying more bandwidth. Its a band-aid not a solution.

You don't need MPLS, QoS, you need more bandwidth, seriously. Just because you have a doorman directing traffic doesn't mean Jane should always go through that door before George first. What happens when George has a doctor's appointment. Should the doorman have to “reconfigure” his method of thinking. What happens if the doorman isn't capable of making that decision. I love it when vendors/salespeople try to talk me into MPLS or QoS. I ask them to explain to me why outside of these common principles is MPLS a better solution then more bandwidth, most of the times the subject is changed. With networking services and equipment getting cheaper and cheaper, its a better idea to invest in more bandwidth period. You can butcher your equipment up to send data out however you see fit but in the end, there is going to be a time that will dawn on you when you'll realize the money you spent, was wasted.

Enough rambling. I have to shape my traffic to post this.

[Aaron Rosenthal]

I couldn't quite tell if you're saying that QoS is irrelevant because it absolutely is necessary for a corporate network. Agreed that QoS across multiple carriers can get complicated and this is exactly why a larger organization should really have someone managing all the routers across every location. More bandwidth isn't always the answer. If you're running VoIP over your WAN, along with application sharing, QoS is entirely necessary. I agree that most carriers do a poor job of properly configuring routers which is why it's very important that larger organizations use a fully managed router service from a 3rd party who can give the type of attention needed.

[Michael Graves]

In fact QoS is absolutely necessary, at least as long as we have RTP over UDP. The bursty nature of network traffic can cause even a generally not saturated connection to momentarily choke up. Yet we're not likely to ever see broad availability to QoS on the public internet. See Brough Turner for details or http://blog.mgraves.org/tag/qos/