Graham Leggett wrote:
Mohan Sundaram wrote:
I've my misgivings with this scheme.
What you are doing makes sense only if the number of connections is a
constrained resource. If bandwidth is the constraint, then shaping by
source IP irrespective of number of connections will do the job. As
far as I've seen, routers can support 200k connections and this is
sufficient for many large LANs - say 500 node LAN with 400 connections
per node.
In many cases, the user may not know how many connections he is
opening or which app is consuming connections. Thus, the user may not
be in a position to take remedial action and hence will be at a
disadvantage.
In the network in question, bandwidth is minimal (many many users
sharing 512kbps). As a result, unlike in typical networks where
simultaneous connections are statistically insignificant, in this case
one user running many bittorrents can pretty much wipe out network
performance to a ratio of 20 to 1 or more.
The typical response I have seen to this scenario is to try and
prioritise certain protocols over others, but this strategy has the
disadvantage of dictating to the user that they can only use those
certain protocols.
What I would like to do instead is allow the user to use any protocol
they like, with the caveat that attempting to open many connections
simultaneously will result in a steadily decreasing share of the pipe,
rather than a steadily increasing one.
Your aims are admirable - I left my last ISP because they implemented
app discrimination. Maybe they couldn't set their ellacoyas to do it
fairly - whatever.
Your situation is different - many many on 512kbs (512kbit or 4mbit?)
either way the problem is that you are trying to shape ingress from the
wrong end of the bottleneck which just isn't easy or totally doable.
Egress shouldn't be affected by number of connections.
As you have found the more connections the harder ingress shaping
becomes - and you may need to sacrifice 50% of your bandwidth to keep
control.
There are things that can be tweaked regarding your setup - queue
lengths being the main one. If you give users their own queues then you
have to compromise - either the total is too long for your link or you
have too short a queue for each user. ESFQ is the only thing (need to
patch) that will do user fairness and maintain a queue len setting for
the link (would be nice if hfsc etc could do this - may be possible to
hack it as I see there is a drop function on leaf queues IIRC).
Another hack is to make the esfq head drop (assumes you only send
bulk/established connections to it).
Without patching/hacking the think to do is use short queues to make
sure you drop packets often so the tcp senders don't flood your
ISP/teleco buffer. On 512kbit I also used to send new connections to an
even shorter queue (new marked using iptables connbytes), this gets them
out of tcp slowstart quicker.
Bittorrent is slightly harder as it uses tcp full duplex for bulk - so
acks tend to get piggybacked and stuck in egress queues meaning that non
piggybacked acks overtake them (assuming your egress is set this way)
and ack big chunks of a window at once causing burstiness - using short
queues for egress bt helps this.
You are always goinng to be somewhat screwed when ingress shaping as
nothing happens to your shaping untill it's too late - maybe someone
will make an ingress shaper one day that can be a bit predictive and
back off other traffic for new connections sooner rather than later.
Andy.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
