Re: [LARTC] TCP window based shaping

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

David Boreham wrote:
> 
>> Does anyone have any pointers on how other people have implemented tcp 
>> window adjustment to do bandwidth shaping?
> 
> 
> Hmm....I _heard_ that Packeteer had patents on this and
> so nobody else was attempting to do it.
> 
> Possibly an incorrect rumor, but it made sense to me.

They say on their site that their algorithm is patented which could be a 
pain if it's the obvious solution.

The more I think about it (probably not enough yet), the more I think 
that just keeping state and depiggybacking acks could achieve much the 
same thing if your shaper is clever enough.

The worst senario for me is bittorrent, and if I could depiggyback the 
acks I don't see that playing with window size on top of that would be 
any better than keeping state so that I had an idea of how much was 
unstoppably on the way.

Closing the window down isn't going to stop what's allready left the 
sender and is sitting in a big modem buffer any quicker than me stopping 
sending acks. Just knowing how lagged out each connection is would be 
enough to allow me to change bandwidth more elegantly without too much 
buffer filling. Not with anything that exists in Linux now - but even 
just hacking HTB/HFSC so that a class could behave as full as soon as it 
sees traffic would be a start. I can allready sort of break slowstart by 
treating new connections harshly (short queue), though it would be nice 
in the case of bittorrent to be able to detect connections that go back 
into slowstart aswell - sfq sort of singles them out, but it's a bit 
late by the time it gets them.

I guess there are other things you could do aswell like trying to 
account for different rtts with the intention of avoiding bursts.

Andy.


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