As usual Rich, you post material we all learn from. I've not much to add except to say first that most every scaled WISP I know employs some decent packet shaper, if only to more fully understand the nature of the traffic on their network.
That said, Alvarion uses a bandwidth management technique that is 4th gen (for us). Our first gen versions years ago tended to choke when the oversubscription was being hit, due either to overly optimistic assumptions on the part of the WISP or because of some unique event (e.g. 9/11). Our current generation of bandwidth management implements a choreography between the both the infrastructure and clients side and should the network get tapped beyond the oversubscription model, then the system will gracefully degrade the access of all the clients on the network, but do so proportionately to their subscribed tiers so the larger users continue to get bigger pipes compared to those subscribed at lower access levels. Patrick Leary AVP WISP Markets Alvarion, Inc. o: 650.314.2628 c: 760.580.0080 Vonage: 650.641.1243 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Comroe Sent: Wednesday, January 24, 2007 11:50 AM To: WISPA General List Subject: Re: [WISPA] Advanced Bandwidth Management This thread should not hit a nerve, as I think it has. I've read a lot of your stuff, so I know you're a bright guy. You know that while telephone talk-time may not be metered for many phone services that if everyone picked up their phone that the chances of getting a trunk out of your local office would drop to zero. That's just science, not marketing. No matter how your terms of service are sold there's a real engineering metric called erlangs per user, and it's expected value is much-much less than 1. This is traffic engineering, not marketing. It's the real science behind what most wisps describe as "oversubscription". The lower the average erlangs per user the more users a given bandwidth serves. There are actually textbooks and mature classes on the subject going back 40 years (the science was matured long ago by telephone engineering from the Bell System). It's a legitimate concern what to do about users that statistically use x10 fold, x100 fold, or even x1000 fold or more over the average. Unless you're a service provider with a statistically HUGE number of users you cannot afford to let the averages take care of themselves as phone carriers do. Even so, with the typically small number of users per access point, a statistically anomalous user can destroy service to other customers unlucky to share the same channel ... it's something that simply MUST be addressed. What the writer described, I call the leaky bucket algorithm, and there are some wisp manufacturers that actually code this into their radio products (no need to perform it via a head-end traffic shaper). If your deployed radios do not, a head-end traffic shaper can do the same thing. It's referred to as the leaky bucket algorithm because it's has a physical similarity. Imagine a bucket of a given size that has a leak ... through which the user draws water. In an instant, the user cannot draw more water than the bucket currently holds (referred to as burst size). Once the bucket, or burst size, has been drawn, the user cannot draw more than the bucket's refill rate (referred to as sustained rate). Radios with this built-in typically specify a burst size and sustained rate per CPE, for inbound, and for outbound (4 parameters in total). I'm familiar with many wisps that set the burst sizes to 10M (don't know any that set it to 1G as the author hypothesized), and set sustained rates at 256kbps or 384kbps. The interesting thing about the algorithm is that burst size is dimensionless (it's only a size, and not a rate ... the rate is determined by the radio channel and traffic levels), while the sustained rate is a true rate (bits/sec). I appologize for the lecture, but traffic engineering has always been a topic of interest to me going way back. But I have great concerns for the viability of wisps that don't appreciate the issue (unless they only sell business service where throughput per user is sold with SLAs ... engineering to a high erlang per user, or equivalently described as a low oversubscription rate). regards, Rich ----- Original Message ----- From: Matt Liotta To: WISPA General List Sent: Wednesday, January 24, 2007 11:49 AM Subject: Re: [WISPA] Advanced Bandwidth Management Have you thought about selling the customer a pipe that works for any and all traffic at the speed the customer signed up for as opposed to deciding for the customer? -Matt Jason wrote: > List, > > Several times in the last few weeks the topic of bandwidth > management has been discussed, but "I Still Haven't Found What I'm > Lookin' For"... Here's what I'd like to do: > > 1. Each user starts with a big "Internet Pipe". This way casual > surfing and emails, etc. happen nice and snappy. > > 2. If a user downloads a big chunk of data, he needs to be "shaped" > to a lower data rate after a few minutes (I'm thinking 2 or 3 minutes). > > 3. Step 2 repeats over and over several times if the user continues > to download. > > 4. After the user quits hogging the network, his bandwidth is > restored in stages (backwards of 2 and 3). > > I know this, or at least similar things to it, are being done out > there. The HughesNet satellite FAP works something like this (I don't > know the actual values): > > 1. Each user has a "Bit Bucket" that holds 1 Gig of bandwidth. > > 2. The "Bit Bucket is replenished at 128k. > > 3. The speed at which the user can download from his "bit bucket" is > 1meg. > > 4. If the user uses all the bits in his bucket faster than they are > replenished, he eventually gets only 128k. > > Does anyone know how to get something like this going? I am > especially interested in Linux/Ubuntu solutions. > > Jason > > -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/ ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(190). ************************************************************************ ************ ************************************************************************ ************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses(42). ************************************************************************ ************ ************************************************************************************ This footnote confirms that this email message has been scanned by PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses. ************************************************************************************ -- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
