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 icon next to the DSCP value gives a detailed traffic graph in a pop-up screen.
The DSCP Groups can be viewed by clicking on the drop down arrow on the widget and select DSCP Group. 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 time period for which the report is shown can be controlled by using the time selection icon at the top.
You can view the top TOS information by clicking on the drop down arrow at the top of the widget:
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 trade-offs 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.
The semantics of the TOS field values (expressed as binary numbers):
|0001||minimize monetary cost|
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).
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.
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: