There are some fairly wide-ranging misconceptions about what QoS can do. QoS is pretty complex, and a lot of people just skim the documentation and make assumptions based on what they’ve read. Still others read only executive summaries, or worse, extrapolate from information they’ve heard from other misinformed people.
QoS is a very useful technology, but it is not a miracle. It cannot make a T1 perform like a DS3, and it cannot completely prevent packets from being dropped. What QoS can do for you depends on your network and your requirements. If you have a DS3’s worth of bandwidth requirements, no amount of queuing or reservation will make a T1 good enough. In this section, we’ll examine a few common misconceptions.
I can’t tell you how many times I’ve heard this in meetings and technical discussions regarding QoS. While the analogy is useful in certain circumstances, it is a dangerous one because the perception is that each “chunk” of the link cannot be used for other traffic. This is simply not true. The important thing to remember here is that while scheduling of packets always takes place, the limits set are really only enforced during congestion.
Using low-latency queuing as an example, let’s think about the process. Packets come into the interface and are scheduled according to your configuration. Say you’ve used the following allocations for the link:
Voice: 10 percent
Voice control: 10 percent
FTP: 10 ...