Re: FRTS with MQC

Victor,
Thanks for the good tips. question under discussion is why solution used LLQ
instead of RTP Priority.

I thought, with LLQ, traffic matched for LLQ will always leave first
whereas, with rtp prority, it will not become active untill congestion has
occured Therefore, voice will not always leave first.

Please correct if wrong.

On Sun, Jun 14, 2009 at 7:03 AM, Victor Cappuccio <vcappuccio_at_gmail.com>wrote:

> Hi,
>
> with LLQ the entrance criteria to a class can be as granular as you like
> because you define it by an ACL. You are not limited, as with IP RTP
> priority, to a simple UDP port range. If the port range feature did not get
> changed, it is probable that every future voice application would take
> advantage of it.
>
> Some voice QOS Design Considerations Notes:
>
> General Considerations
>
> - Do not use VoIP on a FR PVC that also carries VoFR
> - Prioritize the PVC if it carries only voice traffic
> - Don't mark voice packets as DE
> - Set IP Precedence = 5 on the dial peer
> - Don't use WRED for voice queues
> - Turn on DTMF-relay for low bit-rate codecs (8k and below)
> - Set echo, loss/gain parameters as specified by the network loss plan.
> - Measure/calculate network packet delay - the goal is 150 to 200ms
> one-way.
> - If TCP delays affect DTMF-relay performance use Cisco-rtp for
> DTMF-relay
>
> Queuing Considerations
>
> - LLQ - classify voice in a priority class
> - Use ip rtp priority if LLQ is not available
> - Set the bandwidth on the priority statement in the LLQ configuration
> (or in the ip rtp priority statement) to the aggregate number of calls
> per
> interface/PVC
> - Create ACLs that prioritize both voice media and signaling
>
> Fragmentation Considerations (speeds less than 1.5Mbps
>
> - Fragment to a 10ms delay to optimize size for backbone packet/cell
> sizes and network delay characteristics
> - Set fragments size so that voice packets are not fragmented
> - Set the ppp multilink fragment-delay command on leased line interfaces
> - Set the frame-relay fragment command in the FR map class
> - Fragment all PVCs carrying data on the interface if at least one PVC
> carries voice
>
> Traffic Shaping Considerations
>
> - Set Be to 0
> - Set Bc to 10ms (1/100 of CIR) for mixed voice/data PVCs
> - Set mincir greater than or equal to bandwidth needed for voice
> - Set FRTS on the interface
> - Shape traffic strictly to the CIR on the PVC carrying voice
> - Shape both sides of the VC to the slower link speed to prevent egress
> blocking
>
> CAC Considerations
>
> - Limit voice calls to prevent oversubscription of the bandwidth
>
> *Video QoS Design Considerations*
>
> - For bidirectional and/or low speed video use priority queuing and
> allocate 384Kbps for bandwidth
> - For one-way video traffic use a CBWFQ mechanism
>
> LLQ Considerations
>
> - Large video MTUs placed in the LLQ's priority queue with voice traffic
> will bypass the fragmentation engine and cause delays for the voice
> traffic.
>
> CAC Considerations
>
> - In a single-zone WAN model limit the number of video terminals
> - In a multizone WAN model use Gatekeeper CAC. However, Gatekeeper CAC
> is only available in a hub-and-spoke network.
>
>
> On Fri, Jun 12, 2009 at 10:25 PM, mohmmad imran <imran_mohmmad_at_yahoo.com
> >wrote:
>
> > Hi Experts,
> >
> > I am kinda confused when to use MQC LLQ in FRTS or to use IP RTP priority
> > for
> > VOICE Traffic prioritization.
> >
> > Task 1:-
> >
> > configure the FRTS on the router Frame-relay link with 256Kbps CIR, TC
> 10ms
> > and to decrease the serialization delay on the circuit a single packet
> > cannot
> > take more than one interval to be transmitted
> >
> > Answer: -
> >
> > map-class frame-relay
> > frame-relay cir 256000
> > frame-relay bc 2560
> > frame-relay fragment 320
> >
> > Task 2:-
> > now says that configure your router so that 200Kbps of VOIP traffic is
> > always
> > de-queue first when it is sent over this frame-relay link.
> >
> > Answer: -
> > As per my understanding I would do this with the frame-relay ip rtp
> > priority
> > like
> >
> > map-class frame-relay
> > frame-relay cir 256000
> > frame-relay bc 2560
> > frame-relay fragment 320
> > frame-relay ip rtp priority 16384 16383 200
> >
> > but in solution it uses the MQC LLQ and then called that service policy
> in
> > class-map.
> >
> > Can anyone please explain when to use IP RTP priority and when to use MQC
> > LLQ
> > with FRTS?
> >
> > ---Imran
> >
> >
> > Blogs and organic groups at http://www.ccie.net
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> --
> Victor Cappuccio
> CCIE R/S# 20657
> CCSI# 30452
> www.anetworkerblog.com
> www.linkedin.com/in/vcappuccio
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Jun 14 2009 - 11:23:39 ART