From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Tue, 15 Feb 2005 22:33:05 +0000 Subject: Re: [LARTC] TCP window based shaping Message-Id: <421278A1.40408@dsl.pipex.com> List-Id: References: <42095013.8030600@wildgooses.com> In-Reply-To: <42095013.8030600@wildgooses.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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/