Re: [LARTC] TCP window based shaping

[Ed Wildgoose <lists@wildgooses.com>]

>i'm just trying to slow the traffic (it's for my master|degree|pedigree
>thesis, so i don't want to waste all my life on this) without changing
>the window size.
>
>  
>
>>How do we fit this thing into the linux QOS architecture anyway?
>>    
>>
>
>i'm writing a scheduler that just delay the ack rate (it's in a very
>preliminar state, so nearly nothing was done).
>
>now i'm looking for a place where to put the flow information (in a
>conntrack module, maybe?)
>  
>

Have a look at the BWMGR qos product.  They have some interesting thoughts.

Basically their idea seems to be that you only need to get the window
shaping (or ACK shaping) roughly right.  The fine tuning happens just as
now with the queue simply filling up a little.  Seems to me that this is
right, if you just get the window even +/- 50% of the target bandwidth
then you can do fine tuning by delaying ACK and buffering data.  The
trick is basically to avoid the huge splurge of data during slow start
which can cause queuing on the ISP end.

Otherwise I am broadly speaking very happy with the default QOS.  It's
just this queueing which occurs when a bunch of connections all start
together which is the problem.  This isn't really just a bittorrent
issue though because a busy webserver would likely see the same conditions?

Are we all on the same page as to what the problem is?  Any more
thoughts on how to tackle it?  I'm still not convinced that delaying
ACK's is really any better than the current option to buffer incoming
data.  I guess the receiving machine TCP stack gets it earlier so the
app looks more responsive, but other than the lower lag I don't see much
difference really?

Curious to hear how your project gets on though!  Please keep us informed!

Ed W

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