eap Mailing List: Re: EAP WG Last Call on Network Discovery andSelectionProblem Document

[Bernard Aboba (bernard_aboba]

I think a few more changes are required to address all of Jouni's comments:
http://lists.frascone.com/pipermail/eap/msg04701.html

1. There are a number of typos that need to be fixed, reference updates, 
etc.

2.  Change:

  As noted in [Velayos], the IEEE 802.11 Beacon mechanism does not
  scale well; with a Beacon interval of 100ms, and 10 APs in the
  vicinity, approximately 32 percent of an 802.11b AP's capacity is
  used for beacon transmission.

To:
  The 802.11 Beacon is sent only at a rate within the basic rate
  set, which typically consists of the lowest supported rate, or
  perhaps the lowest supported rate.  As a result, "virtual AP"
  mechanisms that require a separate Beacon for each "virtual AP"
  do not scale well.

  For example, with a Beacon interval of 100 Time Units (TUs) or
  102.4 ms (9.8 Beacons/second), twenty 802.11b "virtual APs"
  each announcing their own Beacon of 170 octets would result
  in a channel utilization of 37.9 percent.   The calculation can be
  verified as follows:

1. A single 170 octet Beacon sent at 1 Mbps will utilize the channel
  for 1360us (1360 bits @1Mbps)

2. Adding 144us for the Physical Layer Convergence Procedure (PLCP)
   long preamble (144 bits @1Mbps), 48us for the PLCP header
  (48 bits @1 Mbps),  10us for the Short  Interframe Space (SIFS),
  50us for the Distributed Interframe Space (DIFS), and 320us for the
  average minimum Contention Window without backoff
  (CWmin/2 * aSlotTime = 32/2 * 20 us)  implies that a single
   Beacon will utilize an 802.11b channel for 1932us;

3.  Multiply the channel time per Beacon by 196 Beacons/second, and we
   obtain a channel utilization of 378672us/second = 37.9 percent.

In Appendix A, delete:

     The simulations presented in [Velayos] appear to confirm this
     conclusion; with a Beacon interval of 100 ms, once more than 8
     virtual APs are supported on a single channel, more than 20% of
     bandwidth is used for Beacons alone.  This would indicate a limit
     of approximately 20 virtual APs per physical AP.

> From: "Bari, Farooq" <farooq.bari [at] cingular.com>
> To: "Jouni Malinen" <j [at] w1.fi>,"Bernard Aboba" <bernard_aboba [at] hotmail.com>
> CC: <eap [at] frascone.com>
> Subject: RE: [eap] EAP WG Last Call on Network Discovery 
> andSelectionProblem Document
> Date: Mon, 23 Apr 2007 17:09:30 -0700
>
> Based on the email exchanges between Jouni and Bernard I propose the
> following resolution to the issues raised by Jouni
> --
> Jouni's concern about the calculations can be addressed by presenting
> them in the draft as standalone calculations without referring to
> Velayo's paper. Bernard had done these independent calculations in his
> response which to my understanding Jouni did not seem to have a problem
> if they were not referring to Velayos paper.
>
> --
>
> Jouni had some concern on scalability section  which can be addressed by
> changing
>
> "Similarly, "virtual AP" approaches introduce additional Beacons in
> proportion to the number of networks being advertised.  Neither approach
> scales to...".
>
> To
>
> "Similarly, approaches that utilize separate Beacons for each "virtual
> AP"  introduce additional Beacons in proportion to the number of
> networks being advertised.  Neither approach scales to..."
>
> --
> Jouni comments on conclusion section can be addressed by following steps
>
> Adding some explanatory text about Virtual APs
>
> Hidden SSIDs.  Here Beacons are not sent for SSIDs defined as "hidden";
> instead, stations are configured to send a Probe Request for each
> "hidden  SSID".   As a result, Beacon traffic does not grow with
> addition of new "hidden virtual APs".  Instead Probe Request traffic
> increases with the number of users configured to probe for "hidden
> SSIDs" and the number of "hidden SSIDs" they are configured to probe
> for.   In some cases disclosure of station interest in a "hidden SSID"
> may be considered a privacy risk, and additional latency may be
> introduced where a substantial number of hidden SSIDs needs to be
> probed.
>
> Multiple SSIDs per Beacon.  In this approach, multiple SSIDs can be
> advertised within a single Beacon or Probe Response. This approach
> improves Beacon scaling as compared with advertisement of a single SSID
> per Beacon, and also may reduce Probe Request traffic, so that it can
> complement the "hidden SSID" approach.
>
>
> By changing
>
> "Studies such as [MACScale] and [Velayos], demonstrate that the IEEE
> 802.11 Beacon/Probe Response mechanism has substantial scaling issues,
> and as a result a single physical access point is in practice limited to
> less than a dozen virtual APs on each channel with IEEE 802.11b."
>
> to
>
> "Studies such as [MACScale] and [Velayos], demonstrate that with the
> utilization of a separate Beacon for each "virtual AP", the IEEE 802.11
> Beacon/Probe Response mechanism has substantial scaling issues, and as a
> result a single physical access point is in practice limited to less
> than a dozen virtual APs on each channel with IEEE 802.11b."
>
> By changing
>
> "However, even with these enhancements it is not feasible to advertise
> more than 50 different networks, and probably less in most
> circumstances"
>
> To
>
> "However, even with these enhancements, when a separate Beacon is
> utilized for each "virtual AP", it is not feasible to advertise more
> than 50 different networks, and probably less in most circumstances.
> These limitations however do not exist with alternative "virtual AP"
> approaches now in development."
>
> BR,
>
> Farooq Bari
> farooq.bari [at] att.com
> +1 425 580 5526
>
>
> > -----Original Message-----
> > From: Jouni Malinen [mailto:j [at] w1.fi]
> > Sent: Tuesday, March 27, 2007 7:11 PM
> > To: Bernard Aboba
> > Cc: eap [at] frascone.com
> > Subject: Re: [eap] EAP WG Last Call on Network Discovery
> andSelectionProblem
> > Document
> >
> > On Tue, Mar 27, 2007 at 09:52:22AM -0700, Bernard Aboba wrote:
> > > BTW, I did some traces, and 170 octet Beacons are actually quite
> common
> > > (Apple Airport Extreme has Beacons of this size, for example).
> > >
> > > If you add up 1360 bits at 1 Mbps (1360us), 144 us for preamble, 48
> us for
> > > PLCP, 10 us for
> > > SIFS, 50 ms for DIFS, and 1200 usec for CWmin/2 slot times, and
> multiple by
> > > 98 Beacons/sec, you get 27.6 percent.
> > >
> > > 200 octet beacons would give 30 percent.  So I don't think that the
> Velayos
> > > paper is that far off.
> >
> > Sure, it is possible that beacons are longer. Though, I would assume
> > that this would be more likely with 802.11g/a APs while the paper was
> > talking about 802.11b which is unlikely to include many of the new IEs
> > in beacon frames. Anyway, if the question is on how many "modern APs"
> > one can have on a single channel, this kind of channel time usage may
> > indeed be getting more likely since I would expect most 802.11g APs to
> > continue beaconing at 1 Mbps rate.
> >
> > --
> > Jouni Malinen                                            PGP id
> EFC895FA
> > _________________________________________________________________
> > To unsubscribe or modify your subscription options, please visit:
> > http://lists.frascone.com/mailman/listinfo/eap
> >
> > Arhives: http://lists.frascone.com/pipermail/eap