Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Sat, 27 Aug 2005 00:13:46 -0500

Hi, Theo, 

Sorry for jumping in the middle of discussion. But I think in your analysis 
you assumed that L2 and L3 handoffs decision are made at two different 
times and is independent of each other. If you tightly couple L2/L3 
handoff detection and execution you should not encounter the issue that 
you are raised. See below an example handoff execution sequence that can be followed:  

   a. Discover information about neighbors using CARD and other link 
      layer mechanism. This is done ahead of handoff initiation. 
   b. Invoke your handoff control algorithm as soon as signal strength of 
    connected link falls below a given threshold say T1. 
   b. Using signal strength and other policies capabilities in step a, choose appropriate AP that is the potential candidate for L2 handoff.
Handoff algorithm should select most appropriate AP at this time. 
   c. Using L2->L3 mapping obtained during step a, get the IP address of Access Router Serving the given AP. If AP is being served by multiple ARs and then you can use L3 capability (e.g. load) to select appropriate AR. 
   c. Initiate L3 handoff (FMIPv6) using the connected link. 
   d. As soon as L3 handoff is complete, force MN to associate with the AP that was selected during step b.   
   e. If signal strength of connected link falls below a given threshold 
      and you are unable to complete proactive signaling then associate with 	the selected AP and follow the reactive handoff scenario. 

If we follow this model then I guess we should not encounter the problem that you raised in your email. So basically your L2 and L3 handoff executions should be tightly controlled.  Does it make sense? 

Regards,
Ajoy 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Theodoros Pagtzis
Sent: Friday, August 26, 2005 6:24 PM
To: James Kempf
Cc: Soliman, Hesham; mipshop; Rajeev Koodli
Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?

James Kempf wrote:
>>>> since it is so sound, please help me with this: I am an FMIPv6 MN 
>>>> and detect two (or more) candidate AR/APs that are all present in 
>>>> the next IP handoff. Could you please tell me where to send the FBU 
>>>> so that the tunnel can be established (bind NCoA to PCoA) 
>>>> ????????????????????
>>>>
>>>
>>> Pick one.
>>
>>
>> Ok, so...how do you pick one since you cannot correlate it with where 
>> you are moving at a single instant..????
>>
>>
> 
> If there is more than one router on the link the MN is moving to, then 
> what does it matter which one it picks? 

ummm IMHO nope. Consider:

  First let us agree that the sending of the FBU is NOT done after 
*activating* (not configuring) the ultimate NCoA, but BEFORE it.

  The sequence is:

                a) acquire AP/AR mappings
                b) configure NCoA(s)
                c) dispatch FBU (i.e. leaving PAR - or in the worst 
"found" NAR)
	       - at *this* point the MN must make a choice and setup a binding 
to the prospective (hopefully accurate) NCoA for forwarding purposes. In 
a multi AP overlap the MN has to choose which one is the correct NCoA. 
Let us say it chose NCoA1.

                - tunnel has been set up and forwarding is active to 
particular (i.e. chosen) NCoA1.

                d) L2 handoff in progress
                e) detect strongest AP
                f) map to correct NCoAi
                      however in a multi AP/AR overlap there is no 
guarrantee that NCoAi = NCoA1 since you are driven by the AP -> NAR 
mapping (NOT the other way around)....

if selection of the BS is done by signal strength (and then we all know 
which address it is going to use), there is no guarrantee that the move 
of the MN will be done towards THAT AP/AR mapping...In fact you can 
choose X AR/AP by signal strength do the FBU towards that NCoA1 and find 
out you are going towards the direction of the NCoA2.

There IMHO exists an unavoidable (what I call) "black hole effect" until 
it is realised at the correct NAR (i.e. too late since packets have been 
lost already).

-- 
theo
Nets & Mobile Systems Group
UCL-CS

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

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

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 27 Aug 2005 11:07:44 +0100

Singh Ajoy-ASINGH1 wrote:
> times and is independent of each other. 

nope! I have not made such assumption. Your suggested (above) rationale 
is at least wrong because anybody in the know, KNOWS that the L3 is 
preceded by L2. So what you say I assumed is IMPOSSIBLE to happen. The 
fact that you

Let me comment inline in your model where necessary

If you tightly couple L2/L3

>     connected link falls below a given threshold say T1. 

Threshold T1 is for detachment NOT for attachment. The fact that you 
detach from one AP bears NO relevance to where you attach!!!! Even 
GPRS/GSM on soft handoff initiation has got transmission over 3 or more 
BSs since they CANNOT decide with certainty the exact next AP candidate 
until the hysterisis margin settles down. Even then there is compelling 
evidence that the Jacobi iteration for the  matrix iterative technique 
to derive the best SNR _LINGERS_ between BSs with FALSE POSITIVES which 
will only settle when there are LARGE deviations in each matrix iteration.

> Handoff algorithm should select most appropriate AP at this time. 

here you do not "choose the appropriate AP" as you conviniently 
described. The SNR algo even with hysteresis margin tells you WHEN to 
start looking for a new BS. However

    1) the search and association occurs AFTER you detach from the 
previous AP NOT BEFORE!!!!
    2) the indication that you have from mobility/routing neighbourhood 
mappings (i.e. AP/AR mapping) BEFORE the detachment in MULTI-AP overlaps 
that are available concurrently, is NOT indicative of which AP you will 
eventually select during L2 handoff period. Both RNC/GPRS and 802.11 do 
exactly this and for GPRS this EXACTLY why their soft handoff does NOT 
have a single EXACT BS candidate for the handoff.

For GSM/GPRS the pilot signals as well as the destined MN data stream in 
soft handoff mode are received SIMULTANEOUSLY until the MN settles into 
the cell CONCRETELY.

For 802.11 we all know that
             a) the MN cannot detect new APs while in active 
transmissions. It must change in monitor/probe mode. I am well aware of 
the efforts about interleaving but they have serious limitations that 
incurs by itself packet loss (which defeats the point) particularly 
during a handoff). Basically they sound nice but under average channel 
load conditions they fail magnificently.

             b) even if it interleaving was in place the temporal 
location of the MN does NOT guarrantee ANYTHING about the accuracy of 
the selection, particularly when MULTIPLE-APs are around. This is 
because advanced detection of APs (i.e. interleaved) and ultimate 
detachment and L2 handoff (i.e. active scan) cannot be guaranteed to 
yield the SAME AP (i.e. the one selected in advance with the one 
ultimately selected during the scan phase).  I am NOT talking about the 
trivial case of a 2-cell ovelap. This is NOT the average case.

>    d. As soon as L3 handoff is complete, force MN to associate with the AP that was selected during step b.

WHAT???????????????  SINCE WHEN has this been happening in the world of 
wireless handoffs. Do first the L3 handoff and then the L2 one ????
This is certainly either an error on your description or a joke..

>       and you are unable to complete proactive signaling then associate with 	the selected AP and follow the reactive handoff scenario. 

well this depend completely on which stage of the proactive signalling 
the SNR went below the threshold. And the reactive handoff scenario is a 
MIPv6, i.e. FMIPV6 will have to go through DAD and a few other delays I 
have found and eventually have the samle handoff latency as MIPv6 (so 
there we can remove the "FAST" qualifier from the handoff.

t.