RE: Custom Queue Confusion

From: Brown, Patrick (NSOC-OCF} (PBrown4@chartercom.com)
Date: Mon Jun 02 2003 - 19:15:12 GMT-3


Even though the solution will produce the same calculation, only one will
service correctly. In the IP and SNA queue, 2 1500 byte packets will be
serviced before moving on to the next queue. In the IPX queue 2 1500 byte
packets will also be serviced before moving on to the next queue. So how
would you be providing an higher ratio of bandwidth to IP and SNA traffic,
if IPX traffic gets serviced the same number of bytes. You might as well
have a byte count of 3000/3000/3000/1500.

When you set the byte count to 9000/9000/7500/4500, now the queues get
serviced correctly. So IP and SNA sends 6 1500 byte packets, IPX send 5 1500
byte packets, and telnet sends 3 1500 byte packets.
Just my 2 cents.

Patrick B

-----Original Message-----
From: Jason Cash [mailto:cash2001@swbell.net]
Sent: Monday, June 02, 2003 3:48 PM
To: 'Hossam Mahmoud'; 'Nguyen Hoang Long'; ccielab@groupstudy.com
Subject: RE: Custom Queue Confusion

I agree with you calculations, but the solution that they provided was:

queue-list 1 protocol ip 1
queue-list 1 pro ip 2 tcp 2065
queue-list 1 protocol ipx 3
queue-list 1 protocol ip 4 tcp telnet
queue-list 1 queue 1 byte-count 9000
queue-list 1 queue 2 byte-count 9000
queue-list 1 queue 3 byte-count 7500
queue-list 1 queue 4 byte-count 4500

So how would the solution you came up with 3000/3000/2490/1500 be incorrect
when, fractionally, they are the same? If I were to use the "3000" count,
would that be considered incorrect?

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Hossam Mahmoud
Sent: Monday, June 02, 2003 11:37 AM
To: Jason Cash; 'Nguyen Hoang Long'; ccielab@groupstudy.com

Pals,
Yes!!In all versions they use the same calulcation method. And in both 12.1
and 12.2 documentations they mention the new borrowing technique that
"Nguyen " is talking about.
 
So i think we HAVE!!! to conclude that the new technique is not related to
calculation method.
 
Giving it a second thought i would say the following:
 
1- The two calculation methods gives almost the same results with slight two
differnaces. First, the accuraccy of the BW distribution between queues.The
documentation calculation technique is less accurate than "Nguyen" method.
Second the length of the queues. "Nguyen" method gives higher queues length.
 
2- Accurate BW distribution is surly prefered.
 
3- But High queues length is not recommended. It may cause unexpected jerky
performance. This jerky performance will be caused due to the fact of
serving shorter queues gives more predictable delays for other queues.

So we have to compromise here.And i think we would rather accept a less
accurate BW distribution more than jerky unexpected performance. Or at least
that is what the documentation says!!!
 
 
As far as i think NOW (not final yet) the new technique for handling queues
will only affect one step in the documentation calculation technique. Here
is the documentation calculation method after applying this change.
 
Calculation Method:

____________________________________________
 
Here is what I do (average pkt 1500)
1) For each queue, divide the percentage of bandwidth you want to
allocate to the queue by the packet size, in bytes.
 30/1500 = .02
 30/1500 = .02
 25/1500 = .0166
 15/1500 = .01
 
2) Normalize the numbers by dividing by the lowest number:
 .02/.01 = 2
 .02/.01 = 2
 .0166/.01 = 1.66
 .01/.01 = 1
 
3) A fraction in any of the ratio values means that an additional packet
will be sent
 
(THIS IS WHERE THE NEW Queues handling technique shows up!!!).
 
The new technique will allow to serve the additional packet once and will
take this in acount
to decrease the serverd bytes in the second cycle serving this queue.

From my understanding to the new technique, I do't think that we need to do
this approx.
any more.
(Please note that if we choosed the factor 3 here!! we will reach the same
values as we
get if we use "Nguyen" method. But as i said before this will affect the
queues lenght
and hence performance.)
 IP = 2
 SNA = 2
 IPX = 1.66
 Telnet = 1
 
4) Convert the packet number ratio into byte counts by multiplying
each packet count by the corresponding packet size.
 IP = 1500x2 = 3000
 SNA = 1500x2 = 3000
 IPX = 1500x1.66 = 2490
 Telnet = 1500x1 = 1500
 
 
5) To determine the bandwidth distribution this ratio represents,
first determine the total number of bytes sent after all three queues are
 serviced:
Based on my info above I get: 3000+3000+2490+1500= 9990
 
6) Then determine the percentage of the total number of bytes sent
from each queue:
 IP = 3000/9990 = .3 (30%)
 SNA = 3000/9990 = .3 (30%)
 IPX = 2490/9990 = .249 (24.9%)
 Telnet = 1500/9990= .15 (15%)
 
What do u all think?? Is it convencing???
Waiting for yr opinions!!
Thanks a lot
SAM
 

Jason Cash <cash2001@swbell.net> wrote:
One more then and I think this horse will be dead.

Based on that information, that being with the changes to 12.1 how should
queues be determined? Even in that link, the example is given with the
antiquated byte count determination.

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nguyen Hoang Long
Sent: Monday, June 02, 2003 2:24 AM
To: Hossam Mahmoud; Jason Cash; ccielab@groupstudy.com

Hossam,

check this:
http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcpr
t
2/qcfconmg.htm#xtocid47

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.

----- Original Message -----
From: Hossam Mahmoud
To: Jason Cash ; 'Nguyen Hoang Long' ; ccielab@groupstudy.com
Sent: Monday, June 02, 2003 1:34 PM
Subject: RE: Custom Queue Confusion

I agree with you but do u know exactly which IOS version supports the new
borrowing technique.

As far as i know the LAB is still using 12.1. IOS ver 12.1 documentation
is
using the same calulation method used by Jason in his initial mail!!

So i think this is the calculation method expected at LABS.....is't it??

Thanks for advise
SAM

Jason Cash wrote:
That actually is the correct answer, but how did you come to get:

30:30:25:15 = 6:6:5:3 ?

How did you know to divide by 5 to get 6:6:5:3? Or did you use some
other
calculation?

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nguyen Hoang Long
Sent: Sunday, June 01, 2003 2:54 AM
To: Jason Cash; ccielab@groupstudy.com

Hi Jason,

I would do by this way for exact ratio:

IP:SNA:IPX:telnet = 30:30:25:15 = 6:6:5:3

therefore:

IP = 1500x6 = 9000 (30%)

SNA = 1500x6 = 9000 (30%)

IPX = 1500x5 = 7500 (25%)

Telnet = 1500x3 = 4500 (15%)

Since we're using new IOS, which permits the router to borrow from the
next
queue for a current queue, your calculation method is not necessary. I
prefer a more simple method.

Long
----- Original Message -----
From: "Jason Cash"
To:
Sent: Sunday, June 01, 2003 12:28 PM
Subject: Custom Queue Confusion

> I am getting really confused on the custom queuing! I have looked over
the
> previously provided links, but those examples don't address the
problem
I
am
> having. Whereas I am instructed:
>
>
>
> IP traffic 30% bw
>
> SNA traffic 30% bw
>
> IPX traffic 25% bw
>
> Telnet traffic 15% bw
>
>
>
> Here is what I do (average pkt 1500)
>
> 1) For each queue, divide the percentage of bandwidth you want to
allocate
> to the queue by the packet size, in bytes.
>
> 30/1500 = .02
>
> 30/1500 = .02
>
> 25/1500 = .0166
>
> 15/1500 = .01
>
>
>
> 2) Normalize the numbers by dividing by the lowest number:
>
> .02/.01 = 2
>
> .02/.01 = 2
>
> .0166/.01 = 1.66
>
> .01/.01 = 1
>
>
>
> 3) A fraction in any of the ratio values means that an additional
packet
> will be sent. Round up the numbers to the next whole number to obtain
the
> actual packet count.
>
> IP = 2
>
> SNA = 2
>
> IPX = 2
>
> Telnet = 1
>
>
>
> 4) Convert the packet number ratio into byte counts by multiplying
each
> packet count by the corresponding packet size.
>
> IP = 1500x2 = 3000
>
> SNA = 1500x2 = 3000
>
> IPX = 1500x2 = 3000
>
> Telnet = 1500x1 = 1500
>
>
>
> Now here is one place I get lost. IPX byte count is the same as IP and
SNA
> and I know that can't be right, but what do I do? 2 is the only
multiple
to
> go by.
>
>
>
> 5) To determine the bandwidth distribution this ratio represents,
first
> determine the total number of bytes sent after all three queues are
> serviced:
>
> Based on my info above I get: 3000+3000+3000+1500= 10500
>
>
>
> 6) Then determine the percentage of the total number of bytes sent
from
each
> queue:
>
> IP = 3000/10500 = .28 (28%)
>
> SNA = 3000/10500 = .28 (28%)
>
> IPX = 3000/10500 = .28 (28%)
>
> Telnet = 1500/10500= .14 (14%)
>
>
>
> This adds up to 98%. So I will wait for some advice before I proceed.
> Basically, when I a queue is rounded up and is equal to a greater
queue,
how
> is that queues byte count determined?

----------------------------------------------------------------------------
-
-
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).

---------------------------------
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).



This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:51 GMT-3