Re: Class-default contradiction

From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Thu Jul 12 2007 - 14:07:40 ART


Well, I can not stop thinking about it as a progammer.
You have a bunch of packets being queued at some queues, and you have to
decide what to transmit next. So follow the rules:

1- Is there anything in LLQ ? send it, restart.
2- Ok, we have a bunch of queues now to serve, do it with some bytes
from each queue in a proportional way to its allocated bandwidth.
restart at each packet sent, but keep track of where you were.
(sort of WRR with deficit tracking)
3- Nothing up there to send ? Oh well, send whatever is in the default
queue, er, class.

Bandwith allocations make a minimum. If you put enough packets into
a queue, you can starve class default.
Agree with you that if you put a bandwidth there, it just becomes
another queue.

BTW, this is not my invention, it comes from some cisco QoS guru, whose
identity is protected until he agrees to show up (Tim ? :)
Obviously, all understanding errors are my own.

-Carlos

Jason Guy (jguy) @ 12/07/2007 13:52 -0300 dixit:
> Carlos,
>
> The one thing that the doc implies is the default class does not need to
> allocate bandwidth. It is not in contention with the other queues by
> default. It allocates bandwidth from the non-"max-reserved-bandwidth"
> pool. So it is automatically has access to 25%, so the other queueing
> cannot affect it by default since they allocate bandwidth from the
> reservable 75%. Therefore, I cannot see how it can be starved if it is
> protected along with the control traffic.
>
> I think if the class-default is allocated bandwidth (using the bandwidth
> {remaining} command), it is included with the other queues. But by
> default is does not show up in the configuration and I think that is
> when it is part of the 25% non reservable bandwidth. Once it is
> specified, I think it is just another reservable bandwidth queue.
>
> Hope I am making my question clear. I understand how to use the
> class-default, and what it does on a wole, but I am questioning where it
> allocates bandwidth from. It is not entirely clear.
>
> Jason
>
>> -----Original Message-----
>> From: Carlos G Mendioroz [mailto:tron@huapi.ba.ar]
>> Sent: Wednesday, July 11, 2007 3:23 PM
>> To: Jason Guy (jguy)
>> Cc: ccielab@groupstudy.com
>> Subject: Re: Class-default contradiction
>>
>> AFAIK, max-reserved-bandwidth is just an administrative limit.
>> It will not let you go over this "reservation" limit.
>>
>> But regarding class-default, that's another story.
>> In the process of giving access to bandwidth, there are 3
> "priorities":
>> -LLQ (AKA priority) goes first,
>> -Bandwidth allocated classes
>> -default class (if not explicitly allocated some BW).
>>
>> So what the docs say is true, you can starve class default if you
>> oversubscribe the rest. And the numbers aare done in layer 3,
>> so the layer 2 headers are extra.
>>
>> -Carlos
>>
>> Jason Guy (jguy) @ 11/07/2007 16:03 -0300 dixit:
>>> I have been studying QoS some more, and I think the documentation
>>> contradicts itself in relation to the class class-default. In the
>>> Congestion management overview, it say this:
>>>
>>>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
>>> fqos_c/fqcprt2/qcfconmg.htm#wp1001203
>>>
>>> CBWFQ Bandwidth Allocation
>>> The sum of all bandwidth allocation on an interface cannot exceed 75
>>> percent of the total available interface bandwidth. The remaining 25
>>> percent is used for other overhead, including Layer 2 overhead,
> routing
>>> traffic, and best-effort traffic. ***Bandwidth for the CBWFQ
>>> class-default class, for instance, is taken from the remaining 25
>>> percent.*** However, under aggressive circumstances in which you
> want to
>>> configure more than 75 percent of the interface bandwidth to
> classes,
>>> you can override the 75 percent maximum sum allocated to all classes
> or
>>> flows using the max-reserved-bandwidth command. If you want to
> override
>>> the default 75 percent, exercise caution and ensure that you allow
>>> enough remaining bandwidth to support best-effort and control
> traffic,
>>> and Layer 2 overhead.
>>>
>>> Then as I read through the WFQ configuration guide, it says this:
>>>
> http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/
>>> fqos_c/fqcprt2/qcfwfq.htm#wp1017373
>>>
>>> Configuring the Class-Default Class Policy
>>> The class-default class is used to classify traffic that does not
> fall
>>> into one of the defined classes. Even though the class-default class
> is
>>> predefined when you create the policy map, you still have to
> configure
>>> it. ***If a default class is not configured, then traffic that does
> not
>>> match any of the configured classes is given best-effort treatment,
>>> which means that the network will deliver the traffic if it can,
> without
>>> any assurance of reliability, delay prevention, or throughput.***
>>>
>>>
>>> The interesting thing is that in one paragraph it basically says 25%
> of
>>> the interface is reserved (by default) for the class-default, L2,
> and
>>> control. Then the other says class-default is best effort. I would
>>> consider best-effort traffic to have to contend with the other
> Queue's
>>> for bandwidth. In this case, it seems the class-default is not in
>>> contention for the reservable 75% of the interface bandwidth (by
>>> default).
>>>
>>> Am I misinterpreting this? If you change the max-reserved-bandwidth
> to
>>> 95%, does this mean any traffic not classified has to contend for 5%
> of
>>> the control traffic? What if you put a bandwidth statement under
> the
>>> class-default class? Does that affect where it allocates it's
> bandwidth
>>> from? Seems like the class-default should be treated like any other
>>> class.
>>>
>>> Jason
>>>
>>>
> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>>
>> --
>> Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
>
>

-- 
Carlos G Mendioroz  <tron@huapi.ba.ar>  LW7 EQI  Argentina


This archive was generated by hypermail 2.1.4 : Sat Aug 18 2007 - 08:17:40 ART