This paper was written because I wanted to listen to shoutcast mp3 streams without being cut and wanted to have a good response time with ssh even when uploading lots of data via ftp or dcc.
Basically it explains how to setup 2 classes of traffic for your upstream to get a more "interactive" connection and why to do it this way.
(C) 2001 Emmanuel Roger. Licensed under the GNU Free Documentation License.
When you upload data on a slow link, a long queue of packets may form in your local buffer.
Thus, if you happen to be uploading a file with ftp, any telnet, chat, or ack packets may get caught behind the queued ftp packets and will be delayed.
Telnet and chat will become sluggish, or unusable due to long queing delay. Delaying acks may adversely affect downstream services.
A better Quality of Experience can be achieved by expediting (giving priority to) certain types of upstream traffic for services that require a high level of interactivity.
Much of the Internet is still based on 'best effort' delivery in which all packets are treated roughly equally. But human requirements for services delivered over the Internet, don't work that way: A few ftp packets delayed for a second or two will most likely have no impact on the user. A telnet packet delayed as little as 400 milliseconds can result in a typing error by the user.
Therefore, giving priority to packets whose delay _will_ directly be experienced by the user at the expense of those packets whose delay will be invisible to the user is a good strategy to improve the Quality of Experience for the user.
A similar argument can be made in the downstream direction (e.g., don't starve real audio for the sake of email downloads which can tolerate more delay than real audio, telnet, etc.). However, we users have little control in that direction.
In a perfect world, the OS would detect which traffic needs higher output priority. But we aren't in a perfect world.
So we just divide the traffic into two classes:
This is the kind of traffic which will be given the higher priority, but the less bandwidth.
It is composed of small packets ( tcp ack, irc, ssh, telnet, http requests etc...)
This kind of traffic is given the lower priority, but most of the bandwidth.
It is composed of large packets (ftp data, http responses, email with large attachments, pr0n ...)
In opposition to traffic classification by port, ip, or tcp flags, classification by size of packets doesn't need to be redefined every time you add a service to your machine or network and suits well an adsl or cable modem connection.
There are better ways to class different kinds of traffic, but this is easy and seems to work well for the average user.