Enterprise QoS Part 00 – Series Introduction

606 Words. Plan about 2 minute(s) to read this.

Network engineers the world over have a loathing for quality of service (QoS). Next to IP multicast, QoS ranks near the top of the list of frustrating network technologies. But not for me. I thoroughly enjoy QoS. Why? QoS addresses real world problems of traffic not being delivered on time or at all. When correctly applied, QoS strategies affect real, positive changes for applications riding across a busy network. Done right, QoS helps ensure that traffic is delivered every time, and on time.

I have been fortunate enough to deploy network-wide QoS at a couple of enterprises, and I’m currently evaluating a QoS strategy for a third enterprise that currently doesn’t have one. As with any network deployment, the problems I’ve leveraged QoS to solve have been similar, yet unique. For example…

  • Different applications require different QoS treatments.
  • Different physical media require different QoS implementation techniques.
  • Different hardware platforms have different QoS capabilities that require different code.
  • Sundry applications mark their traffic, but with no predictable strategy, and no guarantee that traffic is marked at all.

In this series, I’m going to talk through an enterprise QoS deployment strategy based on my experience. I’m not trying to write a book; this series was inspired by a QoS workshop I’m writing for Interop NYC 2013. So, I’m going to stick with a specific enterprise scenario, and then build an QoS strategy for it. The scenario I’ll be following is as follows:

  • This is an enterprise (i.e. not service provider) network. While service providers certainly offer various classes of service across their infrastructures, many of the techniques used (reservation of bandwidth across an specific MPLS path, for instance) are not typically used in enterprise environments.
  • The enterprise features a campus Ethernet running IPv4.
  • The enterprise connects to several remote offices via a wide area network. The WAN is supplied via an L3VPN MPLS service provider that hands off Ethernet or HDLC to the enterprise’s edge router. The enterprise owns the WAN edge router; it is not managed by the carrier.
  • The enterprise runs voice, video and other data types across their infrastructure.

The intent of this scenario is address QoS for a common enterprise topology running a common combination of traffic types. Storage over IP is also common (iSCSI, NFS), but tends to be isolated to the data center network segments of the enterprise. Applying QoS for storage traffic is a different sort of problem, and one that I plan to address in some blog posts & a Packet Pushers podcast of its own. The focus here will be on doing our best to guarantee timely delivery of a variety of traffic classes between endpoints that are potentially quite far from each other, at least in a network sense.

I’ve broken the series into several parts as listed below, which will post over the next several days. If QoS interests you, I hope you follow along. Please enjoy, and send your feedback to me via ethan.banks@packetpushers.net.

  1. What is QoS, what does it do, and why do network engineers hate it?
  2. Why do some applications require QoS, while others do not?
  3. Isn’t packet delivery at all costs the most important thing?
  4. Can someone please explain all of these QoS terms?
  5. A consistent QoS strategy: L2 & L3 traffic marking & Cisco AutoQoS.
  6. A consistent QoS strategy: queueing collaboration applications.
  7. A consistent QoS strategy: shaping to match far-end bandwidth while still prioritizing.
  8. A consistent QoS strategy: end-to-end packet walk – congested vs. non-congested.
  9. QoS corner cases: throttling a bandwidth hog.
  10. QoS corner cases: tunneled traffic.
  11. QoS corner cases: DSCP mutation maps.

Search for all parts in the Enterprise QoS series.


Ethan Banks writes & podcasts about IT, new media, and personal tech.
about | subscribe | @ecbanks

4 thoughts on “Enterprise QoS Part 00 – Series Introduction

  1. Nice series Ethan! Most of the hate comes from people not understanding it, same as with multicast. I have to say that the Catalyst QoS is pretty horrible though. The MQC syntax is so much better, it’s a shame that not all the new switches get it, Catalyst 3850 has it.

    Also due to ASICs every platform has a bit different implementation which can be a big hurdle to get over. I used to work for one of Europes largest ISPs and they had a guy (CCIE) that did QoS almost full time. There’s a lot to consider when you have different CPEs, different PEs, how many classes do you need? How do you handle MPLS? What values to use for WRED? Is behaviour the same on this new version of IOS? And so on…

    Looking forward to this series.

  2. I am very excited for this series. My company is currently deploying QoS in an almost identical scenario as described for this series. I can’t wait to compare our thoughts to this series and get a great discussion.

  3. Great! I’m going to follow a whole series. I hope it will inspire me to deep dive into the QoS topic. I always walked around the QoS technology:) and maybe this time it encourage me to learn more about it.

  4. Ethan,

    This series is great. Format and structure definitely takes you on a journey. I feel empowered after reading it. QoS is definitely a weaker area for me but this is a great practical guide to deployment. Good luck at Interop!

    I owe you a few beard rubs.

    /Anthony

Comments are closed.