implementing qos

Have a question or want to start a discussion? Post it! No Registration Necessary.  Now with pictures!

Threaded View
I wanted to learn how to implement QoS so I was going to implement both
an IntServ and DiffServ model in a small home network but I'm not clear
on if this is possible for such a small application. In the end, my
goal is to figure out what is best for a small LAN with a few dozen
voice, video, and data apps that will send locally as well as outside
the LAN.

Also, I've read that QoS (e.g. IntServ) requires several functions on
routers and switches along the path like admission control,
classification, policing, queuing and scheduling. But say I have all
this gear, and one of the hops in the network is done over radio and
this radio may have to travel very long distances. Does QoS still work

Re: implementing qos

Most modern networks don't follow the IntServ model, and really for the
reasons you listed. There are limitations with protocols like RSVP. In
fact, it is possible for RSVP to signal a path as "adequate" if
insufficient bandwidth is present in an intermediate hop. There's also a
lot of overhead managing and signaling resources...RSVP manages at the
flow level. Imagine an interface with hundreds or thousands of flows. In
short, IntServ doesn't scale as well as the DiffServ model.

You'll find that DiffServ works well, and is the method chosen by most
network engineers today. It (somewhat) addresses the issue of crossing
network domains, that is, networks not under your administrative
control. End-to-end QoS can be challenge in these environments, but
because DiffServ is implemented in a per-hop-behavior (PHB) fashion, you
have a much more scalable scenario. Of course, the provider has to
adhere to your classification scheme or at least provide some equivalent
mapping. MPLS providers will do this, but I don't believe they will
offer anything beyond the class of service (ToS) in terms of
classification (a handful of classifications, typically "gold, silver,
bronze, and default" classes). I don't believe there are providers out
there that provide full DSCP class support.

Anyone out there confirm or deny this thought about provider support? :-)

In your home lab environment, you may find it not a terribly good ROI to
implement fancy QoS mechanisms. :-) That's *not* to say QoS doesn't have
its place in a LAN environment, especially an enterprise LAN with a
large traffic mix. I think you'll find yourself very bandwidth-rich, and
QoS won't benefit you much (if at all) in your LAN unless you can
saturate some of the interfaces. Now, as for the WAN port, you can
influence the outbound interface queues for sure as different packet
sizes and associated interface delays change things just a bit. You
could classify your traffic with appropriate ACLs, integrate them into
your traffic policy, then apply that policy outbound on your WAN
interface. You have the most control outbound. You can implement service
policies inbound, but you don't have control of what the Internet hands
you. In the case of voice, you can use/tweak de-jittering buffers to
play back the packet stream predictably. You can also apply your traffic
policies to the inbound traffic, but keep in mind that there is an order
of operations that Cisco IOS uses when dealing with the processing of
inbound vs. outbound QoS. For your situation, I'd concern myself with
outbound traffic. Again, you'll not really have much control on what
your provider hands back to you...the Internet is best-effort only. ;-)

Here's a template for you to start with:

class-map match-any Outbound-Voice
match protocol rtp
class-map match-any Default

policy-map SDM-Pol-Serial0/0
  class Outbound-Voice
  priority percent 70
  set dscp ef

interface serial0/0
  service-policy output SDM-Pol-Serial0/0

You can add more classes and modify the policy map as appropriate. As an
aside note, I utilize similar QoS tools in my network. I have a couple
of sites that are driving some of the WAN circuits into the ground. My
server group sometimes likes to fire off backups in the middle of the
day. I will see average utilizations of 99 percent for hours at a time.
In fact, with a display threshold of 90% at the 95th percentile (top 5
percent of traffic spikes per sample are removed), I see averages at 98%
for the sample period! The point is, these circuits are severely abused.
To add to the challenge, we hand off a fair amount of voice traffic to
these sites, as they also provide T1 PRI gateway services. Guess what?
The Cisco IOS provides solid performance with such abuse. I see lots of
discards on non-voice traffic, but voice gets just what it needs. We
utilize the SAA features in IOS, and we see jitter stats that vary by
only a few milliseconds and consistent MOS scores of over 4.5 for voice
quality. In past work environments I've worked with ATM networks. It's
surprising to see how well QoS tools perform relative to protocols like
ATM that are designed from the ground up to deal with converged traffic!

Good luck with your lab!

-Cisco guy from Fort Wayne, Indiana

William Zumwalt wrote:
Quoted text here. Click to load it

Site Timeline