Re: [LARTC] TCP window based shaping
On Fri, Feb 11, 2005 at 06:18:01PM +, Ed Wildgoose wrote: 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. basically, we have smaller queue because we are queueing the small ack, not the big data transfer on the downlink. and delaying ack is the first step to do the delay+advertised window resize that maybe someone (me?) will do in the future. 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! of course! :) -- BOFH excuse #208: Your mail is being routed through Germany ... and they're censoring us. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] TCP window based shaping
On Sat, Feb 12, 2005 at 02:16:09AM +, Andy Furniss wrote: 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. note that drop means 'losing correct data already received'. so when we drop, we need a retransmission, so we are wasting bandwidth. btw, simulate a drop is easy just send two (or three - it depends on the implementation of the tcp stack) duplicate ack that means: we have received out of order packet so please retransmit. 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. yes, that's the idea. 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. thank you for those references. ciao ciao. -- BOFH excuse #270: Someone has messed up the kernel pointers ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] TCP window based shaping
On Fri, Feb 11, 2005 at 02:57:59AM +, Ed Wildgoose wrote: I like the sound of this idea, but I don't follow the details? Certainly it seems to me that you can do most of the work by only looking at outgoing ACK packets. For example with certain assumptions we can simply measure the outgoing ACK rate, assume this is dependent on the amount of data being controlled by our bandwidth throttling, and therefore we get a really good estimate of the effect of our current incoming rate. However, this breaks down if for example the sender was not sending data as fast as possible. we have to estimate the Acknowledge data rate and if the sender is overlimit we can begin to slowdown his traffic. or something similar... Also simply delaying ACK's doesn't seem to be the whole answer because the sender should simply see this as a longer RTT and increase the window size to keep more data in transit. Seems that we need to do a little of both, eg examine outgoing ACK speed, reduce the window to the approx correct size and then our RED/tail drop takes care of the fine tuning hehe, right. and if we are lucky, there will be a router in the internet that will 'taildrop' that traffic for us, so we are not wasting our bandwith. (i didn't tested this algorithm, but in a network simulator (ns) it works). As others have said, it's stuff like Bittorrent which really shows the weaknesses in the current system. I find that even throttling bittorrent to say, half the incoming bandwidth still shows regular increases in latency, no doubt to the effects of the sudden rush of incoming connections. (or slow start effects basically). i'll do a lot of testing on this.. bittorrent will be a pain, i guess. In the BWMGR product (or whatever it is called), I get the impression they do more work on controlling initial windows to try and throttle slow start back some? Seems to me that one could do more work around the time of the initial ACK to get a window size more in keeping with the flow for that tcp class? If we only allocate 10Kb of our connection to that class, and we are connected via some broadband device, then nowhere in the world is more than 350ms away, and hence a window size of 65535 is clearly wayyy to large - lets fix this early? 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?) bye! p.s. sorry for my bad english... -- BOFH excuse #266: All of the packets are empty. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] TCP window based shaping
On Tue, Feb 08, 2005 at 11:49:39PM +, Ed Wildgoose wrote: Does anyone have any pointers on how other people have implemented tcp window adjustment to do bandwidth shaping? Granted the basic idea is to set the window size to be RTT * bandwidth, but a quick squiz at google turns up mostly papers on how to implement this at the sender end with a view to some new magic TCP implementation. I'm really interested in notes on how to implement at the router side, perhaps with a view to writing a new QOS module. Biggest issue I can see right now is an architecture one, ie monitoring the incoming packet rate and then applying that to the outgoing ACK packets. instead of shaping the incoming traffic and estimate rate from the outgoing traffic, you can 'delay' the outgoing ACK, and estimate the rate from the raise of the sequence number. so you just shape on the outgoing queue, without take care of the incoming traffic. note that everything here is patented, so if you must have lawyers, if you want to develop.. :-/ http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2Sect2=HITOFFp=1u=%2Fnetahtml%2Fsearch-bool.htmlr=0f=Sl=50TERM1=packeteerFIELD1=co1=ANDTERM2=FIELD2=d=ptxt -- BOFH excuse #33: pizeo-electric interference ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Re: [LARTC] Weighted packet shaping?
On Tue, Dec 28, 2004 at 07:53:43PM +1030, Mark Williams (MWP) wrote: Ok... Using your script gave the following (from 17:30 onwards): http://www.overclockers.com.au/~mwp/temp/tc-1hour-yours.png Purple is class 23; all other traffic, in this case bittorrent. Blue is class 21; a windows box, in this case an FTP transfer. Shouldnt class 23 still be dropping off further than that? It seems HTB is wanting to share traffic equally among on the classes rather than by priority. You script is pretty much having the same effect as mine :( ok, maybe i'm wrong, but i try to run the same script, and i think that the script have problem setting prio 0 on filters: running: $TC filter add dev $IFNAME parent 1:0 prio 0 protocol ip handle 22 fw flowid 1:20 $TC filter add dev $IFNAME parent 1:0 prio 2 protocol ip handle 21 fw flowid 1:21 gave me: # tc filter list dev eth0 filter parent 1: protocol ip pref 2 fw filter parent 1: protocol ip pref 2 fw handle 0x15 classid 1:21 filter parent 1: protocol ip pref 49152 fw filter parent 1: protocol ip pref 49152 fw handle 0x16 classid 1:20 --^ don't blame me if this is obvious/wrong/stupid. :) 2.6.10, with lastest iproute2 -- BOFH excuse #212: Of course it doesn't work. We've performed a software upgrade. ___ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
