QoS and available Bandwidth

...

Under 'interface Dialer 1', you need to stick in (say) bandwidth 400

It's only a guestimate since you don't know what your line will always sync at. But most UK ADSL lines sync at 448 kbps upstream, then you have some overhead (and maybe BT's BRAS rate limit applies on downlink too, I don't know). So 400 might be about right. "Premium" UK ADSL lines sync at 768k upstream, and give maybe 650 kbps throughout.

Of course it's the uplink speed that's relevant here. From your router you can't do anything about the downlink. Some ISPs have VOIP-friendly downlink controls, e.g. AAISP.net in the UK offers an optional "95%" control panel setting that only allows small UDP packets through once the downlink is 95% full - ideal for protecting VOIP on a busy link.

If you do "show int atm 0/0/0" (or whatever it is on your router) you'll get to see the uplink and downlink sync speeds.

I don't understand the 42 kpbs comment. The "priority 240" 240 kbps reservation doesn't cost you anything when you're not using it. Unless you line is syncing slowly maybe

Hope this helps

- Martin

Thanks. I ended up with 2 statements.

bandwidth 700 bandwidth receive 6190

Seems it doesn't accept it in one line.

I remember reading about bandwidth, and noting that it was just some "information" that didnt control actual throughput. But rereading it again and implementing it does seem to affect the QoS system.

This is a 7mbps 800kbps ADSL link. I removed the ethernet, PPPoE and ATM overhead to get those numbers.

This router does not have a buiolt in ADSL modem, only a 100mbps ethernet port to the modem, so it has no way of knowing what throughput the link is capable of.

What is not clear to me is what the bandwidth includes. The above numbers assumes it includes only the IP header and its payload.

The router can't know about the ATM overhead. But it would know about ethernet, PPPoE overheads. (but ATM represents the greatest overhead).

Now, I get: router1#show queueing int dialer 1

Interface Dialer1 queueing strategy: fair Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 527 kilobits/sec

Out of curiosity, wouldn't QoS on the receive side also work ? If you stop the flow at the end of the pipe instead of at the start of it, wouldn't senders of non priorioty packets detect packets dropped (by my router) and slow down ?

I guess I'd use a site like Speedtest.net to try to get a feel for whether the line is really capable of the speeds you expect. Or indeed whether the upstream ISP side is a bottleneck.

I don't pretend to understand the details of the queue statistics. But I'm told it's worth making sure your Dialer0 section has something like:-

tx-ring-limit 3 tx-queue-limit 3

My understanding is that once a packet is in the TX queue, it's no longer subject to prioritization rules. So by limiting the size of the TX queue, you make the QoS stuff more effective - otherwise a quick burst of non-VOIP traffic could get into the TX queue and thus hog the uplink for long enough to cause an audible click in the VOIP uplink traffic. This does mean that if you have lots of intense TCP uploads going on, some of those TCP packets will be dropped - but TCP is designed to self-tune to things like that, and in practice I've not seen any problems with a TX queue size of 3.

Well, it's not ideal, since the packets have already been down the pipe by that stage. For preference you'd like your bandwidth reservation / traffic prioritization setup to limit which packets go down the pipe. On the plus side however, the downlink side of ADSL is so much faster that it's harder to saturate the downlink than the uplink.

If you don't have any QoS options on the ISP end, then I wonder if you can achieve something with a second policy-map for the downlink side, applied to the Dialer0 interface with:

service-policy input voip-QoS-downlink

If you set up such a policy to prioritize VOIP in that direction, then by dropping random packets from non-VOIP traffic, perhaps the router might be able to cause TCP sessions to slow down a bit. It would be better if the router could actually signal the sender to slow down, but I don't think that's possible (neither source quench or ECN actually work like that on modern routers IIRC).

Perhaps a more knowledgeable expert could help us out here, and comment on the extent (if any) to which it's possible to shape your ADSL downlink traffic in order to protect your VOIP traffic.

Good luck!

- Martin

Meanwhile, at the comp.dcom.sys.cisco Job Justification Hearings, JF Mezei chose the tried and tested strategy of:

Even if it was built in, with a best-effort service like DSL the router doesn't know what bandwidth it has available either. All you can do is test it and plug in some numbers.

But with :

policy-map voip-QoS class class-voip priority 240 class class-default fair-queue

Shouldn't any voip traffic get priority over "class-default" for the first 240kbps of traffic no matter whether the line is 300kbps or 10gbps ?

Also, if I have "bandwidth 600" in the interface,

why does:

router1#show queue dialer 1 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: Class-based queueing Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/0/256 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 210 kilobits/sec

Show 210kbps available ?

I could understand 600, or 600-240=360 or 240. But 210 ?

Another question:

OK, so I want voip to have priority of at least 240kbps. Rest is fair queue in the above.

Is it possible to create a web-class (my web server's outbount traffic) which would not have any bandwidth garantee, but would have priority in the queue against the rest of the traffic ?

I like the cut of your jib. So traffic outbound from port 80/tcp would take precedence over (say) P2P or FTP / SCP uploads.

The golden rule with "bandwidth" statements is high enough to be realistic, but at or lower than the real useful data rate.

If you have say "priority" for your VoIP traffic and other stuff in a WRED queue, then the WRED queue will naturally use everything available - spare bandwidth allocated to priority or stuff you never allocated or whatever.

The Tx ring is the last buffer for packets waiting to go out on the wire.

The router doesnt drop from the Tx buffer unless something goes badly wrong (like the line going down) - it is just a holding area to feed bits to the hardware.

The assumption is that "significant buffering" is done in the QoS queues, and the Tx ring just trades some jitter for line use efficiency.

QoS is about controlled unfairness for different sets of traffic.

because QoS works by controlling what goes into a queue and what order things come out, it only has a big effect at a choke point in the traffic flow (although since you often dont know where that is, ideally QoS should be at each point through the network where congestion might build up)

For a traditional user the inbound traffic dominates the flow, and the ADSL line on a broadband link is the biggest choke point. So the most effective way to control you inbound traffic is at the ISP DSLAM connection.

There are devices that can handle inbound QoS in this kind of setup - but they manipulate the TCP window and other high level aspects of TCP to control upstream.

WRED will have the effect of making flows "back off" in TCP.

2 issues. 1 - WRED doesnt have any effect on UDP, so if your line is heavily used for something like iplayer it isnt going to do much good (at least not directly) 2 - you are assuming there is good correlation between outgoing TCP flows and incoming - unfortunately a well tuned TCP stack will see a big difference in useful data flow vs reverse direciton control traffic.

a link to a Cisco doc about QoS good practice:

I need a sanity check...

The dialer 1 has a "bandwidth 600" and max-reserved-bandwidth 100 (since there is no routing protocol on some simple PPPoE link)

Dialer 1 gets attached to a 100mbps ethernet port that leads to the modem which has an 800kbps ADSL uplink. (translates to about 600kbps in application throughput in real life).

How does the router detect congestion ? It gets data at 100mbps from the lan, and is able to push it out the ethernet link to the modem at

100mbps.

Does the "bandwidth 600" command really tell the policy-map that any throughput higher than that will cause congestion ?

I last worked on this a couple of years ago and things may have changed but here is what I found.

On IOS almost no QoS works as advertised or as you might expect. There are many many exceptions to what works and these exceptions are undocumented. There will be many fine configuration examples but it turns out that none of them work on your platform/interface-type/ something-else and that what works and what doesn't work is not described.

Given that I have got QoS to actually work on DSL.

I forget all of the details but I think I can recall enough.

1. QoS ONLY works outbound on an interface.
2. Traffic shaping cannot be used on a dialer.
3. The trick on DSL for OUTBOUND traffic is to use

interface ATM0 ... ! noting relevant here

#sh run int atm0.1 interface ATM0.1 point-to-point bandwidth 512 pvc 0/38 vbr-nrt 448 448 !

That appears to be an understatememnt !

I found an example on a cisco web page that said you hacve to use the shape command on a parent policy-map to define available bandwidth, and that policy-map then does a service-policy that calls in your real policy-map.

BUT, that example applies to a ethernet interface, not to a dialer interface. I get a "GTS: not supported on this interface" had to lookup what GTS means (generic traffic shaping).

I will look into it. But it is quite easy to get a bittorrent going at

59KB/s, and then watch it as I make a phone call and make lots of noise on phone. It *should* cause the BitTorrent client to lower the output rate.

When I decided to go with Cisco, I didn't expect the above sentence to apply to a company that makes enterprise and even carrier grade products.

Configuring the 2924 switch was much simpler and worked according to the documentation. But this 871W router is quite the challenge when you can't find documentation that actually applies to it.

BTW, can someone confirm that one has to put the class-map and policy-map statements ahead of the interface definitions in the startup config ?

I hage mine after, and when booting the rooter, it could complain about the policy-map being unknown. But once booted, I was able to enter the service-policy command in the interface without complaint.

Moving the class-map and policy-map statements above the interface command that have the service-policy command seems to have solved the problem. The ACLs can still be after the interface definitions, even those being used by the class-map statement.

Well I have never noticed any issues with command order.

I just use conf t and enter the commands. I would not mess with external text editors and tftp say to try to change the order of the commands.

Usually IOS just lets you put what you want in and assumes that undefined items will be defined later.

Well everything except QoS seems to work quite well:-)

Sorry, I got it in my head that it was an 876 that you had.

One trick I recall was using a loopback and PBR to force all traffic to the loopback and then doing QoS on the outbound from the loopback.

I recall that QoS worked quite well on Ethernet interfaces. Is there a way for you to get rid of the dialer?

When you use the vbr-nrt thing on the ATM it links the ATM and the dialer queues. The term I think cisco used was pushback. It allows the ATM queue to push back against the dialer queue and stops it from just blasting away. This I recall did work but still not hierarchical policy maps.

In some cases I ended up using rate-limit to constrain non-critical traffic and reserving bandwidth for voice. I described this briefly in a prior message. Not ideal as rate limit drops out of spec traffic instead of queuing it but it did work since TCP copes with lot frames. Modern TCP stacks with selective ACK cope rather well.

Have you tried ver 15?

You havent mentioned hierarchical policy maps? They dont seem to work on all interfaces.

Have you tried a policy map on your ethernet? I know it makes no sense to put an IP based policy on an interface without an address but I have seen references to the use of such maps on ATM interfaces. I was dubious and never got round to trying it.

Finally - TAC?

To get a non PPPoE ADSL link would tripple my monthly bill. The local mafia (Bell Canada) has decided that non PPPoE ADSL was a premium service and charges and arm and a leg for it.

I tried this. Didn't work on the dialer interface. It appeared to do something on the ethernet interface which, despite handling PPPoE traffic from the dialer. Show QUEUE IN Fa4 would show individual TCP streamns and a whole bunch of information that would never show when applied to the dialer interface. But voIP traffic wasn't given any priority.

Perhaps I need to revisit this approach and try various permutations to see if I can get it to limit non voip traffic.

Would probably cost more than the value of the modem :-)

Well, I think I found something which works, thanks to a supportforums.cisco.com posting:

class-map match-any class-voip description VOIP traffic QOS match access-group name ACLvoip ! ! policy-map voip-QoS class class-voip priority 128 ! policy-map voip-parent class class-default shape average 500000 service-policy voip-QoS

and apply "service-policy output voip-parent" to the fast ethernet 4 interface instead of the dialer 1 interface. The trick was to avoid defining a "class-default" in the child policy-map.

the "shape average" is what tells the router what your upload/outbound bandwidth is. (I'll probably have to adjust this based on speed tests for this supposed 800kbps uplink minus ATM overhead.

Now, I have a question:

an 800kbps ADSL1/2 uplink gives 716kbps of real throughput once you remove the ATM overhead. (1696 bytes of ATM packets to transmit 1 ethernet of 1518 bytes).

In terms of the "shape average" command for that policy-map applied to the ethernet interface that carries PPPOE traffic, but which prioritises traffic based on IP characteristics,

what does it apply to ?

ethernet packet ? (1518 bytes, yields 716kbps) pppoe packet ? (1500 bytes, yields 707kbps IP packet ? (1492 bytes, yields 703kbps) IP payload ? (1452 bytes, yields 684kbps)

(Remember that this router is unaware of ATM protocol and overhead because that is handled by the separate ADSL modem).

Is fast ethernet 4 the interface that your ADSL modem plugs into?

Don't know - but I would probably go with 684 on the basis that it's best to err on the side of caution, so that there's room for a little error correction. Talking of which: my ISP has enabled interleaving at the DSLAM, which should reduce the impact of transient RF interference on the phone line, at the cost of increasing latency by perhaps 10 milliseconds.