Re: [LARTC] TCP window based shaping

[Ed Wildgoose <lists@wildgooses.com>]

Sorry for the belated reply:

>instead of shaping the incoming traffic and estimate rate from the
>outgoing traffic, you can 'delay' the outgoing ACK, and estimate the rate
>from the raise of the sequence number.
>  
>

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.

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

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

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?

How do we fit this thing into the linux QOS architecture anyway?

Ed W

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