Re: [LARTC] Re: further CBQ/tc documentation ds9a.nl/lartc/manpages

[Henrik Nordstrom <hno@marasystems.com>]

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

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/