Subject: [Mipshop] "scan" and "join" in 802fh draft

From: Rajeev Koodli <[email-masked]>
Date: Mon, 16 Feb 2004 15:12:56 -0800

Hi Pete,

the sense I get from the draft is that you
tacitly assume that a scan has to be tightly coupled with
every handover. I would like to understand
this better. Scan and join are two separate
operations, and although combining them sequentially
yields a handover, you don't necessarily
have to do it that way. For instance, I could run
fmipv6 interspersed with scan and join the following way.

- upon interface up, do scan, perhaps for known
   SSIDs. Result is a set [AP1, AP2, AP3]
- join an AP1
- Do ND
- Do RtSolPr, PrRtAdv for AP2, AP3
- run VoIP
- send FBU using a host or network
   trigger
- join AP3
- send FNA

Isn't this realistic ?
I don't see any reliability concern regarding
RtSolPr and PrRtAdv messages. Also, aren't
scan and join exported, even to the end user ?
(On a Centrino, you can "scan", and then "connect"
to a specific AP.) So, could you clarify the
skepticism about the scan primitive being available in

"Note that in this scenario, the scan request primitive is made
   available to the host and the firmware in the 802.11 device does not
   autonomously make handover decisions. " ?

This statement also combines scan with a join.

Regards,

-Rajeev

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Sung Hyuck Lee" <[email-masked]>
Date: Wed, 18 Feb 2004 17:22:01 +0900

Dear all, 

 IETF Seoul meeting is coming  ...
 However, If you did not make any reservation for accommodation yet, 
 please let me know. I can help the folks who have not found an 
 appropriate hotel. 

 p.s. This mail is not ad.

Thanks & Regards,

Sung-Hyuck Lee
----------------------------------------------
NPTG, i-Networking Lab.
Samsung Advanced Institute of Technology (SAIT)

Tel: +82-31-280-9585
Fax: +82-31-280-9569
Cellular: +82-11-9039-2615
e-mail: [email-masked]
----------------------------------------------

 ��!����X��X��ȩ�)��_��!��l��0�X���+����Y���b�ا~�抛!�

---

From: Pete McCann <[email-masked]>
Date: Thu, 19 Feb 2004 09:49:45 -0600

Hi, Rajeev,

> have to do it that way.

I agree, but the ability to separate them depends on the
hardware/firmware in use, right?

> For instance, I could run

Perhaps, but I think that you would want to do a scan somewhere after
"run VoIP" and before "send FBU", so that you know that you still have
good radio connectivity to AP3, right?

> RtSolPr and PrRtAdv messages.

I agree these should probably be done in advance, not at critical
handover times.  That would give you the chance to retransmit them as
needed.  However, if radio conditions are changing rapidly, you might
not have the opportunity to learn about all the neighboring APs before
a handoff becomes necessary.

> Also, aren't
> to a specific AP.)

I think it's true that most chipsets give you some sort of scan
primitive, but I think that the "connect" operation is usually
prefaced by a firmware-layer scan to make sure the AP is still there.

> So, could you clarify the

This reflects my understanding of the way most chipsets operate, in
that they implement periodic scanning (in firmware) and execute
handoffs autonomously to other APs in the same ESS.  Even if there are
exceptions that allow the host more control, the statement itself as
written is a true one.

Perhaps we should attempt a more systematic examination of different
chipsets (I for one don't have access to enough documentation).
Perhaps based on your implementation experience, you can point us to
explicit documentation on the chipset you used, and what primitives
you had to invoke to execute the handoff under host control?

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 10:27:37 -0800

> good radio connectivity to AP3, right?

You may or you may not. It depends on the card configuration. Even if you
did scan this way, it is not a handover issue since you already have done
RtSolPr for AP3. So, there is no reliability concern as it is expressed in
your
draft.

> handover times.  That would give you the chance to retransmit them as

I think the draft should state this.

> a handoff becomes necessary.

This accurate yet very broad statement needs some qualification.
Are you saying that after the initial discovery, the current link can
become so poor that handover is necessary ? If so, why scan at that time ?
Try joining one of the previously scanned APs for which you already have
subnet information. Only when join fails, try a scan again.
Note that after the initial discovery, if a periodic scan yields AP(s) not
in the current set, the MS may do RtSoLPr/PrRtAdv, but this is not
at handover time.

> prefaced by a firmware-layer scan to make sure the AP is still there.

Could be. However, I do not see the same delay in connect that
I see in scan (on my IBM laptop, mere observation).

On a Nokia C110, a "join" primitive is available, and its
latency is under 100 ms in our tests. Average is better than
100 ms.

> exceptions that allow the host more control, the statement itself as

You agreed above that scan is made available to hosts.
So, that can be made explicit.
The host can always make autonomous decisions, and that's
why we have reactive handover. The key issue is whether the MS
has been able to obtain subnet information. The way the text
is worded above, it looks like every time there is a scan, there
will be a handover such that there is no time for obtaining any
subnet-specific information.
A more balanced view-point is necessary.

> you had to invoke to execute the handoff under host control?

As I said above, we have tested on Nokia C110. I don't have whole
lot of documentation either; just the running code! Note that even if
some cards prefaced a join with scan just to make sure the AP exists,
that has limited bearing on the fmipv6 protocol when the AP in question
has already been resolved (via RtSolPr/PrRtAdv). Of course, a
scan-prefaced-join could produce more delay. Again, the draft currently
is not clear enough to make this distinction.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Thu, 19 Feb 2004 14:41:25 -0800

Hi Rajeev and Pete,

Interesting discussion.

> I think the draft should state this.

Actually, I believe in .11 traffic gets shut down during the scan because
there is no control channel, so by default most cards don't scan except at
handover time. The discovered APs and their channels which were not selected
for handover could of course be used when the mobile station is on the new
AP to obtain information about mapping between AP and AR addresses for
possible future handovers via the PrRtXXX messages, but there is no
guarantee that one of those APs will be selected during the next handover,
since a future handover scan might discover an AP that was much better but
not visible on the previous access point. Of course, it would be possible
for the card to scan in advance of the handover, and most cards have
driver-visible commands to force this, but it would shut traffic out for
whatever amount of time a complete scan takes, usually anywhere from 70 to
200 ms.

The APs also have periodic beacons. I'm not sure what an actively
transmitting mobile station does with these. The only thing I've heard them
used for is when a mobile station first boots up, and for dormant mode
support.

Note that all these considerations *only* apply to infrastructure mode (I
hope the draft makes this clear, I haven't had time to read it yet). If you
run the mobile stations in ad hoc mode, and designate one an "access point"
by virtue of some Layer 3 identification, you can use the PrRtXXX messages
just fine opportunistically without running into the problem of scan delay.
The EU MobyDick project implemented FMIP in this way.

> in the current set, the MS may do RtSoLPr/PrRtAdv, but this is not

I interpreted this to mean that the mobile station might run out of range of
the current AP before having an opportunity to actually find another AP. But
I agree that, as a fallback position, the mobile station could try joining
another AP that it discovered on a previous scan.

> latency is under 100 ms in our tests. Average is better than

Yes, the connect is usually fast (actually, its a Reassociation.Request()
followed by a Reassociation.Reply() command for most cards, but YMMV). If
you don't need to use .11i to reauthenticate. If you do, it could take up to
seconds.

> A more balanced view-point is necessary.

Well, typically that would be so. Most cards run the scan/join together in
firmware and don't allow them to be interrupted. At least that was the case
a year ago when I looked into this. As I mentioned, it would be possible to
do the scan independently of the join, but then it would shut down traffic.

In our implementation of FMIP, we were not able to find a card that allowed
the scan/join to be split on an infrastructure mode handover. We tried for
quite some time.

> is not clear enough to make this distinction.

I think we ought to talk to someone from 802.11 about this. I think Bob
O'Hara will be in Seoul, and also Dave Johnston, from Intel. Bob has been
involved with 802.11 since its inception, and Dave is the chair of the 802
Handoff ESG (soon to be 802.21). I don't know Dave's involvement with
802.11, but he could give a broader 802 perspective. In fact, I would go so
far as to say we ought to ask someone heavily involved in 802.11 like Bob to
be a co-author.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 16:45:41 -0800

Hi Jim,

agree that a scan could affect traffic if there is any. This will
happen at any time, not just at handover time. So, the suggestion
is to do scan upon interface up, and resolve discovered APs to
corresponding subnet information. This could follow router discovery,
and presumably there is no data traffic yet.
Subsequently, traffic can ensue, and that traffic could be
affected by a card doing scan. (the actual impact depends a lot on application
traffic pattern, CSMA/CA) Scanning pattern of a card is a policy
issue and should be identified as such, default being periodic scanning.
If the scan produces a new AP not in the current set, new RtSolPr/PrRtAdv
is necessary. However, the MS can also simply handover to an existing AP it
has scanned previously by doing just a join. (there are only 3 channels
available in
.11b) I am arguing that a more balanced view-point thus be presented.

Regarding some cards unable to separate scan from join: It does not
matter to the protocol operation as long as the AP in question has
been resolved. Of course, there will be more L2 delay. This should also
be clarified.

Regards,

-Rajeev