On Wed, 2002-10-09 at 20:54, Jason Tackaberry wrote: > Hi everyone, > > I'm using HTB to shape traffic for students in our residences. We're an > extremely small college (about 50 Internet users in our residences) and > we don't have a good deal of bandwidth to work with, so I must do what I > can to make what we do have tolerable to our students. > > I am right now using the following approach: I have allotted a portion > of our total bandwidth (R) to the residence subnet on the upstream > interface on our router. This class is sub-divided into two classes: a > p2p class for all those pesky file sharing programs, which has a ceiling > of about R/2, and an "everything else" class, which has a guaranteed > rate of R/2, and a ceililng of R. I have put SYN and ACK packets in a > separate class (under root) to improve responsiveness. > > In theory, this scheme works pretty good. The problem is that every day > some of these p2p programs are using different ports, and they manage to > suck up all available downstream bandwidth. So, the student who wants > to send their friend a file over ICQ is going to get starved by every > other student running Kazaa-du-jour. > > Now it would be _really_ nice if there was some ability to examine > packets at layer 7 to determine what class a particular session belongs > in (like, for instance, the way Packeteer's Packet Shaper works). I'm > assuming I can't get this functionality (unless I write it myself), so > can someone suggest a remedy to my problem? Is there some magic > adjustment I can make? Or, perhaps I should try a different approach, > and give each IP a guaranteed rate? The only drawback I see with this > is that with 50 users, I could only guarantee each user 5kbps. :) > > Any guidance would be appreciated. > Jason, It sounds like your using a black list to get you moved into the "P2P" bandwidth.... Why not turn it around and review /etc/services and say: http,smtp,pop3,imap,news,https,rsync,icq,irc,ssh and other services get into the white list of "Non-P2P" bandwidth. It's much easier to qualify the things you like, instead of the things you don't like in this case. I'd also shift the percentage to 75/25 whitelist/blacklist. Now if anybody abuses this, by trying to run P2P over a well-known port, there are ways of solving that too. First just bandwidth limit them into you get 2.5K unless there is bandwidth to spare.... Another idea, is keep stats on "abused ports". Any source or dest port that consumes more then X% of the total bandwidth gets put onto the blacklist ports. Script the whole stats, and adding removing ports from the list. Possibly just keep port 80 on the it's okay post list it will always exceed X% for reasonable values of X. There's also a certain amout of fairness in just splitting the bandwidth guaranteed evenly. It's about as fair as you can be. An interesting thing could be split the bandwith cap inversely proportional to usage. So for someone who rarely uses the network connection, they have a higher hard cap then someone who uses it constantly. Just order everyones network usage, give the first 5% guaranteed access to 30% of the bandwidth. Give the next 60% guaranteed access to 60%, give the last 20% access to 10% of the bandwidth as a guaranteed limit. So when everyone is on, the people who generally don't use it much get on an abundance of bandwidth during the few times they want it. Maybe do that with 80% of the bandwidth, leave the other 20% uncontrolled for anyone to use at any rate they can get it at just so there is burstable bandwidth available to anybody when they need it. The people who use more then their fair share most of the day, can wait while the people who generally don't take their portion are attempting to use it. This is even more fair then picking "bad" services. It doesn't make any difference if I'm consuming all the bandwidth downloading web pages to build the next google index, or if I'm consuming all the bandwidth using Kazaa. I'm still using too much of the shared resource. What I'm using it on is relatively irrelavent. Me using it for anything keeps someone else from using it productively. Keep the stats and re-categorize the users say every 6/12/24 hours. Maybe do it just once a week. You might have to shuffle the percentages, and user count a bit, but it should work to give people a fair chance at using up their portion of the bandwidth when they need it. Yeah it's a fair amount of scripting, but should be relatively stable setup once you are done with it. Thanks, Kirby > Best, > Jason. > > -- > Jason Tackaberry :: tack@auc.ca :: 705-949-2301 x330 > Academic Computing Support Specialist > Information Technology Services > Algoma University College :: www.auc.ca > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > -- Real Programmers view electronic multimedia files with a hex editor. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
