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

[Ziv Leyes]

Hi Christopher,
Excuse my ignorance, but I'm not sure I understand what you mean by " If you are running a borrow enabled IOS" What's a borrow IOS?
The routers are both running c7200-spservicesk9-mz.124-11.T1.bin, one is a 7204VXR NPE300 and the other 7206VXR NPE300.
I'll try your suggestion and I'll let you know if it helped.
Thanks,

Ziv

-----Original Message-----
From: Christopher E. Brown [mailto:chris.brown at acsalaska.net]
Sent: Thursday, February 07, 2008 5:01 AM
To: Ziv Leyes
Cc: [c-nsp]
Subject: Re: [c-nsp] Question about ip rtp header-compression

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
------------------------------------------------------------------------





************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************





 
 
************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
************************************************************************************