[nsp] QoS issues with LLQ, Fair Queue and Frame Relay

[Luciano Salata]

Eric,

If you are using voice gateways like Cisco ATAs or any other capable, you
can send the voice traffic already marked by the GW and then just classify
by looking the ToS field (precedence/dscp). This way, you will decrease the
classification complexity at the router, and probably decrease the cpu
"utilization".

On the other hand, using g.729 doesn't mean in a link utilization of 8kbps
per call. Without using header compression and/or tweeking the payload size,
one g729 call may use ~25kbps.

HTH

Luciano

-----Mensaje original-----
De: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]En nombre de Eric Wieling
Enviado el: Lunes, 11 de Agosto de 2003 02:08 p.m.
Para: Voll, Scott; cisco-nsp at puck.nether.net
Asunto: RE: [nsp] QoS issues with LLQ, Fair Queue and Frame Relay


As I understand it the ATA-186 in SIP mode uses UDP port 5060 for
control messages.  The voice-access-list should match that.


On Mon, 2003-08-11 at 11:54, Voll, Scott wrote:
> Are you dedicating bandwidth to the control protocol?  I'm doing
> everything with ip precendence and dscp bits so I'm not sure which ports
> you need to add if they are not all ready in your ACL?!?  I would also
> try the header compression.  That takes the header from 40 bits to 2.
>
> Scott
>
> -----Original Message-----
> From: Eric Wieling [mailto:eric at fnords.org]
> Sent: Monday, August 11, 2003 9:48 AM
> To: Voll, Scott
> Subject: RE: [nsp] QoS issues with LLQ, Fair Queue and Frame Relay
>
> We are trying to do two G729 streams.  HOWEVER, I'm seeing high latency
> for packets that match voice-access-list even when there is NO voice
> traffic (just an ATA-186 registering to my SIP server).
>
> On Mon, 2003-08-11 at 11:43, Voll, Scott wrote:
> > How many calls are you trying to make and what codec?  You are only
> > prioritizing 64k.  You need to add up how many calls and how much
> > bandwidth per call and make that your priority **** not just 64.  64
> > will take care of one G711 call. Or maybe 3 calls at like G729/ G723
> > etc.
> >
> > You might also look at "frame-relay ip tcp header-compression" or
> > "frame-relay ip rtp header-compression" to help get you some more
> > bandwidth.
> >
> > Hope that helps
> >
> > Scott
> >
> > -----Original Message----- From: Eric Wieling [mailto:eric at fnords.org]
>
> >
> > I'm having trouble with getting QoS working.  I looked at
> >
> http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_e
> > xample09186a0080094af9.shtml and decided to go withLLQ rather than IP
> > RTP Priority because we will eventually want to prioritize traffic in
> > addition to RTP traffic.  What I'm seeing is that the RTP traffic is
> NOT
> > being prioritized over other traffic.  I'm also seeing what looks like
> > random problems with TCP connections (users are complaining about not
> > being able to connect to our mail server, etc.
> >
> > We have a Frame Relay network in a hub and spoke configuration.  QoS
> was
> > configured at each of the offices.
> >
> > I've pasted part of our config in hopes that someone out there can see
> > what I might be doing wrong.  ANY help or pointers to additional
> > information would be helpful.
> >
> > System image file is "flash:c2600-ik9o3s3-mz.122-15.T5.bin"
> >
> > ip cef
> >
> > class-map match-all voice-class-map
> >  match access-group name voice-access-list
> >
> > policy-map traffic-policy-map
> >  class voice-class-map
> >   priority 64
> >  class class-default
> >   fair-queue
> >
> > interface Serial0/1
> >  description Connected to BellSouth
> >  bandwidth 768
> >  no ip address
> >  encapsulation frame-relay
> >  no fair-queue
> >  frame-relay traffic-shaping
> >  frame-relay lmi-type ansi
> >
> > interface Serial0/1.1 point-to-point
> >  description morrison
> >  bandwidth 384
> >  ip address 172.16.0.41 255.255.255.252
> >  frame-relay interface-dlci 201
> >   class traffic-map-class
> >
> > ip access-list extended voice-access-list
> >  permit udp any any range 16384 37276
> >  permit udp any eq 5036 any
> >  permit udp any any eq 5036
> >  permit udp any eq 5060 any
> >  permit udp any any eq 5060
> >
> > map-class frame-relay traffic-map-class
> >  frame-relay cir 384000
> >  frame-relay bc 3840
> >  frame-relay be 0
> >  frame-relay mincir 384000
> >  service-policy output traffic-policy-map
> >  frame-relay fragment 480
--
BTEL Consulting
850-484-4535 x2111 (Office)
504-595-3916 x2111 (Experimental)
877-552-0838 (Backup Phone)

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/