QoS - Priority queue not working

[Spinovski]

Hello Cisco experts

I have been studing QoS over the last months, since it's very important and complicated topic for CCIE and professtional work as a network administrator, Finally I was able to understand the theory but for some reason my practice doesn't match Cisco documentations and courses

I wanted to apply this configuration to my home network, Since i also play video games on steam and since these games are realtime and very sensitive to congestion (Packet loss, latency...etc) just like VoIP or video traffic.

First of all my home Internet is 1 Mbps Upload which is low but enough to launch a video game on steam, I wanted to give steam traffic 700 Kbps strict priority which is enough to play or watch a game, the class-default class has 300 Kbps with WRED for early dropping and congestion avoidance.

No matter what I did, when I try to provoke a congestion to my Internet on the Upload direction, ( For exemple I upload a big file that saturate the Upload), my Cisco router 1841 doesn't give any priority to my steam traffic (I can clearly see lateny on game, packet loss and can't even watch or play the game, I sent ICMP packets to Valve and clearly saw packet loss and latency Up to 2000 ms due to network congestion), I stop uploading the file, everything is back to normal, the game works well.

I thought my ISR G1 1841 was old, I tried an ASR920 which is a powerful, that's what we use for our customers when we deliver MPLS and Internet circuits. The result is the same, the game lags which means the router doesn't put those steam traffic to the priority queue.

Here is the configuration:

Identify Valve (Steam) traffic using ACL (Valve has 2 IP blocks):

ip access-list extended steamoutacl
10 permit ip any 162.254.192.0 0.0.7.255
20 permit ip any 155.133.224.0 0.0.31.255

class-map match-any steamoutcmap
match access-group name steamoutacl

! Policy-map on LAN interface to tag steam traffic with DSCP EF !

policy-map steamoutpmap
class steamoutcmap
set ip dscp ef
class class-default
set ip dscp default




class-map match-all STEAM
match dscp ef


policy-map STEAM
class STEAM
priority 700  <=======(Strict priority queue with 700kbps for real time steam video game traffic)
class class-default
bandwidth 300  <=====(CBWFQ with 300 kbps)
random-detect <=====(WRED)

Interface G0/0/0 <======= (WAN Interface)

service-policy output STEAM




Interface G0/0/1 <====== (LAN interface)

service-policy input steamoutpmap

Please note that I have also tried simple configuation without tagging the traffic with EF,  here is an example:

policy-map steamoutpmap
class steamoutcmap
priorty 700

class class-default
bandwidth 300
random-detect

Interface G0/0/0

service-policy output steamoutpmap

Am I missing something with the QoS configuration, is there anything else to enable so the router perform the LLQ/Strict priority correctly ?

Thank you for your help

Spinovski
Network administrator

[Joseph W. Doherty]

"Am I missing something with the QoS configuration, is there anything else to enable so the router perform the LLQ/Strict priority correctly ?"

Yes, what you're missing is a parent shaper, assuming your gig interface isn't physically also running at 1 Mbps (which is, I believe, a pretty safe assumption).

Besides the need for a shaper, I would advise against using LLQ, as you're are doing.  I would also advise against using WRED.

". . . studing QoS over the last months, since it's very important and complicated topic . . ."

I agree that QoS is an important topic, although often ignored until real-time traffic, mixed in with other traffic, really showcased the need for it, but as it being complicated, I don't really believe it's that complicated, although the way it's often "taught", and the latest "suggested/recommended" approaches, do make it appear complicated.

For some fun, try this:

policy-map Fun1
class class-default
shape average 850000

int g0/0/0
service-policy output Fun1

See what kind of behavior you get pinging Valve while doing your upload.

As QoS varies between IOS versions, if you don't obtain much better ping response for the prior (or even if you do), try:

policy-map Fun2
class class-default
shape average 850000
service-policy Fun2-child !correction

policy-map Fun2-child
class class-default
fair-queue

int g0/0/0
service-policy output Fun2

Let me know how the above turns out.

[Spinovski]

Hello Joseph,

Thank you for your response

I agree that I had missed the Parent Class-Based Shaper that triggers the software queuing, although this is theoretically true but in my real world testing, the router still doesn't give the priority bandwidth to Valve traffic.

I tried to give Valve traffic Strict priority "600 kbps" and class-default "200 Kbps", when I upload a file the router does better this time but it's intermittent, in other term the latency got improved but most of the time it increases again  Up to 1800 or higher then 2000ms for Valve traffic to the point where the QoS queuing config is useless, please see the images "Pinging Google which belongs to class-default on the left and valve on the right

Here is my configuration:

policy-map steamoutpmap
class steamoutcmap
priority 600
class class-default
bandwidth 200

! For some reason "fair-queue" couldn't be accepted here it gives the message "deconfigure bandwidth before issuing this command in this class", which I tried to delete "bandwidth and reverse it but same issue occur.!

policy-map steamparentpmap
class class-default
shape average 800000 16000 (tc=20ms)
service-policy steamoutpmap

int f0/0
service-policy output steamparentpmap

Thanks again !

[Joseph W. Doherty]

You're pinging through the router, not from the router, correct?

Your 1 Mbps upload bandwidth is using what kind of Internet service connection?

Could you post stats from

show policy-map

interface (when doing your test)?

You did not try the exact examples I provided, correct?

What IOS is running on your router?

[Spinovski]

Hello Joseph;

Yes I am pinging through the router from my pc running the live game
My Internet connection is a DSL, At the suburb area where I live we are limited to 1Mbps Upload

Here are the stats : 

Home-Cisco#show policy-map int f0/0
FastEthernet0/0

Service-policy output: steamparentpmap

Class-map: class-default (match-any)
83699 packets, 32391477 bytes
5 minute offered rate 134000 bps, drop rate 0 bps
Match: any
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
800000/800000 4000 16000 16000 20 2000

Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 82720 31393985 27550 22609229 no

Service-policy : steamoutpmap

Class-map: steamoutcmap (match-any)
22854 packets, 4292373 bytes
5 minute offered rate 42000 bps, drop rate 0 bps
Match: access-group name steamout
22854 packets, 4292373 bytes
5 minute rate 42000 bps
Queueing
Strict Priority
Output Queue: Conversation 72
Bandwidth 700 (kbps) Burst 17500 (Bytes)
(pkts matched/bytes matched) 6636/1286743
(total drops/bytes drops) 0/0

Class-map: class-default (match-any)
60845 packets, 28099104 bytes
5 minute offered rate 91000 bps, drop rate 0 bps
Match: any
Queueing
Output Queue: Conversation 73
Bandwidth 100 (kbps)Max Threshold 64 (packets)
(pkts matched/bytes matched) 21854/22316634
(depth/total drops/no-buffer drops) 0/979/0

My configuration is almost similar to the one you suggested except the shaping parent is set to 800000 kbps with tc 16000 kbps, this time I played with the bandwidth reservation, I gave 700 Mbps to LLQ (Valve) and 100 Mbps to class default, I upload a file,  

Ironically, some times it works fine as you see on the first image, I uploaded a file, the left image is the class default and right is Valve, latency to Valve is within the standards of around 280ms which is normal because my traffic is going from Europe to Canada through an IPSEC tunnel to Valve server in Canada or USA. 

Here is a second image where the high latency to valve occur again for some reason, not sure why the router queuing process works intermitently.

The router i use is ISR 1841
IOS version : Version 12.4(13r)T
System image file : c1841-adventerprisek9-mz.124-16.bin"
c1841-adventerprisek9-mz.124-16.bin

Thank you,

[Joseph W. Doherty]

Ah, some interesting factoids in your posting.

I don't recall ever experiencing Cisco's LLQ not working correctly, although sometimes to get it to work at its best you also need to decrease the TX ring limit on the egress interface (as the hardware FIFO queue, provides FIFO like results).  I've used TX ring limits as small as 2 or 3.

You mention DSL and IPSec tunnels.  If your DSL is like what's commonly used in the US, PPPoE often reduces the effective MTU by 8 bytes, tunnels and/or IPSec overhead could decrease your effective MTU up to about 100 bytes.  These, and not knowing other possible issues, end-to-end, might be contributing to your bouts of high latency, i.e. why it appears to work sometimes, and not other times (because some, possible most, of the received latency isn't at your router's interface, when you push much data during an upload).

Somethings you can try, include: the aforementioned reduction of interface's tx ring limit.  Try setting your f0/0 interface's IP MTU to 1400 and use tcp adjust-mss 1360.  Try reducing your shaper's Tc to 10ms (a value that has often worked well for me).  Try reducing your shaper's bandwidth down toward what you believe your game bandwidth need really is.  (If there's congestion issues upstream of your device, shaping slower might be the only "cure".  Unfortunately, of course, shaping slower "loses" bandwidth that otherwise might be available, but if we shape to what's actually and usually available, we can obtain more predictable performance.  [BTW, Cisco has a variable/dynamic shaper feature, in a later IOS, only works with DMVPN, I recall.])  (Also BTW, Cisco recommends LLQ should not be larger than about 1/3 the available bandwidth.  I suggest it might work okay up to about 1/2 the available bandwidth.  [NB: Although both Cisco and I agree you should limit the LLQ bandwidth allocation, we do so for different reasons.  Cisco's recommendation is to provide sufficient bandwidth for other non-LLQ traffic.  My recommendation is to insure LLQ has available burst bandwidth. {Otherwise you can run into the same issues, queuing latency and/or drops, on a dedicated link with X amount of bandwidth used exclusively by the "LLQ" traffic.}])

BTW, believe your IOS version is pre-HQF (introduced 12.4[20)T).  If so, that might explain why you were having issues trying to use FQ earlier.  Hmm, been so long, I forget most of the internal workings of pre-HQF, but my "Fun1" version's shaper might do FQ or even WFQ "under the covers".  That version might be very worthwhile trying, again, experimenting with dropping shaper bandwidth limit.  (Understand, FQ, alone, often negates the needs for many, if any, classes beyond LLQ, which often is only needed for really sensitive traffic like VoIP.  Further, if your pre-HQF shaper uses WFQ, tagging it's traffic with non-zero IPPrec will boost such traffic dequeuing priority.)

I've often said:

policy-map handles-90%-of-all-QoS-needs
class class-default
fair-queue

policy-map handles-99%-of-all-QoS-needs
class real-time
priority percent 35
class class-default
fair-queue

policy-map handles-99.9%-of-all-QoS-needs
class real-time
priority percent 35
class foreground
bandwidth remaining percent 81
fair-queue
class background
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue

Unfortunately, Cisco switches don't usually support FQ.  Pre-HQF, I recall, only supports WFQ in class-default.  With your pre-HQF IOS, this policy-map might work, if Fun1's shaper, alone, doesn't appear to WFQ.

policy-map Fun1-FQ
class class-default
shape average #
fair-queue

[Spinovski · Accepted solution]

Hello Joseph,

I now understand that HQF has first been introduced on 12.4(20T) which totally makes sense why the shaper and queuing are working out even though i have changed the MTU, bc value as well as the tx-ring-limited value to no avail.

I retried the same configuration with my ASR920 and it worked fine, the purpose of this was to practice and have a better understanding on how QoS works which was a dilemma for me, I believe I got what I needed to know thanks to your valuable explanations and details.

We can consider this discussion as resolved.

Thanks again and best luck

Spinovski