format, the VA01 transaction would then require 490 KB per transaction. If link and
bandwidth-provisioning remained unchanged, then the new end-user response time would be
approximately 32 seconds per transaction. If there is no other traffic traversing the 512 kbps link, the
transaction would require approximately 8 seconds. Clearly this is a case where QoS alone is insufficient
to accommodate required service-levels given the nature of the data traffic.
e-mail per day (including all attachments). While E-Mail is a highly asynchronous application and is
recommended to be classified as best-effort traffic, it nonetheless requires bandwidth. The daily average
mail spool divided over an 8 hour workday equates to average of 2.8 kbps of e-mail traffic per employee.
If the remote branch has 50 employees, this requirement becomes 140 kbps as a daily average. But,
e-mail traffic generally displays a cyclical burst according to time of day (with highest traffic levels
between 8-10:30 am). If the assumption is made that e-mail traffic during these periods is double the
daily average, then more than 280 kbps of bandwidth could be consumed by e-mail during these hours.
policies, but also in determining when to increase link bandwidth.
a daily basis. Application updates, fluctuation in the numbers of users, varying business environments,
as well as the time of day, month, and year, all affect bandwidth requirements of data applications.
Therefore, rather than attempting to determine exact kilobits of bandwidth requirements for data
applications, a simpler and proven approach is to assign relative priorities to data applications.
that are defined, the less the distinction between service-levels. To illustrate, the available bandwidth
could be likened to a pie. If the pie is sliced into 64 gradually smaller pieces and then served to
respectively important guests (with the largest slice being served to the most important guest), it would
be quite difficult to ascertain who's getting the better slivers. Likewise, having too many classes will
reduce the overall effectiveness of QoS. Therefore, it is recommended that you define only four classes
of data traffic at the most.
of QoS provisioning is dampened. Taken to an extreme, if all applications are assigned 'gold' service
levels, then the end result is the same as when no QoS is provisioned at all (first-in-first-out scheduling).
For this reason, applications provisioned with QoS should be limited to only a select few (maximum 3
applications per class).
classes of traffic: important, best-effort and less-than-best-effort. Important traffic can additionally be
sub-divided into multiple categories, as required.
Mission-critical applications are those that directly contribute to the core operations of an enterprise.
These applications are highly-interactive and are therefore sensitive to loss and delay. Examples of
mission-critical applications include ERP applications, such as SAP, Oracle, and PeopleSoft, as well as
proprietary applications that were designed in-house.