In brief, QoS (quality of service) tries to provide some assurance for network traffic handling beyond just best effort. When there's congestion, it treats different types of traffic differently; often treating some traffic better at the expense of treating other traffic worst.
A good example would be a VoIP (voice over IP) traffic sharing the same link with a FTP file transfer.
Assume you have two hosts connected switches at 100 Mbps, but those switches are interconnected by a 10 Mbps link. FTP will try to drive up to 100 Mbps, but at the 10 Mbps link, traffic will queue. When the queue fills, packets will drop. This will tell TCP to back off its transmission rate. What you should see is a classic saw tooth pattern of transmission rate.
Now while FTP was doing the above, you also send 80 Kbps of VoIP traffic across the same 10 Mbps link. VoIP tends to be very sensitive to delay, drops and even jitter. VoIP packets intermixed with the FTP packets are very likely to suffer delay, drops and jitter; result a very poor, if usable at all, voice call.
With QoS, we classify or identify we have VoIP traffic and treat it better than other traffic. Usually, for real-time traffic like VoIP, we'll guarantee the 80 Kbps it needs from the 10 Mbps. This, though, reduces the bandwidth available to FTP by 80 Kbps. FTP will take longer to transfer its data, but VoIP will perform the same regardless of whether FTP is using the link or not. We've provided a quality of service for the VoIP traffic.
QoS can encompass even more. For just the FTP alone, it's rather wasteful that it keeps overrunning the 10 Mbps link, which causes packet drops, which makes for a effective transfer rate often less than the full link capacity and/or wastes bandwidth. To improve the quality of the FTP transfer (goal exactly 100% bandwidth utilization; no waste), you might adjust the TCP receive window size, clock ACKs, or set the ECN bit. (NB: advanced techniques like these are not usually found on most ordinary network devices, but are some of techniques used by some traffic optimizing appliances.)
The "easy" alternative to using quality of service is to insure there's never congestion. If the switch interconnection link was 1 Gbps, instead of 10 Mbps, we could run both the 100 Mbps FTP and the 80 Kbps VoIP without issue.
Where bandwidth is "cheap", such as on LANs, then QoS might not be needed. On WANs, where bandwidth isn't so "cheap", QoS might be necessary if you're trying to guarantee service (or performance).
Often where to use QoS is whenever applications are adversely impacted by having insufficient bandwidth that can be obtained from other applications whose needs are not as stringent. What to use sometimes is as simple as insuring FQ is enabled on a router's outbound interface.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...