Re: [LARTC] Making tcp start transfers slow

[Patrick Petersen <lartc@schmakk.dk>]

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 :)

> 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! :)

> > 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.

> 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?

-- 
Patrick Petersen <lartc@schmakk.dk>

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