"What is important to understand is that bandwidth management devices which do not utilize window manipulation at all cannot reduce your network latency on an overall basis. They will simply shift the latency from one type of traffic to another."
They are still talking about egress shaping here - I say - so what if latency gets shifted, as long as you arrange for it to be "shifted" to bulk then it doesn't matter.
Egress shaping is sorted without window manipulation - As long as whatever you define as interactive traffic is < your bandwidth then you can arrange for it never to be delayed by bulk traffic any more than the bitrate X length of bulk packet.
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.
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...
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. 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?
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.
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. Satellite links are a whole new ball game of course (and I have some satellite users...)
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...?
Ed W _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
