On Monday 10 December 2001 12.59, Martin Devera wrote: > jamal would probably say here that it is nonsence to delay/queue packet > which already arived to your box :) In a station trying to shape the traffic sent to him it does by limiting the waste of retransmits. egress queues does not help then as there is no egress where to queue the packet. To argue that it is nonsense to have a ingress queue for your own received packets is the same as to argue that it is nonsense to have a egress queue for routed packets. The packet dynamics are the same, only the application is slightly different. To summary: ingress queues makes sense when you want to shape the traffic sent to you. This is most obviously true when looking at a station, but also true to some extent in routers. To get the minds working on the router case consider the following router: ppp0 256 Kpbs link to ISP eth0 100 Mbps lan 1 eth1 100 Mbps lan 2 eth3 100 Mbps lan 3 And you want without needing to involve your ISP reasonably shape incoming traffic received on ppp0 to not use more than 64kbps for rsync in total. Doing such a setup using ingress shaping is "trivial". Doing it using egress shaping on each of the ethernet interfaces is not. Sure, the queues is only of use if the queue can be large enough to fit significant portions of your active TCP windows, but when they are they can significantly increase link efficiency by trading per packet latency. Regards Henrik
