[c-nsp] Hierarchical QoS Policies

[Cameron Dry]

You're probably running into limitations imposed
by the tx-ring (interface hardware fifo queue).



-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Andre Beck
Sent: Thursday, 7 April 2005 11:50 PM
To: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] Hierarchical QoS Policies


Some clarifications:

On Thu, Apr 07, 2005 at 02:49:12PM +0200, Andre Beck wrote:
> 
> The way I configured this is BTW described at several places in the 
> IOS docs, locations where I found it are "FR shaping" and "QoS on 
> Tunnel interfaces".

It's even used in an example in the QoS Command Reference Guide for
12.3T found at

http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps5207/products_
command_reference_chapter09186a00801a7ee2.html#wp1055837

where it states:

------------------------------------------------------------------------
Examples

 The following example creates a hierarchical service policy
 in the service policy called parent:

  Router(config)# policy-map child
  Router(config-pmap)# class voice
  Router(config-pmap-c)# priority 50
  Router(config-pmap-c)# exit
  Router(config-pmap)# exit
  Router(config)# policy-map parent
  Router(config-pmap)# class class-default
  Router(config-pmap-c)# shape average 10000000
  Router(config-pmap-c)# service-policy child
------------------------------------------------------------------------

Would they really plug an example of "LLQ under a shaper" into the
reference guide if it won't work? I didn't think so.
 
> First question is: Why is traffic of a class that exceeds the limits 
> of this class dropped entirely instead of falling through to the next 
> classes in the policy map including the final class-default? Or is it 
> but gets lost due to congestion in that class?

Ok, found that documented: When not congested, traffic with a strict
priority denotion can exceed its bandwidth. If, however, there already
is congestion, it will be dropped. Not that I completely like that
policy, but at least it's rational to some amount and I can deal with
it.
 
> Second and even more important: After increasing that burst size, I'm 
> having my pings back, but with very large and jittering RTT. It seems 
> to classify correctly and apply the bandwidth correctly, but it 
> doesn't seem to prioritize and LLQ as expected. This should work with 
> a shaper, shouldn't it?

And thats the point: I've now tested this:

- With 12.3(11)T4 on the same 831
- On a 1760 with a 12.3(8)Tsomething, service-policy applied to a
  FastEthernet Subif
- On said 1760 applied to a Tunnel interface. This is essentially
  my production setup (when replacing the simple ICMP class stuff
  with somewhat more elaborate Precedence matching).

The result: RTTs go up and jittery (to something like 60 to 140ms for
400 byte pings) as soon as other traffic congests the shaper. It
*seems* like LLQ is not working, but from practical experience with ISDN
these RTTs are not actually bad - a congested B-channel usually involves
RTTs beyond one second. Looking closer at them, I realized that at
100kbps, a full size packet of 1500 bytes aka 12000 bits will have a
serialization delay of 120ms, so if the shaper emulates the queueing
behavior of a real interface up to and including the blocking of packets
due to serialization delay of other packets that have just seized the
interface, well, it would explain the RTT values I see. I have not found
detailed documentation about the shaper and how it interacts with LLQ so
far, any pointers are welcome. Dito hints on whether my above theory is
valid or not. I'll go test this by simply comparing how ICMP behaves in
the same congestion situation if *not* classified and prioritized as
such.

TIA,
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 <-
_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/