eap Mailing List: Re: EAP WG Last Call on Network Discovery and Selection Problem Document

[Bernard Aboba (bernard_aboba]

Thanks for your comments, Jouni.

> 2.1.  Discovery of the Point of Attachment to the Network
>
>    "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."
>
> - where is that 32% number coming from? I did not find it from [Velayos]

I think this is referring to Figure 2, which shows roughly that percentage 
of capacity
used for a 10 ms Beacon interval.

> - what exactly is "AP's capacity"? Would this be theoretical capacity
>   of a single 802.11b channel with one transmitter using 1 Mbps
>   transmit rate and N-byte frames (with a suitable number of N; maybe
>   100 or so bytes)?

I am assuming that "capacity" here means "channel utilization" but I do not 
see a precise definition in the paper.

> - is it from Figure 2 by assuming that 10 ms Beacon interval in a
>   single AP would be the same as 10 APs using 100 ms interval?
>   What if the APs are on different channels?

I think so.

> - please note that these are simulated results and the exact parameters
>   used in the simulation were not described; based on the results, I do
>   not know whether they correspond to a normal use case of an IEEE
>   802.11b AP

The 802.11 MAC model in ns-2 is suspect, so some verification is required, I 
think.  I don't see any assumptions in the paper, but we're probably talking 
about Beacons transmitted at 1 Mbps, with standard SIFS, DIFS, CWmin, MAC & 
PLCP headers, etc.

> - "32 percent of an 802.11b AP's"?? Which AP? This sentence seems to
>   be talking about 10 APs.. Should this be "10 APs on the same
>   channel" and "32 percent of the channel's capacity"

I think it probably means 32 percent channel utilization with 10 APs.

> - this paper claimed "approximately 4% of capacity is used for
>   beacons" for a single IEEE 802.11b AP with "default 100 ms beacon
>   interval"

Hmm.  Assuming 2252us per Beacon (see below), based on a 100 octet Beacon 
(including MAC headers), I only get around 2% channel utilization.   It's 
difficult to reach 4 percent unless the Beacons are large.

> - to be exact, "100 ms" is not really correct; it should be 100 TU,
>   i.e., 102.4 ms. Anyway, this does not change the numbers much.

Right.

> -  still, this number seems quite high unless the beacon frames are
>   expected to be extremely long here.. as an example, with 100-byte
>   frame at 1 Mbps, I would expect about 1 ms per beacon and with
>   10 APs at 100 TU beacon interval (i.e., ca. 98 frames/sec) even on
>   the same channel would be around 10%, not 32% capacity; and much
>   less if multiple channels are used

>   (800 bits at 1 Mbps is 800 us, 144 us for preamble, 48 us for PLCP
>   header, 10 us for SIFS would be 1002 us; even with number of 20 us
>   slot times added, this does not get close to 32% capacity)

If you add DIFS (50 usec), and CWmin/2 slot times (32/2 * 20usec = 1200 
usec) this adds up to 2252us per Beacon * 98 Beacons/sec = 22.1 percent.  
The only way to get to 32 percent would be to add another 1000 bits to the 
Beacon.

The following paper provides formulas and channel utilization calculations 
for various scenarios:
http://nfo.iet.unipi.it/~anastasi/papers/book_ch03.pdf

> - Do we really need this sentence here in the first place? Could it
>   just be removed? If not, I would suggest that the numbers would be
>   verified and more exact terminology would be used as far as "capacity",
>   use of different channels, and Beacon frame length is concerned.

I'd recommend removing the reference and perhaps adding a discussion of the 
above calculations instead, perhaps referencing the URL above for the 
formulas.  Also I'd use the term "channel utilization" instead of 
"capacity".

> - depending on the "virtual AP" design, there may or may not be
>   additional Beacom frames per network; it is possible that the same
>   frame includes multiple networks (which would increase length, not
>   number of frames) and all networks may not need to be advertised in
>   every Beacon frame

Right -- more scalable schemes are available.  So this argument can only 
show that advertising a Beacon per VAP is not scalable, not that *all* VAP 
schemes are unscalable.

> - I cannot fully agree with these conclusions. Virtual APs can be
>   designed in a way that allows large number of SSIDs to be supported by
>   a single AP device. Sure, there are some scaling issues, but I would
>   claim this can work with much large number than just a dozen virtual
>   APs per channel.

Yes.  The conclusions reached only apply to a particular VAP scheme, and 
using a more scalable scheme, the number will be much larger, probably up to 
hundreds of VAPs.  This needs to be made clear.

> Anyway, I do agree that the currently available
>   mechanism for this are far from ideal and this can be improved. I just
>   don't agree the numbers shown here.

We should only include numbers that we can verify through hand calculation.  
Personally, I don't put much trust in the ns-2 802.11 MAC model :)

> - same comment as above; in addition, I'm not fully following the logic
>   here on how that "approximately 20 virtual APs" follows from 8 virtual
>   APs at 20% bandwidth for Beacons (nor would I agree with the bandwidth
>   use estimate in a normal 802.11b AP use case)

I think we need to state the assumptions clear.  For example, "if 25 percent 
channel utilization is the maximum acceptable, then this is reached with N 
Beacons, assuming..."

> - term "virtual AP" is somewhat confusing, since it can mean multiple
>   things (at least to me).. The draft seems to indicate that it would
>   always mean a separate Beacon frame for each virtual AP, but I do not
>   agree with that. And even with that assumption, I would not fully
>   agree with the presented numbers.

Yes, the document should be more clear how the numbers are derived and what 
conclusions can be drawn from those numbers.  As it stands, the document 
appears somewhat pessimistic about the value of VAP scalability improvements 
when in fact advances here could solve the problem.