[cisco-voip] Strict Priority Queuing over T1 for Voice

[Andre Beck]

Hi,

On Tue, Oct 24, 2006 at 04:43:15PM -0500, Keith Klevenski wrote:
> 
> I've been battling a problem that seemed to have surfaced recently as we
> have added more users to the office.  We have an office of about 35
> users now with a point to point T1 (HDLC) between this office and the

Running PPP instead of Cisco-HDLC would allow you to use MP and LFI with
the advantage of further reducing the serialization delay, but given that
it's a T1, that isn't really of the utmost priority - worst case jitter
introduced by SD on a T1 is approximately 8ms.

> We have strict priority queuing configured on the T1 interfaces (and the
> FastEthernet interfaces although I don't think this is necessary) with

Depends. FEs are usually FIFO as they are significantly faster than 2Mbps.
If you can generate traffic on the routers that could actually cause
congestion, you preferably QoS the router's FEs, too. A way to congest
them would e.g. be single-armed routing either on o stick (VLANs) or even
due to a default gateway setting that bounces off to another local router
in an environment where ICMP redirects don't work. If it's not an actual
DoS attack.

> DSCP EF traffic in the high queue and signaling (AF31/21/22/23 and CS3)
> the medium queue and other traffic in the normal and low queues.  

Sounds like you're using classic/legacy PQ? Hopefully this isn't old
code that started to deteriorate. I'd prefer MQC in such cases, though
I've seen PQ work perfectly. You just might have to tune queue sizes.

> The problem is when the T1 is saturated we start seeing high jitter (1-2
> seconds) and rxlost packets on the phones and voice quality of course
> suffers.  The thing is I see NO dropped packets on any interface from
> the PSTN to the switch port the phone is connected to other than the
> call statistics on the phone.  This confuses me greatly unless the phone
> itself is dropping them...

Could mean they were defective, but that should have triggered one of
the L2 checksums that were in intermediate use (Ethernet, HDLC).

> it would seem that if the phone determines
> there are missing packets (rxlost) they would show up on some interface
> somewhere but they do not.  Sniffer traces at the phone show the missing
> packets.  Sniffer traces at the trunk at the remote office show missing
> packets, but traces on the trunk in the datacenter (from the 7200 to
> 6509) show all packets accounted for.  Seems like the T1 is the issue.
> There are 24 line code violations on the T1 in the last 24 hours, but no
> slips.  The problem only seems to occur when there is high traffic on
> the T1.

This is indeed rather strange.

>  We also noticed no other traffic is marked EF and the RTP
> stream is EF at the datacenter and at the office so that isn't being
> remarked or anything.  But there are no input queue drops on the 2811
> (which I wouldn't expect since the RTP stream should be CEF switched
> anyway).  If the input interface cannot handle the amount of traffic and
> the traffic is all CEF switched where would you see input drops?  There
> are a handful of buffer failures, but nothing that would account for the
> number of complaints I've been getting lately.

Is the router by chance experiencing high CPU load, especially interrupts?
Are you perfectly sure all switching is CEF? Try "show cef int brief".

> I've connected my phone directly to the 2811 and bypassed the 3750 with
> the same results.
> 
> I also noticed that the rxsize fluctuates between 10ms and 20ms also.
> Shouldn't that always be 20ms?  I thought that was odd.

Dont know about the 6608.

> I guess my main question is when using strict priority queuing shouldn't
> the voice packets ALWAYS get sent first no matter what??  I want to
> believe they are since there are NO drops in the high priority queue
> outbound from the datacenter.

That's the most interesting point here. If there are no drops here
(either in PQ interface stats or "sh policy-map interface" for MQC)
on the relevant queue/class, the packets should be there. Sometimes
there are odd issues, though - I have one where the remote offices are
connected through GRE tunnels established through an IPsec VPN, and I
have a cyclic phase of approx. 0.5s where I lose all packets which
repeats every approx. 253s. Not tracked to a rational cause, yet - and
no, it's not SA renegotiation, the loss is only *within* the GRE, not
in other flows through the VPN...

> What is the best way to do QoS for voice
> over a T1 when you only care about the voice?  Seems like strict
> priority queuing is the best way to assure voice traffic is sent first.

It should work. I'd prefer MQC and having the priority class cupped at
the top at around 80% of the real line rate, but as long as starvation
is really no matter, PQ should do as well.

> We don't really care about starving out any other traffic.

I'd prefer at least the management traffic still works. But I assume
that 1) line keepalive is highest priority already and 2) if it would
be a problem from this area, you'd have seen it in the logs already.

> If packets are being dropped shouldn't I see them somewhere other
> than on the phone?

I'd think so. Either in a output queue or in an incoming error counter.
On any router or switch in the path. But it sounds like you already
investigated all of them. What's strange is the coupling of the problem
to high load on the T1. And the fact you don't just see RX losses, but
also jitter in the full seconds timerange. This must mean something is
queued and/or delayed somewhere. Any idea what's generating this load?

Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-