Re: [LARTC] TCP window based shaping

[Ed Wildgoose <lists@wildgooses.com>]

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