Re: [LARTC] TCP window based shaping

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

Ed Wildgoose wrote:
> 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 delayed acks complicate things a bit - If you are not going to 
deconstruct and spawn new acks then you will always be working with 
pairs. If I had a meg I guess I wouldnt care (and for those with highly 
asymmetric dsl links they are almost a must) but for slow links it's 
nice to be able to get 1 ack = 1 packet.

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

IIRC you have 1 meg - I always assumed that this would be nicer that
my 1/2 meg. I'll have to do some tests when I get time and make some 
graphs to see how my setup behaves, it's a bit tricky with bt though as 
things can change alot over time on the same torrent.

If you are throttling to 50% and not using RED then it's going to be 
more aggressive WRT over dropping and maybe this causes problems by its 
self.

> 
> 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 not sure about this one but if you are p2p with someone whose buffer 
is flooded and you are competing for their bandwidth with others you may 
actually over throttle yourself by reducing window.

The way broadband in the UK is going - higher bandwidth and usage caps I 
think we may also see more contention and not knowing what your 
bandwidth is, is going to be tricky :-) (policers to classify?)

Andy.

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


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