ent FTP-10 percent Email-10 percent Telnet/SSH-10 percent Remainder (default queue)-remaining 50 percent It is very tempting (and appealing to many) to assume that the link is now divided into six pieces, with half evenly divided amongst 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 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. 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 ser- vice, or will HTTP get better service? FTP is only guaranteed 10 percent of the link. That means that HTTP can take up the remainder, 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 prior- ity 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 distinction. The scheduler will service FTP first, which means there will be a higher probability that HTTP packets will be dropped. Packets are only dropped when there is congestion, however, SO both proto