Sorry for the long response time.
On Sun, 18 Apr 2004 00:13:49 +0100, Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote:
I sortof workaround this using the connbytes netfilter patch to make the first 80k of new connections go into a short queue limited to 1/3 - 1/2 of my downstream bandwidth.
I will try this soon.. I recently screwed my kernel over bad with patch-o-matic, so its fixing time at the moment :)
One possible problem - I don't think connbytes will patch with connmark (which IIRC ipp2p uses). I have been told that it is possible to get them to work, but patch will fail as they both change the same struct, so it's a do it by hand job...
Ahh bittorrent - this is a special case. It uses full duplex tcp - so may break some upstream shapers, you can assume that a fair number of your peers have flooded modem buffers - so there could be quite a few "unstoppable" packets headed your way. The worse thing about it, though is that it runs it's own algorithm on allready open tcps - so existing connections may go back into slowstart.
Thats pretty bad.. But if i get this working, even with bittorrent, i guess that means it will probably work with anything! :)
LOL - I think your idea about reducing rwin may help - easy on a small setup where you have control.
Would it be possible to lower the default window size, and thereby making tcp start up slower, or would this just lower the overall speed?
It could help, but may also give you less of a share of a given uploaders bandwidth. Reducing MTU may also help (if you run BT on linux it may reduce rwin for you aswell).
I don't think you can catch all BT traffic by marking the BT ports, I see ipp2p - can you do it with this or maybe do per IP fairness for bulk traffic?
Im fortunate enough to be able to run a small network with only a few people, so theres no real bad things with people doing whatever they can to cheat. Also, ipp2p should catch torrent connections, and seems to be doing so.
Yes - so you don't need to mark all those ports then.
Be carefull about priorotising acks - don't all TCP packets after syn have ack set. Being lazy on a home setup I get away with giving small packets priority - saves alot of marking :-)
For ingress shaping - I find it nicer to shape per IP with htb and use esfq classic to get per tcp fairness rather than esfq on dst which is going to effectively make many bittorrent connections go into a FIFO, which could make for more burstiness.
I'll make a note, but shouldnt esfq make things more or less fair no matter how much traffic one client has over another?
Yes esfq on dst will make things fair per IP address - but in the case of ingress with the many tcps that BT uses dropping is important to get the sender to back off. Esfq on dst is not really a fairness queue any more WRT individual tcp connections, it may not make much difference, but if you use htb for per IP fairness and esfq classic, then the drops are a bit more likely to get at the most active connections.
I modified esfq to drop from the head of a slot rather than the end - which in theory should make things slightly nicer and changed hash to use dst port. I really ought to make them into a switches (when I work out how) I also intend to patch with the change to sfq that was recently talked about on here. If it looks OK I'll put it up on my webspace sometime - I don't really know what I am doing though :-)
For us small bandwidth users a R(real)FQ would be nice - (e)sfq is OK but it often hashes into the same slot and perturb causes packet reordering which hurts more when used for ingress.
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
