Well, in this case my upstream is half of the 768. Normally QOS kicks in and everything hums along beautifully, but if I run a VNC session throught the circuit there's a LOT of break up. I'm not running out of bandwidth (not even close) but I imagine the voice packets are having to wait behind the all the packets generated by the VNC session. Doesn't that sound like something that a reduction in MTU would fix?

-Shikamaru

Hi,

Can you get an ADSL card for your router, or get an ADSL router like the 877 ?

This will let you apply QoS for the upstream direction directly to the point of congestion

If you can't do that, you would need to shape the ethernet output to 768 or less, and within that, apply the QoS setting. This is kind of complicated and not very effective so I would recommend the first solution.

Hope this helps, please rate post if it does!

Well, I'm already applying the QOS statement directly on the router port that's connected to the DSL handoff, so I don't believe an ADSL card will make any difference in this instance. In fact, QOS seems to work very well except in some particular circumstances when graphical data is being streamed across the circuit. I still suspect that the issue involves serialization.

-Shikamaru

Yes it makes a big difference. Unless you have configured shaping and priority, the ethernet interface is never congested hence no QoS can be applied. You would see that doing show policy interface. An ADSL interface instead, would present to point of congestion to the router directly.

When QoS really works, there are no drops in voice quality no matter the amount of data you throw at the circuit.

I don't believe that's true (although I may be misinterpreting the output). If you like, I can post output of "show interface policy-map interface ethernet" of a VoIP call going through the gateway's ethernet port. Packets do get prioritized before congestion occurs.

QOS is not magic. It doesn't solve all issues that occur as a consequence of insufficient bandwidth. Just because I'm using LLQ to prioritize VoIP packets doesn't mean that voice quality will be good if there are serialization issues (such as a situation where bonded T1 is the WAN connection to other sites.) In cases where large data packets are being processed even if QOS is prioritizing, voice packets can still be stuck behind data packets in the process of being passed. Policing doesn't solve everything, that's why there is shaping and serialization techniques.

Like I said, the QOS statement does work, there is a night-and-day difference when it's in place. I would love for anyone to show me the light if I'm wrong about this, by the way.

-Shikamaru

Hi,

first of all, with the due modesty, please understand that you talking to someone that was at cisco the very time the initial QoS was introduced, has been exposed to the evolution and training of it for 10 years, and in summary has enough understanding of the matter to be more than happy about it.

This said, I know for experience that serialization delay is rarely a problem.

What is a problem instead, are cheap adsl modems without QoS, and configurations that are inherently little efficient, like LLQ applied to shaped ethernet.

Now, if you want to post your QoS configuration and "show interface policy-map interface ethernet" so we can discuss on facts.

p.,

Here is the output I mentioned;

********************************************

#show policy-map interface ethernet 0/0

Ethernet0/0

Service-policy output: VOIPQOS

Class-map: Voice-RTP (match-all)

737144 packets, 119019682 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 102

Queueing

Strict Priority

Output Queue: Conversation 264

Bandwidth 1136 (kbps) Burst 28400 (Bytes)

(pkts matched/bytes matched) 46565/3371249

(total drops/bytes drops) 0/0

Class-map: Voice-Control (match-all)

263 packets, 26571 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group 103

Queueing

Output Queue: Conversation 265

Bandwidth 16 (kbps) Max Threshold 64 (packets)

(pkts matched/bytes matched) 174/16745

(depth/total drops/no-buffer drops) 0/0/0

Class-map: class-default (match-any)

1434133 packets, 138634520 bytes

5 minute offered rate 2000 bps, drop rate 0 bps

Match: any

Queueing

Flow Based Fair Queueing

Maximum Number of Hashed Queues 256

(total queued/total drops/no-buffer drops) 0/0/0

********************************************

This was taken during a recent call when there was no congestion.

Here are the QOS statements and ACLs;

********************************************

class-map match-all Voice-RTP

match access-group 102

class-map match-all Voice-Control

match access-group 103

!

!

policy-map VOIPQOS

class Voice-RTP

priority 1136

class Voice-Control

bandwidth 16

class class-default

fair-queue

Extended IP access list 102

10 permit ip any any precedence critical (673516 matches)

20 permit ip any any dscp ef

30 permit udp any any range 16384 32776 (651903 matches)

Extended IP access list 103

10 permit tcp any any range 2000 2002 (201 matches)

20 permit tcp any any eq 2428 (20062 matches)

30 permit udp any any eq 2427 (20343 matches)

40 permit tcp any any eq 1720 (103 matches)

********************************************

Are there any other tests I can run that will help me understand the drop in call quality. As I mentioned previously, the WAN speed is 1.5/384. From the VoIP phone, the upstream call quality (in the 384 space) suffers a bit when packets are fighting for space, but like I mentioned it is not anywhere near as bad as when I remove the statements. Also, the gateway is a 2610.

-Shikamaru

hello, as i was saying previously this doesn't quite work because there is no real congestion on ethernet interface, now I understand this is router that is connected to ADSL modem with upload speed of 384, in this case priority should be like 80 kbps (for a single call), and the default class shaped average 384. See for example:

An ADSL interface in the router would remove the need for shaping and remove the need to approximate said shaping speed. That is the way professional intallations are made.

http://cisco.com/en/US/tech/tk543/tk545/technologies_tech_note09186a0080114326.shtml

Hope this helps, please rate post if it does!

p.,

Thank you for the feedback. I will look into getting an ADSL card for the gateway and go from there.

-Shikamaru

Thanks, p., I will give it a shot. Like I mentioned, the break up that's happening is minute, I'm sure that some tweaking will fix the issue. Also, yeah, in a way it's kind of not optimal to handle the adsl copper hand off directly to the gateway from an ethernet port if I can get a dedicated adsl card for it. I'm pretty sure that the answer is here.

-Shikamaru

The objective is 'pin drop' quality on every call. (I think you've heard this before :)

Thank you for the nice rating and good luck!