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

[Bari, Farooq (farooq.bari]

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
farooq.bari [at] att.com
+1 425 580 5526
 
> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com]
> Sent: Tuesday, April 24, 2007 7:08 PM
> To: Bari, Farooq; j [at] w1.fi
> Cc: eap [at] frascone.com
> Subject: RE: [eap] EAP WG Last Call on Network Discovery
andSelectionProblem
> Document
> 
> 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
>