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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
