From: gladston@br.ibm.com
Date: Mon Dec 06 2004 - 11:08:50 GMT-3
========
With MQC, the percent specified for a class of traffic is relative to
the available bandwidth, not the actual interface bandwidth. By
default, I believe 25% of the bandwidth is reserved, but that can be
changed.
========
Take care. This has changed. See Cisco Article "Understanding the
max-reserved-bandwidth on ATM PVCs" (altough mention ATM is seems to be
valid for others).
For 12.2T (as we know on the Lab) bandwidth percent is refering interface
bandwidth, and not available. They include a new command, bandwidth
remaining percent, to get the old behavior.
I wish a knew it before :)
"Devi Mallampalli" <Devi.Mallampalli@chubb.com.au>
12/04/2004 05:57 PM
To
"ccie2be" <ccie2be@nyc.rr.com>, <ccielab@groupstudy.com>
cc
Alaerte Gladston Vidali/Brazil/IBM@IBMBR
Subject
RE: Interoperability of CQ with CBWFQ
Thanks for your response , Tim/Gladston.
Yes I agree on your point. Indeed I forgot to mentioned that my example
of 64k on the wire is of 100% on the available bandwidth ( assuming I
have tweaked with reference B/W command and even though it is not a best
practice to creep in to last 25% of the available B/w which normally
dedicated to L2 encaps and L3 protocol mechanics).
So let me rephrase my Q. Assuming that 64k in my example is the total
available bandwidth on the wire , is there any difference between both
CQ config/functionality and CBWFQ config/functionality. And more
importantly is it necessary to have both the configs on the device (i.e.
can they interoperate some how on the same device) ?
And another point , as Gladston mentioned earlier, CQ algorithm will
consider the byte-count/size rather than packet count. So suppose you
have two queues , one of which supports an interactive session with many
short packets , while the other queue contains bulk transfer with few
large packets. If you configure the Router to service these 2 queues
with the same byte-count , it will tend to forward a lot more of small
packets. But the net share of the bandwidth will be roughly equal on
average.
Regards
Devi.
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Sunday, 5 December 2004 11:51 AM
To: Devi Mallampalli; ccielab@groupstudy.com
Subject: Re: Interoperability of CQ with CBWFQ
Hi,
One difference I can think of is this:
With MQC, the percent specified for a class of traffic is relative to
the available bandwidth, not the actual interface bandwidth. By
default, I believe 25% of the bandwidth is reserved, but that can be
changed.
Thus, with MQC, in your example, when you configured ftp for 30%, that's
30% of 75% of 64k, not 30 % of 64k.
HTH, Tim
----- Original Message -----
From: "Devi Mallampalli" <Devi.Mallampalli@chubb.com.au>
To: <ccielab@groupstudy.com>
Sent: Saturday, December 04, 2004 7:34 AM
Subject: Interoperability of CQ with CBWFQ
> Hi Group,
>
> I was wondering is it possible to make a CQ (with let us say 4 queues
,
> queue 1 = FTP , queue 2 = Telnet , queue 3 = dlsw , queue 16 =
default)
> interoperable with a CBWFQ so that CBWFQ can call any of CQ config
> parameters in any way ?
>
> From my understanding , CQ is a legacy way of deploying or
manipulating
> the " service threshold" a traffic type from default behavior of 20
> packets in the queue depth and 1500 bytes of pick up run by the
> scheduler on her each pass. And this mechanism I believe is
successfully
> taken over by CBWFQ algorithm which is more flexible (64 queues as
> oppose 16)and can offer better results. And CBWFQ can do almost all of
> things CQ does in terms of identifying the traffic types (class-maps)
> and deciding what to do with each traffic type (policy map) and then
> applying to an interface with a service policy.
>
> So in other words , to me they both are similar algorithms , one a
> legacy one and 2nd one is more sophisticated with better control.
There
> by I think you can not join CQ with CBWFQ in any manner ???
>
> Let me explain you with an example:
>
> B/W on wire = 64k
> Ftp to have = 30%
> Telnet to have = 20%
> Dlsw to have = 10 %
> Default to have = rest of B/W.
>
> So with the above info , I can calculate the required byte-count of
each
> queue with the below formula.
>
> Ftp = 30% of bandwidth to be given = 64 000 / 8 = 8000 bytes * 30/100
=
> 2400 byte-count , which will go in as "queue-list 1 queue 1
byte-count
> 2400 limit 100"
> telnet = 20% of bandwidth to be given = 64 000 / 8 = 8000 bytes
*20/100
> = 1600 byte-count , which will go in as queue-list 1 queue 2
> byte-count 1600 limit 100
> Dlsw = 10%% of bandwidth to be given = 64 000 / 8 = 8000 bytes *
> 10/100= 800 byte-count , which will go in as "queue-list 1 queue 3
> byte-count 800 limit 100"
> Default = 40% of bandwidth to be given = 64 000 / 8 = 8000 bytes *
> 40/100 = 3200 byte-count , which will go in as queue-list 1 queue
16
> byte-count 3200 limit 100
>
>
> And then these queues will then be applied on an interface with a
> custom-queue command.
>
>
> But now my Q is , since we can do the same thing with CBWFQ too with
the
> following config, am not sure how we can make these 2 algorithms
> interoperate (if at all there is a provision/necessity) the above
config
> of CQ to the below mentioned config of CBWFQ ?
>
> Ip cef
>
> Class-map ftp
> Match protocol ftp
> Class-map telnet
> Match protocol telnet
> Class-map dlsw
> Match protocol dlsw
>
> Policy-map cbwfq
> Class ftp
> Bandwidth percent 30
> Queue-limit 100
> Class telnet
> Bandwidth percent 20
> Queue-limit 100
> Class dlsw
> Bandwidth percent 10
> Queue-limit 100
> Class class-default
> Bandwidth percent 40
>
> Interface s0/0
> Service-policy output cbwfq
>
>
> I appreciate any feed back on this subject.
>
> Regards
>
> Devi
>
>
>
>
> *************************************************************
> This email and any files attached are considered
> confidential and intended solely for the use of the
> individual or entity to whom this email is addressed.
> If you have received this email in error, please send a
> reply message to this email address.
> This footnote also confirms that the above email has been
> scanned for the presence of computer viruses.
> *************************************************************
>
>
This archive was generated by hypermail 2.1.4 : Mon Jan 03 2005 - 10:31:24 GMT-3