From: Charles Church (cchurch@wamnet.com)
Date: Wed Aug 06 2003 - 11:30:48 GMT-3
Jason,
Your math is right. The 12.1 caveat make your job much easier, because it
doesn't allow a protocol with packets larger than the byte count defined to
'sneak' bytes through the system for too long. Eventually a packet will be
dropped if it's borrowed too much. Since it now keep track of 'overages',
I'd say keep it simple, and use 10,000 bytes as your total of all protocols.
So if you wanted your distribution to be 50%, 25%, 15%, and 10%, your byte
counts would be 5000, 2500, 1500, and 1000. On slower WAN links you might
want to use a total number smaller than 10,000, like maybe 5000. Divide it
out the same way then, giving you 2500, 1250, 750, and 500. Of course if
there's any question, present your question to the proctor. Since you can
explain in detail your problem, they'll see you know what you're talking
about and give you some direction.
Chuck Church
CCIE #8776, MCNE, MCSE
Wam!Net Government Services
13665 Dulles Technology Dr. Ste 250
Herndon, VA 20171
Office: 703-480-2569
Cell: 703-819-3495
cchurch@wamnet.com
PGP key: http://pgp.mit.edu:11371/pks/lookup?search=chuck+church&op=index
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Jason Cash
Sent: Wednesday, August 06, 2003 10:14 AM
To: 'John Matijevic'; ccielab@groupstudy.com
Subject: RE: Custom Queueing - ONCE AND FOR ALL
So would my calculations have been correct? And what about the 12.1 caveat?
What signifigance does it play?
-----Original Message-----
From: John Matijevic [mailto:matijevi@bellsouth.net]
Sent: Wednesday, August 06, 2003 9:01 AM
To: Jason Cash; ccielab@groupstudy.com
Jason,
This has been discussed in previous thread. The author used packet size of
10000 bytes, of the lab. If they dont specify you can use whatever number
you want. Again, for clarification ask the proctor.
Sincerely,
Matijevic
----- Original Message -----
From: "Jason Cash" <cash2001@swbell.net>
To: <ccielab@groupstudy.com>
Sent: Wednesday, August 06, 2003 9:55 AM
Subject: Custom Queueing - ONCE AND FOR ALL
> I nearing my lab date and a certain few items still nag at me. One is
> custom queuing and detemining the byte-count based on bandwidth
> requirements. Now before you go, "not another one!", I have read the
> archives here, as well as on cisco, IPExpert, etc. and they all seem to
> contradict one another.
>
> At times, I have felt comfortable with my level of knowledge, but then in
> doing some scenarios, I see that my answers are not matching their's and
> don't want to be penalized in the lab. The formula I have come to agree
> with is the one listed on Cisco's website @:
>
>
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/qos_c
> /qcpart2/qcconman.htm#xtocid1151317
>
> It states:
>
> 1. Divide the percentage of bandwidth you want to allocate to the queue by
> the packet size, in bytes.
>
> 2. Normalize the numbers by dividing by the lowest number.
>
> 3. Normalize the numbers by dividing by the lowest number (round up)
>
> 4. Convert the packet number ratio into byte counts by multiplying each
> packet count by the corresponding packet size.
>
> 5. To determine the bandwidth distribution this ratio represents, first
> determine the total number of bytes sent after all three queues are
> serviced:
>
> 6. Then determine the percentage of the total number of bytes sent from
each
> queue:
>
> 7. If the actual bandwidth is not close enough to the desired bandwidth,
> multiply the original ratio by the best value, trying to get as close to
> three integer values as possible.
>
> Then there is this listing which only confuses more:
>
> Note: CQ was modified in Cisco IOS Release 12.1. When the queue is
depleted
> early, or the last packet from the queue does not exactly match the
> configured byte count, the amount of deficit is remembered and accounted
> for the next time the queue is serviced. Beginning with Cisco IOS Release
> 12.1, you need not be as accurate in specifying byte counts as you did
when
> using earlier Cisco IOS releases that did not take deficit into account.
>
> What does that final note mean to me? Does it eliminate the need for step
> 7? With that in mind, I pose the following example:
>
> DLSW - Telnet = 50% (based on default 1500 pkt. size)
> IPX - ICMP = 25%
> UDP = 15%
> default = 10%
>
> 50/1500 = .0334/.0067= 4.98 = 5 *1500 = 7500
> 25/1500 = .0167/.0067= 2.49 = 3 *1500 = 4500 (both 3 and 4500 are not 1/2
of
> above!)
> 15/1500 = .0100/.0067= 1.49 = 2 *1500 = 1500
> 10/1500 = .0067/.0067= 1 = 1 *1500 = 1500
>
> 7500+4500+1500+1500 = 15000
>
> 7500/15000=.5 (50%)
> 4500/15000=.3 (30%, needed 25%)
> 1500/15000=.1 (10%, needed 15%)
> 1500/15000=.1 (50%)
>
> With these numbers, the second queue will get 30% and, more importantly, I
> would probably lose points in the lab. So you can see my conundrum.
>
> Furthermore, how is link speed factored into this? If I were to use a
> multiplier (which I have with 2, and 3 GETTING SAME RESULTS) eventually,
> the total byte count will exceed 64k.
>
> The solution provided the following:
>
> DLSW - Telnet = 5000 byte count
> IPX - ICMP = 2500 byte count
> UDP = 1500 byte count
> default = 1000 byte count
>
> Their math adds up, but doesn't show you how they came to those numbers.
I
> assume they used pkt. sizes of 1000 (which i thought contrasts what cisco
> states)
>
> I thank anyone that has taken the time to read this and hope i can get
> clarification before my lab attempt.
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Sep 02 2003 - 18:53:54 GMT-3