1). All data traffic should be marked with lower priorities than voice RTP and control packets. You may have noticed that if you follow these best practices, you'll now be running pretty short of IP precedence levels. Of the original eight, only levels 0, 1, 2, and 4 remain. IP precedence 4 should be used for critical applications that are not quite as critical as voice, such as video conferencing. IP precedence 0 (essentially, no prior- ity) is used for "best effort" traffic, which leaves only levels 1 and 2. (As you can see, IP precedence doesn't scale well. It's generally best to use diffserv where possible.) Don't forget about yourself. When the links get congested, and you need to trouble- shoot a router problem on the other side of your network, you don't want to have your telnet or SSH traffic being dropped in favor of an FTP download. Because SSH and telnet don't require much bandwidth, the impact of giving them a high priority is small, but the return during a crisis is enormous. By now, you should be compiling an ordered list of how you want to prioritize your protocols. The best effort line should always be at the bottom. This will end up being your default queue. It's also a good idea to keep an entry labeled to be determined, which serves as a placeholder for normal traffic. Assuming you keep the highest priorities on top, the list might look something like this: Voice RTP Voice control Determining Requirements Telnet/SSH (multiple protocols can share the same priority and queue) ---to be determined--- Everything else (default-best effort) In general, you should resist the urge to put HTTP traffic in any queue other than the default. HTTP traffic is not typically mission-critical. However, in some environ- ments-for instance, call-center agents using a web-based application on a remote server-it is important to prioritize HTTP. We'll use this as an example, and assume that all traffic to or from the server (10.10.100.100) on port 80 should be prioritized. The list should now look like this: Voice RTP