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

[Jouni Malinen (j]

On Thu, Mar 08, 2007 at 12:56:31PM -0800, Bernard Aboba wrote:

> 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