Re: implementing qos help
- From: fugettaboutit <no@xxxxxxx>
- Date: Tue, 10 Jul 2007 12:53:19 GMT
Hello,
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:
I wanted to learn how to implement QoS so I was going to implement both an IntServ and DiffServ model to learn about them 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, another question is, 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 then?
- Follow-Ups:
- Re: implementing qos help
- From: Arthur Brain
- Re: implementing qos help
- References:
- implementing qos help
- From: William Zumwalt
- implementing qos help
- Prev by Date: Re: setting up address translation rule in PDM
- Next by Date: Re: 5505 - IPS/IDS
- Previous by thread: implementing qos help
- Next by thread: Re: implementing qos help
- Index(es):
Relevant Pages
|
