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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Wed, 31 Aug 2005 23:30:52 -0500

Hi Theo, 

Please find my inline replies. 

Regards,
Ajoy 

IMO I do not think so. If you disagree with the particular L2 trigger please name the trigger you mean.

Ajoy-> I mean pre-trigger that is used to initiate L3 handoff signaling. 

 Second, even if the 'L2 trigger' you imply arrives after the handoff decision (i.e. decided where to handoff) , then there is no guarrantee that the FBU (a) can be sent (may already have detached - FBU may well doing it too early is guarranteed to disrupt traffic) (b) even if sent that be looking at the wrong AP than the one you have selected.

If you imply that i) first you decide where to handoff (ii) then you send the FBU and (iii) you will land on the right AP (i.e. the one you decided to handoff) I see a lot of worms opening with
(a) this not working for all technologies

Ajoy-> Anyway I am telling this based upon how things are done by cellular network today. Several signaling messages are exchanged once handoff decision is made. However I do agree perhaps it may NOT be good idea to assume that additional signaling messages such as FBU, HI/HACK, DAD can be exchanged during critical path and work reliably for all L2 all the time. That is why I am fine with idea of allowing L3 methods to solve ping pong issue by FMIPv6. I am also ok with choosing bicasting if it is the proper solution. 

(b) increase the no. of ping-pongs which knowingly FMIPv6 is limited

Ajoy-> I do not see how this will increase ping-pong.  I guess you have more 
change of ping-pong if you use pre-trigger (L3 handoff initiation) trigger 
before L2 handoff decision is made. Because in this case MN does not know where to send FBU. Btw, ether way I do see value of adding L3 support to handle ping-pong if that what you thing will make FMIPv6 better. 

(c) the FBU may not be sent at all as detachment may have occured in the first place. There you are only left with the reactive FMIPv6 handoff case that has been argued to be as slow as MIPv6.

Ajoy-> In theory yes, but your handoff algorithm should be smart enough to detect early enough to allow sufficient time for FBU exchange. But it may NOT be doable in all links all the time. 

(d) the FBU is sent to the wrong NAR. 

Ajoy-> I do not see how this will happen. 

well it is physics and MATHS. please take a look at handoff algos. 
The math is what makes the discriminator choose which AP cell to chose. 

Ajoy-> Ok 

The physics only provides the stimuli... If you imply that for FMIPv6 to work we need to have 'proper network planning' then we may want to put that on the dependencies section as well as the effect of damping techniques or other "L2 techniques". 

Ajoy-> I won't insist on this but may not be bad idea to clarify this if required. 

I appreciate that my insistense may be somewhat irritating, but I have been taught to show the problems before I go ahead with any other actions. The community of course is welcome to ignore them..

Ajoy-> Honestly, intention is not to ignore any good idea. I would rather welcome good ideas. 

Well we have exposed the L2 details long time ago by the time we decided that we need L2 triggers. Triggers are event driven, i.e. function oriented..I think that says by itself enough..

Ajoy-> That is at abstract level. Different L2 adopts different mechanisms for handoff so it is really difficult to include all the details even if you want to do so. 

we are repeating the same point again and again in order to depart from the dock of ambiguity particularly now it has reached an RFC form. This has been my intention. Of course the respected MIPSHOP community can choose to leave ambiguity alone and then redisover the problem when we hit the wall..that is also ok with me..

Ajoy-> I do not see any reason to ignore good ideas. We all want a working solution at the end of a day. 

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

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 03 Sep 2005 09:35:42 +0100

Hi Ajoy,

> Ajoy-> I mean pre-trigger that is used to initiate L3 handoff signaling. 

so you mean an L2 SNR threshold that 'pre-triggers' the L3 handoff
initiation signalling sequence. I find difficult to believe an SNR 
threshold as an 'L2-trigger' to initiate the L3 handoff accurately 
without reaching the hard handoff. Why is this?

In order to have such an SNR threshold you would need to go past the 
hysteresis level in your link margin, otherwise you initiate a FALSE 
POSITIVE handoff trigger, i.e. one that appears to behave like an L3 
handoff initiation but is really propagation effect.

Remember there cannot be a counter-claim that we can 'plan' this 
L2-trigger to be 'smart' so as to be sure it is a true handoff WITHOUT 
going past the hysteresis level.

Going past the hysteresis level is a guarranteed L2 handoff and there is 
nothing you can do to stop it at the link layer. That is to say, past 
the hysteresis level brings this pre-trigger notion and the hard handoff 
so close that the distance is infinitesimaly small and thus, one is 
indistinguishable from the other. Remember that setting up a tunnel to 
early is not a good move..

Also the the pre-trigger of the L3 handoff as you described above IS 
prone to ping pongs if the NCoA choice and FBU tunnel setup has been 
made well before the hard handoff. This is because there is NO 
guarrantee that
      1) when you detach you will land on the SNR level at the AP you 
selected. The handoff algo may override you to keep the BER steady..
      2) even if you force the handoff algo to select the AP that maps 
to the selected NCoA you are have at least a 38% chance (for a 3-cell 
overlap) to hit a ping pong. This probability goes higher as soon as the 
  overlap involves MORE candidate APs..

I challenge there ANYBODY who claims to know the FMIPv6 spec so well to 
tell us how FMIPv6 fights that successfully..

> before L2 handoff decision is made. Because in this case MN does not know where to send FBU.  

which is EXACTLY my point on the inherent increase of ping-pongs simply 
by following the "pre-trigger" abstraction and signalling handshake of 
FMIPv6.

many thanks
t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS