QoS
QoS or Quality of service is the most important factor that
determines how effectively the available enterprise bandwidth is being
used in the WAN. It is also an index of the overall User Experience of
the available Bandwidth.
The QoS feature by default lists out the Top DSCP IN
Report.Clicking on the Show Applications link lists out the various
DSCP values along with the list of applications that comprise the DSCP.
It also list out details on Traffic and percentage utilization of the
total traffic by each of the applications and the DSCP group as a
whole. Clicking on the icon next to the DSCP value gives a detailed
traffic graph in a pop-up screen.
DSCP
The DSCP Groups can be viewed by clicking on the View DSCP
Group link. If no DSCP Groups have been created earlier, then an
appropriate message is displayed and the user is prompted to create a
DSCP group. The bottom of the page lists the Top DSCP IN Traffic as a
Pie Distribution.
The time period for which the report is shown can be
controlled by using the time selection bar at the top.
TOS
Because the Internet by itself has no direct knowledge of
optimizing the path for a particular application or user, the IP
protocol provides a facility for upper layer protocols to convey hints
to the Internet Layer about how the tradeoffs should be made for a
particular packet. This facility is the "Type of Service"
facility, abbreviated as the "TOS facility".
The TOS facility is one of the features of the Type of Service
octet in the IP datagram header. The Type of Service octet
consists of three fields. The first 3 bits ( 0,1,2) are for the
first field, labeled "Precedence" , intended to denote the
importance or priority of the datagram. The second field, labeled "TOS"
, denotes how the network should make tradeoffs between throughput,
delay, reliability, and cost.The last field, labeled "MBZ" ( for "must
be zero" ) above, is currently unused. The originator of a
datagram sets this field to zero (unless participating in an Internet
protocol experiment which makes use of that bit). Routers and
recipients of datagrams ignore the value of this field.This field
is copied on fragmentation.
Specification of the TOS Field
The semantics of the TOS field values (expressed as binary
numbers):
1000 |
minimize delay |
0100 |
maximize throughput |
0010 |
maximize reliability |
0001 |
minimize monetary cost |
0000 |
normal service |
The values used in the TOS field are referred to as "TOS values",
and the value of the TOS field of an IP packet is referred to as
the "requested TOS". The TOS field value 0000 is referred
to "default TOS." Because this specification redefines TOS values to be
integers rather than sets of bits, computing the logical OR of two TOS
values is no longer meaningful. For example, it would be a
serious error for a router to choose a low delay path for a
packet whose requested TOS was 1110 simply because the router
noted that the former "delay bit" was set.
Although the semantics of values other than the five listed above
are not defined , they are perfectly legal TOS values, and
hosts and routers must not preclude their use in any way. Only the
default TOS is in any way special. A host or router need not make any
distinction between TOS values
For example, setting the TOS field to 1000 (minimize delay) does
not guarantee that the path taken by the datagram will have a
delay that the user considers "low". The network will
attempt to choose the lowest delay path available, based on its
(often imperfect) information about path delay. The network
will not discard the datagram simply because it believes that the
delay of the available paths is "too high" (actually, the network
manager can override this behavior through creative use of
routing metrics, but this is strongly discouraged: setting the
TOS field is intended to give better service when it is
available, rather than to deny service when it is not).
Use of the TOS Field in Routing
Both hosts and routers should consider the value of the TOS field of a
datagram when choosing an appropriate path to get the datagram to its
destination.The mechanisms for doing so are discussed in this section.
Whether a packet's TOS value actually affects the path it takes inside
a particular routing domain, is a choice made by the routing domain's
network manager. In many routing domains the paths are
sufficiently homogeneous in nature that there is no reason for routers
to choose different paths based up the TOS field in a
datagram. Inside such a routing domain, the network manager may choose
to limit the size of the routing database and of routing protocol
updates by only defining routes for the default (0000) TOS.
Neither hosts nor routers should need to have any explicit knowledge of
whether TOS affects routing in the local routing domain.
Inherent Limitations:
The most important of all the inherent limitations is that the
TOS facility is strictly an advisory mechanism. It is not an
appropriate mechanism for requesting service guarantees.There are two
reasons why this is so:
- Not all networks will consider the value of the TOS field
when deciding how to handle and route packets.Partly this is a
transition issue: there will be a (probably lengthy) period when some
networks will use equipment that predates this specification.
Even long term, many networks will not be able to provide better
service by considering the value of the TOS field. For example,
the best path through a network composed of a homogeneous collection of
interconnected LANs is probably the same for any possible TOS
value. Inside such a network, it would make little sense to
require routers and routing protocols to do the extra work needed to
consider the value of the TOS field when forwarding packets.
- The TOS mechanism is not powerful enough to allow an
application to quantify the level of service it desires. For
example, an application may use the TOS field to request that the
network choose a path which maximizes throughput, but cannot use that
mechanism to say that it needs or wants a particular number of
kilobytes or megabytes per second. Because the network cannot know what
the application requires, it would be inappropriate for the network to
decide
to discard a packet which requested maximal throughput because no "high
throughput" path was available.
Copyright © 2012,
ZOHO Corp. All Rights Reserved.