 distinction. The scheduler will service FTP first, which means there will be a higher probability that HTTP packets will be dropped. Packets are dropped only when there is congestion, however, SO both proto- cols will seem to operate normally until the link is saturated. To summarize, if there is congestion, QoS helps determine which packets should be serviced and which packets can be dropped. In the case of the FTP versus HTTP ex- ample, since FTP is configured as a priority and HTTP is not, if there is congestion, HTTP packets will probably be dropped. Without congestion, FTP packets will be sent first, but the HTTP packets will, at worst, be queued for a short time before being sent. QoS Limits Bandwidth Let's get semantic. QoS does not limit bandwidth, it guarantees it, which is not the same thing. That is to say, if you have a 1.5 Mbps T1 and you want to run 1 Mbps of FTP across it, a configuration that guarantees 10 percent of the link for FTP will not limit FTP to only 10 percent. Again, with no congestion, any protocol can use up as much bandwidth as it likes, provided no other configured protocol needs its share. If I configure 20 protocols on a DS3 and each one needs 1 Mbps, any one of those protocols can use all the bandwidth it wants, provided that (are you sick of me saying this yet?) there is no congestion on the link. QoS Resolves a Need for More Bandwidth As I've said earlier, if you need a DS3, QoS will not make your T1 "just as good." If you have an oversubscribed link, the best QoS can do is to prioritize which packets should be sent first, which also means it's determining which packets can be dropped! That's right-not only does QoS help some protocols, but it makes others worse. Remember the distinction, though: only during congestion. If you have a T1 and you're trying to shove 20 Mbps through it, it doesn't matter how you prioritize and queue your packets, you're going to drop a lot of them. Common QoS Misconceptions Of course, QoS not resolving a need for bandwidth is the corollary to "th