From: David Anderson (dma@xxxxxxxxx)
Date: Wed Jun 06 2001 - 15:26:42 GMT-3
Here is a good explanation of determining the byte count in custom queuing:
Determining the Byte Count
To ensure that the configured bandwidth allocation is as close as possible
to the required bandwidth allocation you must determine the byte count
based on each
individual protocol's frame size. Without doing this, your percentages may
not match what you configure.
For example, suppose one protocol has 500 byte frames, another has 300 byte
frames, and a third has 100 byte frames If you want to split the bandwidth
evenly
across all three protocols, you might chose to specify byte counts of 200,
200, and 200 for each queue. However, that will not result in 33/33/33
ratio. That is
because when the router serviced the first queue it would send a single 500
byte frame, when it serviced the second queue it would send a 300 byte
frame, and when
it serviced the third queue it would send two 100 byte frames, giving you
an effective ratio of 50/30/20. Had you instead specified 1000, 1000, 1000,
the router
would send 2 500 byte frames, 5 200 byte frames, and 10 100 byte frames
with a bandwidth ratio of exactly 33/33/33.
However, the delay to send 1000 bytes might be too large. Another
alternative is to specify 500, 600, 500 which will result in a ratio of
31/38/31, which may be
acceptable.
Fortunately, you do not have to use trial and error to determine the
correct byte counts. Instead, simply follow these steps:
1) Produce a ratio of all frame sizes, starting with the largest as 1. For
example, assume the frame sizes of protocol A were 1086 bytes, protocol B
were 291 bytes
and protocol C were 831 bytes. The ratios would be:
1086/1086, 1086/291, 1086/831
2) Now multiply the results by the percentages of bandwidth you want each
protocol to have. In this example we will allocate the following
percentages, 20% for A,
60% for B, and 20% for C. This will give us:
1086/1086(0.2), 1086/291(0.6), 1086/831(0.2)
or
.2, 2.239, 0.261
3) Again, normalize the ratio by dividing each value by the smallest value,
that is
.2/.2, 2.239/.2, .261/.2 which equals 1, 11.2, 1.3
This is the ratio of the number of frames that must be sent such that the
percentage of bandwidth that each protocol uses is approximately in the
ratio of
20%,60%,20%.
1.Note that any fraction in any of the ratio values means that an
additional frame will be sent. In the example above, the number of frames
sent would be 1
(1086 byte frame), 12 (291 byte frames) and 2 (831 byte frames) or
1086, 3492, and 1662 bytes respectively from each queue. These are the byte
counts
you would specify in your custom queuing configuration.
To determine this bandwidth distribution this represents, first determine
the total amount of bytes sent after all three queues are serviced:
1 x 1086 + 12 x 291 + 2 X 831 = 1086 + 3492 + 1662 = 6240
Then determine the percentage of the 6240 bytes that was sent from each queue:
1086/6240, 3492/6240, 1662/6240 = 17.4%, 56%, 26.6%
As you can see, this is close to the desired ratio of 20/60/20. The
resulting bandwidth allocation can be tailored further by multiplying the
original ratio of 1:11.2:1.3
by an integer, and trying go get as close to three integer values as
possible. For example, if we multiply the ratio by 2, we get 2:22.4:2.6. We
would now send 2
(1086 byte frames), 23 (291 byte frames) and 3 (831 byte frames) or
2172/6693/2493 for a total of 11358 bytes. The resulting ration is
19%/59%/22% which is
much closer to our desired ratio that we achieved above.
Do not forget that using a very large byte count may cause other problems.
At 02:12 PM 6/6/2001 -0400, Ryan LaTorre wrote:
> There is a section in the Cisco Press "IP Quality of Service" book on
> this, but if you don't have the book, I also found some discussion of
> this at:
>
>
>http://127.0.0.1:8080/cc/td/doc/product/software/ios120/12cgcr/qos_c/qcp
>art2/qcconman.htm#xtocid57019
>
> Not having a lot of real-world experience with extensive QoS, I found
> the Ciscopress book to be pretty good. It is very new, and covers the
> modular CLI as well. Check it out...
>
> From the perspective of the lab, I would hope they're not expecting
> candidates to memorize "average" byte counts for different protocols.
> Many protocols vary greatly anyhow - IP can be 64 bytes average is
>voice
> is the only traffic type being used (for example) but if FTP is
> extensively in use, maybe it's upwards of 1500 bytes...
>
> Ryan
>
> > ----- Original Message -----
> > From: "Daniel C. Young" <danyoung99@mediaone.net>
> > To: <ccielab@groupstudy.com>
> > Sent: Wednesday, June 06, 2001 3:15 AM
> > Subject: custom queue: determining byte-count?
> >
> >
> > > Group,
> > >
> > > How do you determine which byte-count to use? I have read in several
> > places
> > > on Cisco's web site that it all depends on the byte count of the
> > protocol.
> > > But does anyone know the byte counts of specific protocols for, say
> > SNA?
> > >
> > > Is there a resource that lists the proper byte counts for all the
> > protocols?
> > >
> > > Many thanks,
> > >
> > > Daniel C. Young
> > > Sr. Network Engineer
> > > CCNP (ATM, Security & Voice Specialist),
> > > CCDP, CCSE, MCSE+I
> > >
> > > SBC Internet Data Center
> > > (949) 221-1928 Work
> > > (714) 350-8945 Cell
> > > young@pobox.com
> > > **Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
David Anderson
Network Design Engineer
Enterprise Solutions Architecture & Design
(408) 853-5515
dma@cisco.com
| |
..:|||||||:...:|||||||:..
C I S C O S Y S T E M S
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:31:19 GMT-3