Hi,
I notice that if two or more existing connections match an ingress policing filter, the input bandwidth does not get evenly divided up between the n connections.
Kinda like litters of baby animals, where the stronger babies get more access to the mothers teats and grow up bigger and faster than their siblings.
That's tcp not being fair.
The only workaround that's working for me is to set explicit ingress policing filters, which match src and dest host and port, so for each filter there can only be exactly one connection which matches. Then, it's just a matter of evenly dividing up the allocated total input bw amongst these n processes. This works, but it's not exactly optimal.
Ingress shaping is alot harder than egress. It is possible to use htb/sfq for ingress by either shaping outbound on your LAN interface (if you have only one) or by using IMQ on your WAN interface. I found this nicer than using an ingress policer, but it's not perfect.
In reality if you want to properly shape ingress from behind the bottleneck you need something to keep state on all the TCP connections, have the ability to change the advertised window to control them and to be aware of what unstoppable packets are due in the future from the WAN so that new TCP connections can be started without causing your queues to move into your ISPs buffer. Even if you did that you are still up against bursty delivery of packets and occilations of TCP caused for example, by ack compression.
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
