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

Mon Aug 11 17:15:39 EDT 2003

For ATAs 186 on UDP ToS field put 0xA0 (after applying it will become
0x000000a0)
HEX A0 = BIN 1010000 -> Precedence/CS 5

For the Asterisk SS (I never used) it seems to be same as ATA (hex).

Luciano

-----Mensaje original-----
De: Eric Wieling [mailto:eric at fnords.org]
Enviado el: Lunes, 11 de Agosto de 2003 03:54 p.m.
Para: Luciano Salata
CC: Voll, Scott; cisco-nsp at puck.nether.net
Asunto: RE: [nsp] QoS issues with LLQ, Fair Queue and Frame Relay

Not all of our VoIP stuff is Cisco.  I do have a question, however with
regards to the Cisco ATA-186.  The default TOS for my ATA-186 is
0x000068b8.  The precedence/dscp can be a max value of 63.  The TOS in
the ATA196 is a lot higher than 63.  I'm confused by this.  Do you have
any info that might help clarify this?  My other VoIP device (Asterisk
SoftSwitch PBX) uses 0x10 for the lowdelay TOS.

On Mon, 2003-08-11 at 13:46, Luciano Salata wrote:
> 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/
--
BTEL Consulting
850-484-4535 x2111 (Office)
504-595-3916 x2111 (Experimental)
877-552-0838 (Backup Phone)