Re: [LARTC] TCP window based shaping

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

Ed Wildgoose wrote:

> I do agree with you, but I think they may have just badly phrased their 
> point.  I *think* what they are trying to say is that with really big 
> devices, ie thousands of connections, then you can't just wait for the 
> traffic to queue up and let it back up like that.  You need to be a bit 
> proactive and kill the traffic right from the start.  I *assume* they 
> mean it's just not feasible to do the equiv of SFQ or some other kind of 
> classifier which can really finely grain the priorities for lots of 
> connections.  Hence their point that you are just shifting latency around.
> 
> Bad point really, but I can kind of see what they might be saying.

Yea maybe I am being a bit harsh and I suppose throttling window will 
save some drops (which would throttle cwind anyway) so it is a bit more 
elegant.

> 
> 
>> It would be nice to slow slowstart like this, to some extent linux TCP 
>> already does this (well it does at LAN speed, it advertises a smaller 
>> window then grows it). Not much help for WAN rates or forwarded 
>> Windows traffic though.
> 
> 
> 
> Well, perhaps this is really what we want to do?  I noticed some 
> interesting looking code on the POM part of netfilter to do some window 
> tracking...

Yea netfilter conntrack does seem a logical place to do this - don't 
know how, though.

> 
>> I don't get the webserver bit - "heavy" browsing on 512kbit link hurts 
>> - typically 4 simultaneous connections over and over. Sortable by 
>> sending new connections to a short, lowish rate sfq (tweaked for 
>> ingress). But only if there is no other bulk aswell. If there is then 
>> I think you need   some sort of prediction/intelligence or a dumb 
>> queue will react too late and over aggressivly - resync bursts aswell 
>> then.
>  
> 
> I do agree.  My point was perhaps more that lots of little connections 
> hurt.  Long lasting ones seem well controlled by current QOS.

Yes I agree.

>  Also, I 
> think SFQ is completely buggering up my IP telephone?  I currently have 
> some SFQ classes on the relevant queues and I wonder if the rehasing is 
> re-ordering the packets?

Maybe - but then if it's interactive traffic it should not really be 
queued enough for it to matter. I hang esfq on my interactive class, but 
it doesn't get used - it's only there because I made it increment an 
unused counter every time a packet arrives and the queue is not empty - 
it always says 0, which means the way I use htb/my marking are working 
as expected. But my home setup is not very scaleable and my marking 
relies on me having control over apps. If I were netadmin for many users 
I would have got round to using hfsc by now.

> 
>> I suppose the gain for marco is that he will not just be delaying acks 
>> - OK he could do the same for data and I agree that there isn't much 
>> difference and it could be better to work with date in some ways eg. 
>> you can really drop whereas with acks it would be harder to simulate a 
>> drop.
> 
> 
> 
> I'm just not sure that he is actually addressing the "lots of small 
> connections" or "overload during slow start" problems that I think are 
> still the main issues to be sorted?
> 
> 
>> Me too - Thomas Graf is also playing with delaying acks - see the 
>> dummy replacing imq thread this & last month on a netdev archive.
>>
>> I also remember seeing another shaper that uses delay pools for acks 
>> bandwidth arbiter or arbitrator IIRC. If you can't find it say, I 
>> probably have it squirreled away somewhere on my old PC.
> 
> 
> 
> Cool, I saw a note about dummy on this list, but didn't read the 
> thread.  Yes please, notes on the other idea would be interesting.

Well I had a look and it seems what I was thinking of has since turned 
into netlimiter. Maybe I was thinking of something else - maybe not, but 
I thought it was to do with a Uni. Here's what I have -

http://www.jessingale.dsl.pipex.com/arb.tar.gz

> I still think that the only sensible answer to this is to literally 
> throttle the initial window advertisement, and perhaps even aggresively 
> manipulate it thereafter.  I'm thinking that you could make some 
> reasonable assumptions perhaps for users on "normal" wan links where 
> latency ranges from 10-15ms up to 330ms.

Yes - but for browsing you'll need to account for how many concurrent 
connections as well, which is going to vary.


   Satellite links are a whole
> new ball game of course (and I have some satellite users...)

I've seen posts from people wanting to remove slowstart totally for 
satellite use.

> 
> I'm thinking that if you could throttle the window back to even the size 
> of the class that the connection "belongs to", then you could control 
> the rest of the link using the normal linux QOS queues.  I currently 
> think the killer is just the spikes in latency which occur as TCP tries 
> to test the window size, or when you have a bunch of connections all 
> doing slow start at the same time (same kind of thing really).  Window 
> control really seems to be the tool to get the link roughly under 
> control and then the queuing should be for the fine grained stuff.
> 
> What do you think?  ...Now how do I code it...?

It's bloody tricky and I haven't got a clue :-)

I think the number of connections within a class is going to matter and 
how to elegantly (predictivly and without resync bursts) change the 
bandwidth of existing classes/connections, also needs sorting.

Anything is going to be better than doing nothing, though.

Andy.

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