Subject: [eap] EAP WG Last Call on Network Discovery and Selection Problem Document

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 08 Mar 2007 12:56:31 -0800

This is an announcement of EAP WG last call on the "Network Discovery and 
Selection Problem" document, prior to sending the document on to the IESG 
for publication as an Informational RFC.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-06.txt

The EAP WG Last Call will last until March 26, 2007.   Please send comments 
to the EAP WG mailing list ([email-masked]), in the format described on 
the EAP Issue list:

http://www.drizzle.com/~aboba/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: <[email-masked]>
Date: Mon, 12 Mar 2007 13:27:42 +0200

Bernard Aboba wrote:

> This is an announcement of EAP WG last call on the "Network
> Discovery and Selection Problem" document, prior to sending the
> document on to the IESG for publication as an Informational RFC.

As there's a lot of ongoing work related to this topic, we could 
keep revising this forever (and do more WG last calls; I think 
this is already the third one :-). 

However, I read through the document once more, and I think
this is a good enough snapshot as-is, and worth publishing
to achieve the discussions.

In other words: let's ship this one!

Best regards,
Pasi

---

From: Jouni Malinen <[email-masked]>
Date: Sun, 25 Mar 2007 10:34:16 -0700

> http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-06.txt

Looks mostly good. Couple of comments below:

2.  Problem Definition

- "wh ere" -> "where"

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]
- 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)?
- 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?
- 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
- "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"?
- this paper claimed "approximately 4% of capacity is used for
  beacons" for a single IEEE 802.11b AP with "default 100 ms beacon
  interval"
- 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.
- 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 in 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)
- 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.

   "verifying the advertised capabilities within the 4-way handhskae)."

- "handhskae" -> "handshake"

2.2.  Identity selection

   "Typically, the user will choose an identity and corresponding
   credential set based on the network chooses to connect to"

- "network chooses" -> "network he/she chooses"
  or: "network chooses to connect to" -> "selected network"

   "authenticate to, preferrably prior to choosing a point of attachment?"

- "preferrably" -> "preferably"

2.3.1.  The Default Free Zone

   "an Internet host to determine whether it an reach a destination on"

- "it an reach" -> "it can reach"

   "Similarly, when a user provides an NAI to the NAS, the NAS does know
   apriori whether the realm encoded in the NAI is reachable or not; it
   simply forwards the access request to the next hop on the roaming
   relationship path."

- I would assume this was supposed to say "NAS does _not_ know"

3.4.  Scalability

   "number of entries in the realm routing table.  Similarly, "virtual
   AP" approaches introduce additional Beacons in proportion to the
   number of networks being advertised.  Neither approach scales to"

- 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

4.  Conclusions

   "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."

      "However, even with these enhancements it is not feasible to
      advertise more than 50 different networks, and probably less in
      most circumstances."

- 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. 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.

8.2.  Informative References

   [IEEE.802.11k]

- "IEEE IEEE 802.11k, D4.1, July 2006" ->
  "IEEE 802.11k/D7.0, January 2007"
- I would also add "(work in progress)" here since this is a draft and
  has not passed sponsor ballot

   [IEEE.802.11v]

- "IEEE IEEE 802.11v, D0.08, January 2007" ->
  "IEEE 802.11v/D0.09, March 2007"
- I would also add "(work in progress)" here since this is a draft and
  has not even been submitted to working group ballot

A.2.  IEEE 802

      "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."

- 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)
- 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.

-- 
Jouni Malinen                                            PGP id EFC895FA
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 25 Mar 2007 14:56:17 -0700

Thanks for your comments, Jouni.

>- 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.

>   transmit rate and N-byte frames (with a suitable number of N; maybe

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

>   What if the APs are on different channels?

I think so.

>   not know whether they correspond to a normal use case of an IEEE

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.

>   channel" and "32 percent of the channel's capacity"

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

>   beacons" for a single IEEE 802.11b AP with "default 100 ms beacon

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.

>   i.e., 102.4 ms. Anyway, this does not change the numbers much.

Right.

>   (800 bits at 1 Mbps is 800 us, 144 us for preamble, 48 us for PLCP

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

>   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".

>   number of frames) and all networks may not need to be advertised in

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.

>   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

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

>   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..."

>   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.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Mar 2007 09:52:22 -0700

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" <[email-masked]>
>To: [email-masked]
>CC: [email-masked]
>Subject: Re: [eap] EAP WG Last Call on Network Discovery and 
>SelectionProblem Document
>Date: Sun, 25 Mar 2007 14:56:17 -0700
>

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 27 Mar 2007 19:10:54 -0700

> 200 octet beacons would give 30 percent.  So I don't think that the Velayos 

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.