From: Scott Morris (swm@emanon.com)
Date: Thu Mar 23 2006 - 12:44:20 GMT-3
CBWFQ does indeed use WFQ (hence the naming convention there), although we
can actually modify bits and pieces with the fair-queue command.
As for the RED/WRED portion, this does modify, as you mentioned the behavior
of a drop policy. When we introduce a shaper, we're making life more
interesting, but the same conditions still apply. Traffic that is not sent
during a particular Tc within the shaper sits in the queue. Given the
bursty nature of traffic, it is feasible that WAY too much traffic would
come in at a given time, and COULD still overflow the size of the queue
available.
The RED feature would affect behavior during situations such as this. So it
all depends on what end-effect we are looking to achieve in our balance of
fairness.
The shaper utilizes whatever queuing mechanism exists on the
interface/subinterface. If one is not there, a shaper creates one (hence
your inability to do queuing on subinterfaces unless the shaper comes
first), but this is part and parcel with the congestion management queue.
By the way, to enable random detection, you also need to specify a
guaranteed bandwidth for the particular class (your config didn't have
that), but the router would remind you!
The class "class-default" is the only one that you have the option to
specify the fair-queue command in to influence how decisions are made. It's
still on by default, this just allows you to tweak things as you find
necessary.
HTH,
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
IPExpert CCIE Program Manager
IPExpert Sr. Technical Instructor
swm@emanon.com/smorris@ipexpert.com
http://www.ipexpert.com
Some output:
Emanon-R1(config-if)#do sh run | begin policy-map
policy-map testing
class web-test
set dscp cs7
policy-map ShapeTest
class four
shape average 64000
class five
shape average 128000
bandwidth 128
random-detect
!
Emanon-R1(config-if)#do sh policy int e0/0
Ethernet0/0
Service-policy input: testing
Class-map: web-test (match-all)
14 packets, 5284 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: protocol http url "*test.txt*"
QoS Set
dscp cs7
Packets marked 3
Class-map: class-default (match-any)
5427291 packets, 401641694 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
Service-policy output: ShapeTest
Class-map: four (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 4
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
64000/64000 2000 8000 8000 125 1000
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
Class-map: five (match-all)
0 packets, 0 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: ip precedence 5
Traffic Shaping
Target/Average Byte Sustain Excess Interval Increment
Rate Limit bits/int bits/int (ms) (bytes)
128000/128000 1984 7936 7936 62 992
Adapt Queue Packets Bytes Packets Bytes Shaping
Active Depth Delayed Delayed Active
- 0 0 0 0 0 no
Queueing
Output Queue: Conversation 265
Bandwidth 128 (kbps)
(pkts matched/bytes matched) 0/0
(depth/total drops/no-buffer drops) 0/0/0
exponential weight: 9
mean queue depth: 0
class Transmitted Random drop Tail drop Minimum Maximum
Mark
pkts/bytes pkts/bytes pkts/bytes thresh thresh
prob
0 0/0 0/0 0/0 20 40
1/10
1 0/0 0/0 0/0 22 40
1/10
2 0/0 0/0 0/0 24 40
1/10
3 0/0 0/0 0/0 26 40
1/10
4 0/0 0/0 0/0 28 40
1/10
5 0/0 0/0 0/0 30 40
1/10
6 0/0 0/0 0/0 32 40
1/10
7 0/0 0/0 0/0 34 40
1/10
rsvp 0/0 0/0 0/0 36 40
1/10
Class-map: class-default (match-any)
7 packets, 1286 bytes
5 minute offered rate 0 bps, drop rate 0 bps
Match: any
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Alexei Monastyrnyi
Sent: Thursday, March 23, 2006 4:38 AM
To: Petr Lapukhov
Cc: Group Study (E-mail)
Subject: Re: random-detect + fair-queue in CBWFQ
oops.. sorry, posted to the wrong chain initially...
As DQOS Exam Guide states "CBWFQ can use WFQ as the default behavior for
unclassified traffic. Packet loss behavior can take advantage of WRED..."
"Weighted" part of RED is either dscp-based or precedence-based, so IMO if
we switch on WRED for any class in CBWFQ, we override the default modified
tail-drop which comes with WFQ out of the box.
Hope DQOS citation does not break NDA... :-)
The interesting thing here is when it comes to shaping queuing. If we put "
class ABC
shape XYZ
fair-queue
random-detect
- does it modify a drop policy for shaping queue or is it for congestion
management only?
IMO it drop policy for shaping should be modified by doing this, otherwise
we don't have any mean to control it. Thought it was not promised. :-) One
more point tfor this is that we don't have any explicit congestion
management queuing for the class in this case but queuing inherited from
physical interface or sub-interface. Modifying tail-drop behavior for those
queues from MQC doesn't seem to be viable.
Any comments from gurus?
A.
on 23/03/2006 09:23 Petr Lapukhov wrote:
> Hello group,
>
> Maybe this is too much of a theoretical question, but..
>
> It would be really nice to know, how do "random-detect" and "fair-queue"
> work together in CBWFQ.
>
> I understand the concept of RED with FIFO queueing, actually this is
> how it worked back in days:
>
> RED/WRED/Flow WRED - all were considered a "queueing strategies", and
> when you enable random-detect on interface, you have to disable
> fair-queue, etc. The queue becomes FIFO, and RED is actually a _drop_
> strategy.
>
> Okay, now, if we have bandwidth configured in CBWFQ class, the class'
> queue becomes FIFO.
> So one can easily understand how RED works here, no problems.
>
> But then, we come to work with class-default. We can turn on WFQ/RED
> at the same time, withing class-default.
>
> Recalling that WFQ has, by itself, it's own drop strategy, which is
> based on queue-limit, CDT and SNs of each flow, i become puzzled here.
>
> How does RED incorporate in WFQ? Does it works per-flow, with CDT
> being one of the thresholds? How does it affect original WFQ drop
behavior?
>
> Maybe someone here knows the answer? :)
>
> TIA
> Petr
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Apr 01 2006 - 10:07:40 GMT-3