EXCELLENT post. This is worth framing. Thank you very much for the information and publishing this with us.
Josh Luthman Office: 937-552-2340 Direct: 937-552-2343 1100 Wayne St Suite 1337 Troy, OH 45373 “Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill On Fri, May 7, 2010 at 2:11 AM, Matt Larsen - Lists <li...@manageisp.com> wrote: > Since there has been a lot of discussion about bandwidth caps on this > list recently, I thought that I would share the one that we recently > implemented, along with some details on how we are enforcing it and how > we established the caps. > > Going back to day 1, we have had a 3gig cap on broadband customers with > a $25/gig surcharge for anyone exceeding that amount. When we were using > all StarOS V2, the radius accounting information was keeping fairly > close track of the bandwidth per customer. Fast forward six years, and > that cap was so low as to be a joke -- and we had not been enforcing it. > It was also very difficult to collect accurate accounting data - StarOS > evolved and the radius accounting became useless in version 3, so some > access points were tracking it and others were not. We also have a few > Tranzeo and Mikrotik access points in the system and no good way to > collect the individual subscriber download information from them either. > > After looking at several different options for collecting the bandwidth > traffic information, we decided to use open source tools to develop our > own solution. We installed a switch between our core and edge routers -- > behind the NAT so that it could see all customer's IP addresses -- and > mirrored a port to our new collection server. The collection server is a > Linux box running CentOS 5.2. The linux box is using softflowd-0.98 to > collect the netflows, and flow-tools-v-0.68.5 to look at the data. Daily > reports are mailed out to our techs list to show the customer who are > nearing or over their caps. A customer page was created that shows the > customers how much bandwidth they have used, how much they have left > before charges and what their overage charges are (if any). The customer > page also shows their historical usage trend for the last 12 months -- > starting with April 2010 when we started collecting the information. > Starting on June 1, we will bill overages as a separate charge to the > customers on the 1^st of the month, regardless of their billing > anniversary. > > The process of implementing this was quite interesting. Out of 2000+ > customers, 80 used more than 10 gigs for the month. One customer - a 1 > meg subscriber at the far eastern edge of our network, behind seven > wireless hops and on an 802.11b AP -- downloaded 140gig. Another one, on > the far western side of our network, downloaded 110gig. We called them > and found out that they were watching a ton of online video. We > discovered a county government connection that was around 100gig -- > mostly because someone in the sheriff's department was pounding for > BitTorrent files from 1am to 7am in the morning, and sometimes crashing > their firewall machine because of the traffic. We also discovered that > there was 80-100meg of stateless udp type traffic traversing our routed > network and getting to our core router. Revised firewall rules on the > APs fixed this problem. The majority of the rest of the subs on the list > were either online video watchers, people with virus problems or who had > left filesharing programs running on their computers. > > After reviewing the usage records, we decided on the following cap sizes > for our plans: > > Package Monthly Download Cap > > 384k 10 gigabytes > > 640k 10 gigabytes > > 1 meg 20 gigabytes > > 2 meg 40 gigabytes > > 3 meg 50 gigabytes > > 4 meg 60 gigabytes > > 8 meg 80 gigabytes > > Additional capacity over cap $1 per gigabyte over the cap > > I feel that these caps are more than generous, and should have a minimal > effect on the majority of our customers. With our backbone consumption > per customer increasing, implementing caps of some kind became a > necessity. I am not looking at the caps as a new "profit center" -- they > are a deterrent as much as anything. It will provide an incentive for > customers to upgrade to a faster plan with a higher cap, or take their > download habits to a competitor and chew up someone else's bandwidth. > > This has been an educational experience, and probably one that we should > have gone through a couple of years ago. I would like to thank the > people on the WISPA and Butch Evans' Mikrotik lists for their input > while we were developing this system. > > Matt Larsen > > Vistabeam.com > > > > -------------------------------------------------------------------------------- > WISPA Wants You! Join today! > http://signup.wispa.org/ > -------------------------------------------------------------------------------- > > WISPA Wireless List: wireless@wispa.org > > Subscribe/Unsubscribe: > http://lists.wispa.org/mailman/listinfo/wireless > > Archives: http://lists.wispa.org/pipermail/wireless/ > -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
