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).

  ----- 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?


  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:


WISPA Wireless List:



Reply via email to