i'm just trying to slow the traffic (it's for my master|degree|pedigree thesis, so i don't want to waste all my life on this) without changing the window size.
How do we fit this thing into the linux QOS architecture anyway?
i'm writing a scheduler that just delay the ack rate (it's in a very preliminar state, so nearly nothing was done).
now i'm looking for a place where to put the flow information (in a
conntrack module, maybe?)
Have a look at the BWMGR qos product. They have some interesting thoughts.
They seem to have some strange ones too -
from http://www.etinc.com/bwcompare.htm
"Suppose you have a T1 line and a single server. Suppose that 2 remote clients request the same page simultaneously, and that page has 15,000 bytes of information. With a typical TCP window of 16K, the entire page will be sent without requiring an ACK from the client."
Conviniently forgets that slowstart exists - stopping the above is what it's for isn't it? Then later -
"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.
Basically their idea seems to be that you only need to get the window shaping (or ACK shaping) roughly right. The fine tuning happens just as now with the queue simply filling up a little. Seems to me that this is right, if you just get the window even +/- 50% of the target bandwidth then you can do fine tuning by delaying ACK and buffering data. The trick is basically to avoid the huge splurge of data during slow start which can cause queuing on the ISP end.
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.
Otherwise I am broadly speaking very happy with the default QOS. It's just this queueing which occurs when a bunch of connections all start together which is the problem. This isn't really just a bittorrent issue though because a busy webserver would likely see the same conditions?
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.
Are we all on the same page as to what the problem is? Any more thoughts on how to tackle it? I'm still not convinced that delaying ACK's is really any better than the current option to buffer incoming data.
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 don't think he will be just buffering though - thats the advantage for him - to build in intelligence to handling the problem of shaping from the wrong end of a bottleneck without the handicap of using dumb queues that are seeing traffic that's allready shaped by a fifo and whose fill rate is determined by what percentage of the fifo rate you set their rate.
I still think that dumb queues can be improved for this situation, though -
Making an htb/hfsc class that behaves as full as soon as it sees traffic, so other classes that are sharing get throttled before it's too late.
Making an eesfq - preferably without the s - perturb is horrible really, the packet reordering alone causes resync bursts in tests I've done.
It is also pretty pointless dropping a whole bunch packets from the same window, one per slot with some timed immunity would be nice - they already used the link anyway. That is more like sfred or fred I suppose.
Being able to detect existing connections that go back into slowstart - don't know how to do that as such, but I suspect bittorrent causes this as it cycles through existing connections trying to find better for you.
De piggybacking acks from full duplex bulk traffic - again bittorrent, though you can make the effects of bt using full duplex for bulk a bit better by using shorter egress queues for it.
I guess the receiving machine TCP stack gets it earlier so the
app looks more responsive, but other than the lower lag I don't see much difference really?
Curious to hear how your project gets on though! Please keep us informed!
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.
Andy.
Ed W
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
