Re: [LARTC] Making tcp start transfers slow

[Andy Furniss <andy.furniss@dsl.pipex.com>]

Patrick Petersen wrote:
> Sorry for the long response time.
> 
> On Sun, 18 Apr 2004 00:13:49 +0100, Andy Furniss <andy.furniss@dsl.pipex.com> 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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/