Subject: Re: [eap] EAP WG Last Call on Network Discovery andSelectionProblem Document

From: "Bari, Farooq" <[email-masked]>
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
[email-masked]
+1 425 580 5526

> -----Original Message-----
> From: Jouni Malinen [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2007 7:11 PM
> To: Bernard Aboba
> Cc: [email-masked]
> 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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 24 Apr 2007 19:08:06 -0700

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" <[email-masked]>
>To: "Jouni Malinen" <[email-masked]>,"Bernard Aboba" <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: [eap] EAP WG Last Call on Network Discovery 
>andSelectionProblem Document
>Date: Mon, 23 Apr 2007 17:09:30 -0700
>

---

From: "Bari, Farooq" <[email-masked]>
Date: Wed, 25 Apr 2007 01:01:25 -0700

Yes I forgot to include the typos and reference updates indicated by
Jouni. They seem a straightforward fix in the update to the draft.

BR,

Farooq Bari
[email-masked]
+1 425 580 5526
 
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2007 7:08 PM
> To: Bari, Farooq; [email-masked]
> Cc: [email-masked]
andSelectionProblem

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 25 Apr 2007 07:06:05 -0700

Found some typos and some additional material that needs to change:

Change:

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 next lowest supported rate.  As a result, "virtual AP"
    mechanisms that require a separate Beacon for each "virtual AP"
    do not scale well.

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
    (CWmin/2 * SlotTime = 32/2 * 20 us)  implies that a single
    Beacon will utilize an 802.11b channel for 1932us.

In Section 4, change:

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

   o  Studies such as [MACScale] and [Velayos], as well as the calculations
      described in Section 2.1 demonstrate that the
      IEEE 802.11 Beacon/Probe Response mechanism has substantial
      scaling issues in situations where a new Beacon is used for each
      "virtual AP".  As a result a single channel is in practice limited to 
less
      than twenty Beacon announcements with IEEE 802.11b.

In Appendix A, delete:

BTW, I noticed a few other typos:

In Section 4, change:

   o  Work is underway in IEEE 802.1, IEEE 802.21 and the IEEE 802.11u
      to provide enhanced discovery functionality.  Similarly, IEEE
      802.1af has discussed addition of network functionality to IEEE
      802.1X. However, neither IEEE 802.1ab nor IEEE 802.1af is likely
      to support fragmentation of advertisement frames, so that the
      amount of data that can be transported will be limited.

To:

   o  Work is underway in IEEE 802.1, IEEE 802.21 and the IEEE 802.11u
      to provide enhanced discovery functionality.  Similarly, IEEE
      802.1af has discussed addition of network discovery functionality to 
IEEE
      802.1X. However, neither IEEE 802.1ab nor IEEE 802.1af is likely
      to support fragmentation of network advertisement frames, so that the
      amount of data that can be transported will be limited.