On Mon, 16 Jan 2006, Flemming Frandsen wrote:
Currently (pre-2.6.16) you can only attach a real traffic shaper to the the output of a device, but why not allow a traffic shaper to be attached to the input of a device, without any of the IMQ/IFB nonsense? I think the problem is that attaching the trafficshaper to the output queue is easy whereas attaching it to the input is hard as there is no queue there to build from, so noone bothered to write it.
No, attaching to the input is just as easy as to the output. The reason that isn't implemented is that it wouldn't really be useful. Say you're sharing bandwidth between 2 users, A and B. Suppose A is sending more agressively than B; then, you can throw away A's overage packets, giving A and B equal shares of your upstream bandwidth. Some LAN bandwidth is wasted by A, but this isn't much if A is running a good TCP. No uplink bandwidth is wasted.
On the other hand, say A and B are downloading large files, and A's server is sending more than B's server. The router at your ISP is going to send you whatever gets there first, so that'll mostly be A's traffic. If you now shape this on input, you'll be throwing away packets that have already gotten to you, and took up downlink bandwidth. By throwing out packets going to A, you can make A and B have "fair" shares of the bandwidth; but B's share won't actually increase (and A's share will get smaller) unless A's server starts sending slower. (This is why A's server should be running ECN.)
The only way to do downlink shaping without wasting your bandwidth would be at the ISP - the other end of your weakest link to the net. Unfortunately, I don't know of any ISP that will do shaping for you.
Alexey _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
