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

From: "Soliman Hesham" <[email-masked]>
Date: Thu, 19 Feb 2004 19:48:12 -0500

Rajiv, James, 

I'm just responding to one point below so I quoted 
all text.

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

=> I interpret Pete's statement to mean that after 
the early discovery (using Prsol and Pradv) things might
change during the time between this discovery and the actual
handover (it could take minutes or an hour before this happens).
The changes may be temporary (radio link conditions change)
or permanent (an AP goes down). So it is clearly questionable
whether the information learnt earlier is still valid. 
I think this makes sense (if that's what Pete meant anyway!). 

Hesham

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

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 19 Feb 2004 17:18:44 -0800

Hi Hesham,

> I think this makes sense (if that's what Pete meant anyway!).

I am not arguing regarding change in radio and network conditions, just
to be clear.
I am saying when a change of current AP is necessary, a join to a
previously discovered AP is recommended. If a long time has passed,
the MS may have discovered additional APs and resolved them
to potentially new subnet information. If join fails, you would
scan anyway, which BTW may not yield any new APs and hence
the Proxy messages are not needed.
In other words, information becoming stale is also not assured!

-Rajeev

---

From: Pete McCann <[email-masked]>
Date: Sun, 22 Feb 2004 13:27:21 -0600

Hi, Rajeev,

 > In other words, information becoming stale is also not assured!

So I guess you are suggesting a change in the description of
Scenario 1abcdef23456g, and possibly in the text of Section 4, to make
it clear that the 1ab might be widely separated in time from the
cdef23456g?  That seems quite reasonable, but I'd like to understand
how many chipsets actually support this.  That is, I wonder if, even
though the scan (1) may be made available to the host, whether the
join (2) is always implicitly prefaced by a scan in some cards, as
James indicated, even though it may not have been explicitly requested
by the host.

Also, depending on how much time has passed, there may be an
increasing chance that the radio conditions have changed sufficiently
to make the handoff ill-advised; the terminal may even have crossed to
the other side of the AP's coverage area and there might be a whole
new set of APs visible.  This at least needs to be noted when you
separate the scan too far from the join.

-Pete

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Sun, 22 Feb 2004 17:28:09 -0800

> separate the scan too far from the join.
I can give you my experience on 802.11  handoff procedure on one of
the chipsets that i worked on sometime back. The driver does a
background scan periodically updating the AP information. (This can
be easily disabled also which implies that during handoff you have
to do an expensive scan operation.) When it is associated with an AP, it 
does not process any beacons from other APs. The only way it updates the
AP information is by probe request/ probe response sequence. Note that this
can be active probes or passive where you don't send a probe request out
depending on other conditions. Later when there is excessive packet loss or signal
strength below certain value, you try to find a better AP from the list of APs
available. Yes, i agree that this information can stale. But the driver that i worked
on did not refresh the information during the handoff. This just means that your
handoff could potentially fail. Perhaps my test setup was not that good to
catch these errors. The normal handoff is by doing  a join, auth and associate again.
I had also tried reassociate for certain cases. But this did not look that common
for the drivers (though AP may support it) to me from what i was told.

There is some effort by one of the big companies to change this is what i have
heard. They want to expose all the information what the driver has to the above
layer so that the decisions about which AP to join etc. can be made at the layer
above the today's 802.11 driver. I don't have much information about this.

-mohan

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Feb 2004 11:51:04 -0800

> James indicated, even though it may not have been explicitly requested

Let me try again.

It is not so much whether a join is prefaced by scan that is the issue.
(It is an issue in terms of latency, but also see Mohan's e-mail)
It is whether the subnet information corresponding to the AP in
question has been resolved. Consider the following.

The MS maintains a set of APs. The set is
initialized at interface up, and the AP set is resolved to gather
subnet information. Subsequently, both the AP set and the subnet information
is updated depending on if the MS discovers a new AP (based on
scan or by other means). For whatever reason, if the MS handovers
to a new AP, either the new AP is

a)  resolved by fmip, or
b) not resolved by fmip

In both the cases, a join could be prefaced by scan or not. The draft
does not present a balanced view of a) and b), IMO.

> separate the scan too far from the join.

Well, do you have to join after every scan ? You could be happy with
your current AP and still do a scan, right ?
How a MS discovers new APs is a WLAN card policy issue. What we
should state in the draft is that if the MS' AP set changes, it SHOULD
do RtSolPr/PrRtAdv. The draft explicitly states that radio conditions
could be worse enough to fail RtSolPr/PrRtAdv. The draft should also note
that the scan could happen when radio conditions are not so bad! :-)

-Rajeev

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Feb 2004 10:49:50 +1100

Hi Rajeev,

> that the scan could happen when radio conditions are not so bad! :-)

I think that the scanning and probing primitives available in
802.11 are such that in most cases, the decision as to whether
active scanning can be done without undertaking handover is
largely out of the control of the upper layer protocols (it's
often in firmware).

As such, we really need to ensure that FMIPv6 for 802.11 describes
what's actually available from WLAN cards, rather than how we'd
like them to be.  That work (how we'd like it) should go to 802.21
handoff group.

If people are aware of systems which allow active (or passive) scanning
without explicit L2 handover occurring, then let's elaborate on
what's available.  We still need to describe applicability to even
implementations where no pre-scanning is available.

Greg

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 23 Feb 2004 16:26:31 -0800

HI Greg,

> largely out of the control of the upper layer protocols (it's

I am not asking for "nice-to-haves". On my IBM laptop,
I am "connected" to an AP, I can do a scan without losing
my current AP. Of course, the scan could result in a new AP
to which the firmware could handoff. There is also a management
interface which allows to specify rudimentary conditions for
AP association.
And, using Nokia C110 cards, we can do "join" only to issue a
handover. We do this as a result of a "generic trigger", i.e., a
host event, or a network shoulder tap. This happens
independently of the firmware making decisions which can
always happen. In the latter case, what matters is, as I have
pointed out, whether the target AP has been resolved to obtain
the subnet information. When no such information exists, the
MS has to resolve it, and depending on the radio conditions, the
FMIP signaling could fail, or not! I am asking that all these
possibilities be included.

> implementations where no pre-scanning is available.

See above. Also, I think the study by University of Maryland indicates
pre-scanning is a useful thing.

-Rajeev

---

From: "Youn-Hee Han" <[email-masked]>
Date: Tue, 24 Feb 2004 10:36:14 +0900

Hi Rajeev,

> that the scan could happen when radio conditions are not so bad! :-)

One of my concerns is that if passive (or active) scan is done toally 
independent of join procedure, 'reactive' mode of fmipv6 would occur
more than being expected. To the contrary, if MN joins after every scan
, and leaves space betwen scan and join to do RtSolPr/PrRtAdv, fmipv6 
can acquire the advantege of being 'predictive' mode. But, most people 
will don't like 'joins after every scan'. I think that this is one of interesting 
optimization issues.

I basically agree with Rajeev. Actually, I like the Rajeev's word, 
"How a MS discovers new APs is a WLAN card policy issue." 
which is fundamental but important for this discussion. 
In the current status, the 802.11 handover scheme is still not standardized. 
So, I bet there are a few of alternatives and many companies try to 
develop their proprietary solutions. 

- YH

2*l†Šfj)bž	b²Ó"¦Èh¦'~Šà†Ûi³ÿðÃ
bz×è®æj)fjåŠËbú?š*l†Š

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 Feb 2004 12:44:26 +1100

Hi Rajeev,

> possibilities be included.

Indeed.

I'm glad to have a concrete example in this case.

> pre-scanning is a useful thing.

I'm sure it is, especially if it can be kept up-to-date.

Some hosts will attempt to use FMIPv6 even when their
L2 driver supports only a subset of the useful
primitives though.  L3 implementors need to be aware
of the implications in this case.

Greg

---

From: Pete McCann <[email-masked]>
Date: Tue, 24 Feb 2004 13:19:09 -0600

Hi,

 > I'm glad to have a concrete example in this case.

Yes, good data points.  By the way, is there publicly available
device-driver level documentation for these cards?

 > of the implications in this case.

Right, I was trying to make some of the potential limitations clear in
the draft, while still allowing for better implementations when you
have the necessary hooks into the low level.

However, by using words like "in most existing 802.11 implementations"
perhaps the draft makes the sunny-day scenarios look less likely than
they really are.  I'll be happy to make another pass over the draft to
make the language more neutral and discuss the possibility (and
benefits/drawbacks) of separating the scan from the join and
scheduling scans at opportune moments.

-Pete

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 24 Feb 2004 11:40:55 -0800

> scheduling scans at opportune moments.

What's a sunny day in IL is a usual day in CA :-)

Good. I hope this thread has provided good information
for your edit.

I have been meaning to write up a short
document on scan & join and relationship to fmipv6.
I hope to get to it soon.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Feb 2004 23:18:09 -0800

Rajeev,

My quick reading of Pete's draft was that he discussed all these
possibilities. He also indicated what is the most common case, namely that
the scan is typically followed by the join without any room for higher layer
protocols, but he didn't rule that out.

So I guess I don't quite understand what the problem is.

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: <[email-masked]>
Cc: "Pete McCann" <[email-masked]>; "Soliman Hesham"
<[email-masked]>; "James Kempf" <[email-masked]>;
<[email-masked]>
Sent: Monday, February 23, 2004 4:26 PM
Subject: Re: [Mipshop] "scan" and "join" in 802fh draft

---

From: "James Kempf" <[email-masked]>
Date: Tue, 24 Feb 2004 23:16:16 -0800

> implementations where no pre-scanning is available.

Pretty much agree with this, except for 802.11, people should talk to
802.11n. .21 is dealing with interESS handover and link triggers.

Also, we should make sure .16 and .20 (if it ever gets off the ground) allow
predictive handover. I'm told .16 does, but I have not yet verified this for
myself, but I think they have not yet completed the .16 handover design
according to what I hear.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 25 Feb 2004 18:53:21 -0800

> protocols, but he didn't rule that out.

As I have said before, the issue is whether the AP in question has been
resolved before or is there time for resolution after the scan. When the AP
has been resolved before, fmip helps. Also, just as the radio conditions might
be bad for resolving an AP, there could be "better times" when resolution
could succeed. I am saying we should document all these possibilities.
I am even willing to write it up!

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Feb 2004 22:19:47 -0800

> I am even willing to write it up!

Yes, this sounds fine to me. As they say: "please send text".

            jak