[c-nsp] VoIP QoS Service Policy Template

[Andre Beck]

On Fri, Dec 17, 2004 at 10:18:42AM -0800, Andrew Melton wrote:
> Does anyone have a good policy-map for marking and queueing traffic
> already marked with a DSCP?

Not yet, I'm still researching that new world for myself ;)
 
> In other words, I am marking VoIP traffic at the edges based on UDP
> port ranges.  That traffic is then marked on the outgoing interface
> with a DSCP value of 101110.

Sounds reasonable. I'm currently just using precedence, but that's
a detail (precedence is the upper three bits of the DSCP anyway).
 
> So, all core routers should accept that traffic, remark it with the
> same DSCP and queue it appropriately on the outgoing interface.

Yep, or just leave the DSCP alone once it passed your edge, just
using it to decide how to queue the packets.

> I'm not sure whether the best way to do this is with a policy-map
> using a 'priority bandwidth' statement for that class which matches on
> the DSCP.  I'd have to have separate statements and policy-maps for
> each interface of differing speeds using this method.

Depends on whether you want it that scalable. If you can live with
a more generic, auto-fitting method of just saying "reserve me n%
of the interface bandwidth for that priority traffic", you can use
the "priority percent" statement instead. Like for instance in:


class-map match-all precedence-higher
 match  precedence 2  3  4  5 
class-map match-all precedence-control
 match  precedence 6  7 

policy-map voice-precedence
 class precedence-control
  priority percent 5
 class precedence-higher
  priority percent 10


Then again, what you normally want is indeed to reserve a certain amount
of bandwidth, not a certain percentage of the interface bandwidth, as
the bandwidth required for voice isn't coupled to the interface band-
width but is either fixed (say, 2Mbps for easily fitting 20 G.711 calls)
regardless of medium, or is dependend on the actual voice usage of the
link times the bandwidth used by the codec in question, making it
per-interface individual anyway. I used percentage because I only
had a bunch of E3 and always wanted the same amount of bandwidth
reserved on them.
 
> Any other suggestions on how to apply a queueing policy to this EF
> traffic?  I know that there are a million ways to do it, I'm trying to
> find what has worked well for people and what hasn't.

The above worked quite well in a load test with 7960 running Skinny
connections over E3 while beeing beaten over the head with data by
means of hping3 UDP floods. Of course it is a completely different
questions how you establish Precedence/DiffServ authenticity at your
SP edge. Matching port numbers is something to start with, NBAR protocol
discovery, RTP detection etc might help further. I had the luck to just
rely on 3550 "mls qos trust device cisco-phone" but that is an enterprise
WAN, no SP cloud with its special situation of dedicated distrust.

-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-