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

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Tue, 30 Aug 2005 11:48:22 -0500

Hi, Theo, 

Please find my inline replies. 

Regards,
Ajoy 

For the simple reason that the L2 trigger denotes detachment. In a 
multi-AP scenario (i.e. not just two APs) what you see BEFORE the 
detachment is NOT guarranteed to be the same AFTER it and more important 
DURING attachment. This is definetely the case for 802.11 and CDMA. In 
fact this is exactly the reason why ping-pongs in GSM/GPRS occur..i.e. 
by making a decision about a BS which appears eventually NOT to be the 
one you settle into; as a result you bounce between cells that cannot 
keep up with the tunnel set up of the FBU signal..

Ajoy-> Theo, I would like to disagree with your notion of l2 trigger. I do not think using link layer detachment as L2 trigger for FMIPv6 handoff initiation is a good idea. If you use this, you will notice lots of ping pong affect at L3 as you are suggesting yourself.  If you use l2 trigger after handoff decision is made, you might still notice fewer ping pongs but most of the ping pongs will be addressed by L2 handoff damping techniques. Anyway I would like to understand what is your solution for ping pong at L3? 
I know in past folks have talked about bicasting.  

>   layer. But someone will have to implement and validate this. 
>> 
> Such very big "SHOULD" is not very compelling evidence to assure us that 
> it will...Would you base your specification/design/product/robustness on 
> a "SHOULD" hypothesis???? I hope not..
> 
> Ajoy-> Detail handoff algorithm is implementation dependent so I am not sure 
> If we can flush these details during IETF mobility discussion. So, let us assume that FMIPv6 is a signaling protocol for handoff execution and go from there. 
> 

No, no and no...details of the handoff algorithm are NOT implementation 
dependent but theoretical performance dependent. I am talking about the 
math here and you say can solve it by implementing the math better...? I 
have never heard that before...A matrix iteration is a matrix iteration, 
the deviations of the SNR are due to FADING and propagation effects, 
even with MIMO..(this is standard textbook theory). How are you going to 
improve this with "implementation"....????  I hope we are not going to 
redefine physics and maths here by MIP management implementation..

Ajoy-> I agree physics is involved here. But you deal with that using combination of following: 
a. Proper network planning 
b. Using damping techniques such as using various thresholds before deciding 
when to trigger handoff etc.  
c. Other L2 techniques 

Theo, I agree with all these but I am not sure if exposing link layer details to L3 is a right solution though. I think we are repeating the same point again and again.

> 
>> >   
>>
>> b. Using signal strength and other policies capabilities in step a, choose appropriate AP that is the potential candidate for L2 handoff.
>>
>>
> More to the point, when you scan channels as you are connected over the 
> existing link and you detect MULTIPLE AP, there is no guarrantee that 
> your AP selection BEFORE the T1 SNR threshold for detachment will 
> coincide with the actual attachment of the MN with a new AP AFTER 
> detachment. This is not just because of SNR, but also a combination of 
> traffic load and an increased call blocking or even DROPPING 
> probability!! So the intelligence you allude to is significant and 
> definetely not tackled by the spec. Abstract intelligence IMO is not 
> specification but brainstorm..
> 
> Ajoy-> Do you think FMIP should specify these details? These are link layer 
> mechanisms and perhaps should be kept out of IETF discussion. However, based 
> upon implementations if we find that proposed scheme does not work 
> for a given link layer then definitely we should try to fix that 
> in abstract manner without going in link layer details. 
> 
> 

Of course not. FMIPv6 need not specify link-layer details explicitly. 

Ajoy-> Ok 

However, when it relies heavily on the performance of these "details" to 
the extent that it can "FAIL" to do a "FAST" handoff, IMO the 
specification must "specify" (i.e. the developer deserves to know) the 
pitfalls, BEFORE the developer decides on the tradeoffs!!! Basically we 
must show WHAT FMIPv6 is dependent on, for the purposes of proving its 
latency claims true.

Ajoy-> I would like to see your proposal before I can comment on this further. 

 In addition, only by admitting where the protocol 
is weak, can we move forward to solve it. Leaving it as a "detail" until 
the vendors hit the wall is wrong, particularly when we can see the 
effect of these details...

Ajoy-> Ok 

t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS

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

---

From: Theodoros Pagtzis <[email-masked]>
Date: Wed, 31 Aug 2005 11:55:31 +0100

Singh Ajoy-ASINGH1 wrote:
> Ajoy-> Theo, I would like to disagree with your notion of l2 trigger. 

I like disagreement, it is the mother of evolution.. (of course within 
bounds as James pointed out to reach at some point in life 
convergence..! :) )

>I do not think using link 
 > layer detachment as L2 trigger for FMIPv6 handoff
 > initiation is a good idea. If you use this, you will notice
> lots of ping pong affect at L3 as you are suggesting yourself.  
> If you use l2 trigger after handoff decision is made, you might still notice 

IMO I do not think so. If you disagree with the particular L2 trigger 
please name the trigger you mean. 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 - doing it too early is guarranteed to disrupt traffic) 
(b) even if sent that FBU may well 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
   (b) increase the no. of ping-pongs which knowningly FMIPv6 is limited
   (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.
   (d) the FBU is sent to the wrong NAR.

> fewer ping pongs but most of the ping pongs will be addressed by L2 handoff damping 
> techniques. Anyway I would like to understand what is your solution for ping pong at L3? 

> when to trigger handoff etc.  

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

> 
> Theo, I agree with all these but I am not sure if exposing link layer details to L3 is a right solution though.
 > I think we are repeating the same point again and again.

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

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 would like to see your proposal before I can comment on this further. 

Well I do not think my proposal affects in any way whether FMIPv6 should 
acknowledge its dependencies/limitations? As James said this is not 
about my proposal it is about getting right FMIPv6. I wanted to 
contributed to that long time ago and for a reason as you may see; that 
was ignored too..

t.