Fascinating.  I only spoke of leaky bucket because that's practically a match 
to what Jason originally described to the list (and I happen to know of radios 
that have this algorithm internally programmed -- happens to be Canopy).  But I 
presume there are other algorithms programmed to different manufacturer's 
radios.  Patrick, is it possible to share details of the Alvarion implemented 
4th gen algorithm you spoke of?  Are there other algorithms implemented (either 
internal to wisp radios or head-end devices) that others can share to the list?

Tom spoke of Bit Bucket, but I don't know if this is a different technique from 
Leaky Bucket or just a different name.  To my knowledge, Leaky Bucket specifies 
all 4 parameters uniquely per CPE, so it's hard to imagine undesirable effects 
on business traffic (like all CPE, the parameters associated with business 
customers can be set appropriately for business traffic).  In fact, I know 
numerous wisps that use leaky bucket that use the parameters of the specific 
customer as terms of the customer service agreement.  To make it simple, some 
use the terms bronze, silver, and gold as subscription package names, whereas 
each simply defines a set of the 4 leaky bucket parameters.

Not only is bw management critical IMHO to wisp operators, but also 
interesting.  I'd love to know enough of the different techniques in use to 
contrast them by behavior or application.  Maybe just some URLs whereby I could 
do some studying?

Rich
  ----- Original Message ----- 
  From: Patrick Leary 
  To: WISPA General List 
  Sent: Wednesday, January 24, 2007 3:59 PM
  Subject: RE: [WISPA] Advanced Bandwidth Management


  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/
--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to