From: David Duncon (david_ccie@hotmail.com)
Date: Sat Oct 02 2004 - 09:14:03 GMT-3
Thanks for your input , Alexei.
Yes , I am using G729 codec across WAN. I am of the opinion that even though
queue-limit 4 (at the moment it is set 1 ) will make 4 packets to stand in
the queue before they get serialized, it may still help our heavy signaling
drops. Because as you can appreciate unlike RTP streams , RTCP can survive
bit of latency and the she is happy as long as packets get to the other side
of the VC.
Based on that logic , I am moving ahead with my CCR (internal change
control) and in the next 72 hours I will make necessary change at HUB
end/7507. If it does not stabilize our call centre operations ,then I may
consider enhancing the signaling class-map's allocated bandwidth from 8k to
may be 15k.
If it still does not help, then may be I will start looking in to CM side of
the things , even though I am reasonably sure that Application layer is
working fine.
Will let you know how am going with this case after few days.
Thanks again for your input :-)
David.
>From: "asadovnikov" <asadovnikov@comcast.net>
>To: "'David Duncon'" <david_ccie@hotmail.com>,<ccielab@groupstudy.com>
>Subject: RE: Queue-limit xx with in LLQ
>Date: Thu, 30 Sep 2004 23:16:27 -0400
>
>David,
>
>You can not decrease latency by increasing queue size. The queuing latency
>is exactly that how long the packet sit in the queue, by increasing queue
>length you are increasing possible maximum (and in your conditions probably
>the average latency), on the other side of the token it would lead to less
>drops within the class. On the surface 8K for signaling appears
>sufficient,
>but obviously it does not work well for you. Did you look into what
>actually is matched to ensure that some other traffic is not getting
>classified as signaling. BTW how many same time calls do you support /
>which codec?
>
>To cut long story short, make sure matching is right, and then increase
>bandwidth if not sufficient.
>
>Best Regards,
>Alexei
>
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>David Duncon
>Sent: Thursday, September 30, 2004 8:40 AM
>To: ccielab@groupstudy.com
>Subject: Queue-limit xx with in LLQ
>
>Hello Group,
>
>I got a real world situation where I am running LLQ between HUB and Spoke
>to
>
>protect voice on a 192k PVC. In the recent past I have been noticing large
>%
>
>of signaling drops. Even though allocated 8k for 12 x 7960s should be fine
>,
>
>I am considering to increase the signaling band width to may be 15k. But
>before I do that , I just want to try our *queue-limit* command under
>class-map of Signaling in order to reduce the current latency existing on
>Signaling queue.
>
>I do understand that in the absence of RED or WRED , this queue-limit value
>will define the *number of packets* queued for a given traffic class.
>
>So my Qs are , 1) what is the default queue-limit value for Signaling
>traffic in general 2) what queue-limit value can I set for Signaling
>traffic
>
>in order to reduce the current latency 3) Is this queue-limit value should
>be different for RTP (even though there is NO latency for RTP packets now /
>i.e I have No drops on this queue)and RTCP/Signalling in the following
>config. If yes , why they should be different.
>
>Policy-map VOIP-192
>Class voip-rtp
>Priority 100
>Class voip-signaling
>Bandwidth 8
>Queue-limit ?? ----------------------------> would like to set statically
>configure this value before I increase the allocated B/w for signaling, but
>not sure how much should I go for?
>
>
>I really appreciate any timely feed back :-)
>
>Thanks in advance
>
>David.
>
>_________________________________________________________________
>FREE* Month of Movies with FOXTEL Digital:
>http://adsfac.net/link.asp?cc=FXT002.7542.0
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
>
This archive was generated by hypermail 2.1.4 : Sat Nov 06 2004 - 17:11:42 GMT-3