[c-nsp] Question about ip rtp header-compression

Christopher E. Brown chris.brown at acsalaska.net
Wed Feb 6 22:00:44 EST 2008


Ziv Leyes wrote:
> The problem is I'm not using NONE of the possible queuing strategies at all right now! So why the line can't just use the whole 2Mb for RTP?
> My question wasn't about if you want to dedicate a specific bandwidth with some QoS policy then you'll be obviously limited to 75% or 80% of the total bandwidth, because the router needs to save some bandwidth for the rest. I'm talking about if there's a limitation on the bandwidth utilization that the ip rtp header-compression can use, even before implementing any queuing strategy or policy.
> 
> 
> Ziv


By default 25% is reserved for the default queue.

Use "max-reserved-bandwidth 100" in the interface config to change this.

Based on your description of a VOIP only link my first take would be 
something like

class-map match-any VOICE
   match ip dscp ef
   match ip dscp af31
or
   match ip precedence 5
   match ip precedence 3
!
!
policy-map SAT_LNK
  description BLAH
   class VOICE
    priority percent 90
   class class-default
    bandwidth percent 10
   random-detect dscp-based
!
!
interface <something>
  max-reserved-bandwidth 100
  ip tcp header-compression iphc-format
  ip rtp header-compression iphc-format
  ip rtp compression-connections 1000
service-policy output SAT_LNK
!


Note, older IOS on the 7200, priority queue size is absolute, no 
borrowing, later IOS (12.3, maybe even 12.2?) allow the priority to 
borrow, but any overage gets *no* special queueing (best effort, no 
fixed timeslot for latency/jitter protection).  If you are running a 
borrow enabled IOS, I would expect that the priority band traffic is 
running over the 75% mark and that excess is being queued without 
protection (our of order and jitter expected), otherwise anything over 
75% would be dropped.

The above would put commonly market RTP + call control in a 90% priority 
queue with fixed timeslots, all else including any traffic (including 
OSPF/etc) falls into the default.  IIRC OSPF and BGP still get some 
special treatment within the default queue.


Personally I maintain separate

VOICE
SIGNALING
NETWORK_SIGNALING
DEFAULT
SCAVENGER

classes with OSPF/BGP living in NETWORK_SIGNALING, VOICE never higher 
that 70% even on a VOIP primary/only link (normally 10 - 30 percent on 
general purpose transport) with the SCAVENGER class always being 1%. 
(SIGNALING is actually VOIP call control + preferred data).


-- 
------------------------------------------------------------------------
Christopher E. Brown   <chris.brown at acsalaska.net>   desk (907) 550-8393
                                                      cell (907) 632-8492
IP Engineer - ACS
------------------------------------------------------------------------


More information about the cisco-nsp mailing list