s. 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 percent Email: 10 percent Telnet/SSH: 10 percent Remainder (default queue): remaining 50 percent It is very tempting to assume that the link is now divided into six pieces, with half evenly divided among voice, voice control, FTP, email, and Telnet/SSH, and the other half devoted to everything else. I think the reason this is such a common misconception is because it's a very simple view and, as such, is very easy to understand. In reality, if email is the only traffic riding over the link, it will use up 100 percent of the link. The same is true for any type of traffic. When there is no congestion, any protocol can use any amount of available bandwidth (there I go again) it needs. Say a single user decides to download a massive file using HTTP. If there is no other data traversing the link, that download may saturate the link. Chapter 31: Introduction to QoS Now, say someone else starts a similar download using FTP. Because FTP is guaranteed 10 percent of the link, the scheduler will forward the FTP packets before it will forward the HTTP packets. Because the FTP queue will be serviced before the default queue, the FTP download will impact the HTTP download. Without getting too deep into how the scheduler works, it's worth pondering the following issue: in this scenario, with no other traffic, will FTP get better service or will HTTP get better service? FTP is only guaranteed 10 percent of the link. That means that HTTP can take up the re- mainder, right? Wouldn't that mean that HTTP would get better service than FTP? The truth lies in the way the scheduler works. Because FTP is configured as a priority over HTTP (which falls into the default queue), the scheduler will service FTP packets before HTTP packets. The difference will probably not be obvious to the users, though, unless there is congestion. This is an important