eap Mailing List

View Index by: Date - Thread - Author
Re: EAP WG Last Call on Network Discovery and SelectionProblem Document
From: Bernard Aboba (bernard_abobahotmail.com)
Date: Tue, 27 Mar 2007 09:52:30 -0700 (PDT)
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.


From: "Bernard Aboba" <bernard_aboba [at] hotmail.com>
To: j [at] w1.fi
CC: eap [at] frascone.com
Subject: Re: [eap] EAP WG Last Call on Network Discovery and SelectionProblem Document
Date: Sun, 25 Mar 2007 14:56:17 -0700

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.


Results generated by Tiger Technologies using MHonArc.