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

-----Original Message-----
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

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
  > 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
  > 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"
  > 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:



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 

WISPA Wireless List:



Reply via email to