Re: [LARTC] TCP window based shaping

[marco ghidinelli <marcogh@linux.it>]

On Fri, Feb 11, 2005 at 02:57:59AM +0000, Ed Wildgoose wrote:
> 
> I like the sound of this idea, but I don't follow the details?
> 
> Certainly it seems to me that you can do most of the work by only 
> looking at outgoing ACK packets.  For example with certain assumptions 
> we can simply measure the outgoing ACK rate, assume this is dependent on 
> the amount of data being controlled by our bandwidth throttling, and 
> therefore we get a really good estimate of the effect of our current 
> incoming rate.  However, this breaks down if for example the sender was 
> not sending data as fast as possible.

we have to estimate the Acknowledge data rate and if the sender is
overlimit we can begin to slowdown his traffic. or something similar...

> Also simply delaying ACK's doesn't seem to be the whole answer because 
> the sender should simply see this as a longer RTT and increase the 
> window size to keep more data in transit.  Seems that we need to do a 
> little of both, eg examine outgoing ACK speed, reduce the window to the 
> approx correct size and then our RED/tail drop takes care of the fine tuning

hehe, right. 
and if we are lucky, there will be a router in the internet
that will 'taildrop' that traffic for us, so we are not wasting our bandwith.

(i didn't tested this algorithm, but in a network simulator (ns) it
works).

> As others have said, it's stuff like Bittorrent which really shows the 
> weaknesses in the current system.  I find that even throttling 
> bittorrent to say, half the incoming bandwidth still shows regular 
> increases in latency, no doubt to the effects of the sudden rush of 
> incoming connections. (or slow start effects basically).

i'll do a lot of testing on this.. bittorrent will be a pain, i guess.

> In the BWMGR product (or whatever it is called), I get the impression 
> they do more work on controlling initial windows to try and throttle 
> slow start back some?  Seems to me that one could do more work around 
> the time of the initial ACK to get a window size more in keeping with 
> the flow for that tcp class?  If we only allocate 10Kb of our connection 
> to that class, and we are connected via some broadband device, then 
> nowhere in the world is more than 350ms away, and hence a window size of 
> 65535 is clearly wayyy to large - lets fix this early?

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

bye!

p.s. sorry for my bad english...
-- 
BOFH excuse #266:

All of the packets are empty.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/