Date: Wed, 3 Oct 2001 22:44:52 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Steven" <steven@trance.org>, <freebsd-questions@FreeBSD.ORG> Subject: RE: Fair bandwidth division Message-ID: <006501c14c97$b09964a0$1401a8c0@tedm.placo.com> In-Reply-To: <01100319141400.00382@kyle.offline.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
>-----Original Message----- >From: owner-freebsd-questions@FreeBSD.ORG >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of Steven >Sent: Wednesday, October 03, 2001 11:14 AM >To: freebsd-questions@FreeBSD.ORG >Subject: Fair bandwidth division > > >Hi, > >I have a freebsd 4.1 machine running as a natd router for my home network. >In recent weeks my housemates have started using the file sharing program >kazaa, which downloads its files from several sources at once in an attempt >to saturate as much bandwidth as possible. > >This is a bit of a problem, as I have have found when one person is making a >download with it and using maybe 65k/sec, others in the house (namely me) >get a top speed of maybe 0.5k/sec (from sites which can easily shift at a >much higher speeds). > This is odd as you both should be averaging the same. But, based on your description whats probably happening is that your housemate has a dozen or more connections open to different sites, and your just one connection. >I do not wish to divide up the bandwidth on a permenant >basis - it makes no sense as a lot of the time there may only be one person >using the net connection. you may have to. If you are the owner of the DSL or whatever line then you can't be afraid of being pushy. I would however like to find a way to dynamically >divide the bandwidth "fairly", so that one computer cannot hog all the >bandwidth when others are trying to use the connection too. > There is no way - at least no easy way. FreeBSD is still behind in this area, but even Cisco or other commercial routers that have traffic shaping don't always work as you expect. I've got a fair bit of experience with traffic shaping on Ciscos because we use it for certain customers. For example in our market it's cheaper to deliver a full T1 than a fractional T1, but if the customer isn't willing to pay for a full 1.5MB of bandwidth, then we use shaping. The Cisco shaping allows you to specify a burst amount and so it's very useful for our purposes - because a customer that has, for example, a T1 and is only paying 256K, well the Cisco shaping allows them to burst to the full 1.5Mbt for a few hundred milliseconds. So, Internet apps that are interactive and that have low total amounts of data to be passed, like Telnet, Web and such, are not that affected, while apps like FTP that are pulling large amount of data are definitely restricted. Since it's those apps that affect percieved service to all the rest of the aggregated customers we have, well those are the ones we want to restrict. With FreeBSD you use dummynet for the shaping, but it's more crude than the Cisco variant because you cannot specify a burst rate - with FreeBSD the pipe is the pipe and that's all you get. Thus if you simply slap on a severe pipe restriction it's going to kill interactive response and everyone is going to bitch. But if you don't make the pipe restriction severe, then it won't make a difference. >Is there a way of doing this? Yes and no. Yes because the correct answer is that this isn't a technical problem, it's a human problem caused by abuse of technology, which is easily corrected by fixing the technology. No, because the problem is human and thus your dealing with perceptions, and the rest of the users that are running kazaa have obviously got the perception that kazza is actually downloading things "faster" so they will continue to use it. Let me illustrate it this way. I'll assume your pipe is a typical 640K BITS per second DSL line, ie: 640Kbps For illustrative purposes we will assume infinite bandwidth on the Internet and servers on it unless told otherwise. Now, if a single user initiates a FTP session, then he gets a transfer of 640Kbps. If two users each initiate a single FTP session then they get a xfer rate of 320Kbps If three users each initiate a single FTP session then they get a xfer rate of 213Kbps and so forth. Now, if a single user initiates TWO FTP sessions, then he gets a transfer of 320Kbps FOR EACH SESSION. If he initiates 3 sessions, he gets 213Kbps per session if he initiates 4 he gets 160Kbps and so forth. So, what happens when a single user initiates 8 sessions, and two other users each initiate single sessions? Well, this is a total of 10 sessions, so every session gets 64kbps - but for the first user, he gets 512kbps, or 88% of the total bandwidth! This is why your getting creamed. But, we aren't done with this example yet. Each of the 8 files that user#1 is downloading happens to be a megabyte in size. At the end of downloading all of them, he will have pulled 8MB over the link. But, wait a second. Since all those 8 files are coming in at 64Kbps, that means they are going to take 12% of the TIME that they would normally take to download! Thus, if you look at it, you will see that whether user#1 downloads all 8 files sequentially - one after another - or in parallel - all at once - he is NOT going to get all the files downloaded ANY FASTER if he uses kazaa than if he just uses an FTP client that downloads the files sequentially! So, in summary your kazaa-using housemate isn't getting anything by using kazaa. But, he is definitely causing problems for all of you because of the way he's going about it means he is going to hog all the bandwidth. This is in short the technical problem to solve, and the answer is obvious - stop using kazaa, or make kazaa download all the file sequentially, not in parallel. (maybe there is a setting?) Your big problem though, is the human one. I've learned that it's impossible to change human perception when the person has a perception about some technology that they don't understand. You can give this entire argument to your housemates and explain all the logic - but they simply won't believe it because none of them understand dick about networking. At some level, somehow they have been conned into believing that kazaa is "faster" or "better" than doing it the "old" way, so they are going to use it and damn whatever you say. Your only option is to play hardball. Tell them that if they run kazaa when other people want to use the link (such as in the evening when your all there) then they are going to be disconnected, period. They are welcome to run it when nobody else is on the line, but they have to be reminded that your all sharing this and it's not nice to the others to hog the bandwidth. >I've done a few searches but cannot see >anything obvious. > Well, there's one other thing you should consider about the various limiting schemes. They either work by delaying or prioritizing packets in a output queue of some kind, or they work by throwing away packets. Dummynet does both. Now consider that if you implement a "throwing away packets" sort of limiting scheme, then your going to be throwing away packets that have already traversed your DSL line, and chewed up the bandwidth on it. It's one thing for an ISP like the one I work at to rate-limit, we lose bandwidth too but our feeds are so much bigger that we can afford a small loss to be able to obtain a lever to use to extract more money out of customers. After all, without that additional money we cannot afford to buy bigger feeds to start with. But for a end-node to rate limit INCOMING traffic - well your just screwing yourself because you already cannot afford to lose any of the bandwidth on your link, and once your ISP has put the packet onto the link to you then your hosed anyway, and you might as well deliver it. It's much better for you to not even initiate the connection to the server on the Internet that's sending you the traffic to start with. Ted Mittelstaedt tedm@toybox.placo.com Author of: The FreeBSD Corporate Networker's Guide Book website: http://www.freebsd-corp-net-guide.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006501c14c97$b09964a0$1401a8c0>