Date: Sat, 20 Jul 2002 01:46:42 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Rik van Riel <riel@conectiva.com.br>, Matthew Dillon <dillon@apollo.backplane.com>, freebsd-hackers@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Subject: Re: Another go at bandwidth delay product pipeline limiting for TCP Message-ID: <3D392372.B744476C@mindspring.com> References: <Pine.BSF.4.21.0207192357270.92922-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > I once wrote a traffic shaper to allow people sharing a link to be able > to keep interractive responses good while someone else is FTPing > a big file in.. > the theory was that teh line becomes unresponsive because the > majority of teh window is sitting in the send queue on the internet side > of the slow link to the custommer. The answer was to artificially meter > out the acks going back to the ftp bulk data source. > basically instead of queueing incoming data (well you could do that too,) > I queued the outgoing acks and clocked them out by only allowing an ack to > be released and forwarded, when my own 'metered simulation' of the ack > rate had passed the ack in the packet.. It had the desired affect... > With propper tuning you can keep the send queue at the far end of your > slow link to 1 or two packets and interactive sessions (which were > accounted for, but not controlled) became 'interactive' again > despite the existance of the parallel ftp session using most of the > bandwidth. > > Whistle/IBM was going to try for a patent (silly idea I think). > I wonder if they ever did..? As primary author, you would have to sign the filing forms, and then assign it to IBM with another set of forms, since a company is not legally permitted to be named as "inventor". Ask Archie and Paul and Jim what they had to do for the ACL patent (which was granted to them, and assigned to IBM). So if you don't have a patent on it, they don't have a patent on it. 8-). I think the reason this is coming up now is that there was a recent thread on Slashdot where someone was asking for a Windows "traffic shaper" for a DSL line. Let's ignore for the moment that no one has the source code to the Windows TCP stack except Microsoft and there're very few people it has licensed the code to (last time I checked, a Windows source licence was a significant fraction of a billion dollars; there's only one company that has a piecemeal license agreement that lets them get NT source code for a per chunk fee significantly less than licensing the whole thing; last I heard, Microsoft was in negotiations to buy them). In that case, the upstream bandwidth was being limited by a device that lives one or two hops past the customer premesis equipment, and there's really no way you could control it, unless there was a stream protocol involved, and your control mechanism was stateful base on that. The problem was that the outbound ACKs were delayed or dropped, and the incoming asymmertric bandwidth (1.5Mbit diwn, 96Kbit up) was under utilised. In a perfect world, with no dropping, and a fully asymetric transfer (e.g. data in the downchannel, no data in the upchannel, so MTU is 1500 bytes and ACK pakets up were 60 bytes, you are talking fully 2/3rds if the upchannel being needed for *nothing but ACK traffic for downchannel data*. But since you can't distinguish packets, except by length, and the protocols involved were likely not over TCP (RTSP or UDP based streaming), there was no way to favor payload less outbound ACK packets over other traffic. before the outbound queue at the bandwidth delay device saturated and killed your downchannel. Knowing the BWDP, as Matt suggests, lets you calculate the percentage you need to reserve fairly accurately, but really doesn't let you do anything about it, since the buffers you need to control are several hops away. Unfortunately, your approach would not work in this case, or I would have mentioned you as someone to contact about solving the problem. The real problem is that you have to know too much about the data channels involved to be able to do this... unless you *are* the bandwidth limiting device, itself. And that's where the fix needs to go. Basically, the DSL provider in the example case needed to pay more money for their equipment than they did. Even limiting locally to the rate you know you are limited to remotely doesn't really work -- because the throughput, and therefore the ability of the remote end to drain the buffers on the limiter device is dictated by the full path, not just the limiter, so if the limiter was not the "limiting factor" (har! 8-)) for a given link, then you are still going to fill the buffers with packets which are not ACKs for data coming down your faster downchannel. It's a really ugly artificial problem. You have to think that the fact that the upstream is 150% of what it would need to be to keep the downstream fully saturated, IFF the upstream's *only* payload was ACK packets for the downstream, has to be more than simple coincidence. The best "gross hack fix" I could think of for it would be to set the outbound window size to 1 packet. Not very satisfying, for a lot of reasons. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D392372.B744476C>