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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Sat, 27 Aug 2005 01:37:32 -0500

My apologies for jumping in the discussion. The scenario under discussion here, with multiple AR-AR pairs present is a case where unambiguous L2 triggers are not available (otherwise, the MN would exactly know where it is about to handoff). Isn't the reactive handoff case meant to handle such cases? 

Vidya

> -----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:23:59 +0100

Hi Vidya,

> My apologies for jumping in the discussion. The scenario under discussion here, with multiple AR-AR pairs present is a case where unambiguous L2 triggers are not available (otherwise, the MN would…

Well maybe if you consider that you set up the WRONG PCoA/NCoA tunnel so 
your packet forwarding went south. There you will unavoidably have to do 
the whole thing reactively. But what is the reactive case? A MIPv6 case 
with late forwarding (to save ourselved from the BU latency) and 
stateful (i.e. DHCP of some funky fast sort - not the one we have 
currently). Since the DHCP is pretty slow currently I am yet to be 
convinced that currently FMIPv6 reactive will not yield a handoff that 
is in fact SLOWER than the plain MIPv6 one. Basically on the reactive 
FMIPv6 handoff, we are going to have to focus ONLY on the DHCP latency 
optimisation. I have currently a number of doubts whether DHCP can be 
optimised for this purpose successfully (and realistically).

Also IF FMIPv6 MUST have FAST DHCPv6 to do a reactive handoff it is NOT 
anymore FMIPV6 BUT  FMIPv6+FAST DHCPv6. Remember when comparing MIPv6 we 
are comparing it MIPv6 vanilla, not MIPv6+CARD+FAST DHCPv6+the kitchen 
sink.. And this is the killer winner of MIPv6 which we have to work 
against while reducing SIGNIFICANTLY latency (if we want to produce a 
spec that does make a difference). Basically what I am saying here is 
that we also have to value the complexity of the protocol too against 
the latency performance optimisation instead of digging cases which will 
add more protos and make the FMIPv6 operation as big as the IPv6 spec 
SUITE!!!

Divide and conquer is good but the division is going to give us a 
serious management problem..

t.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Aug 2005 10:19:18 -0700

> the whole thing reactively.

Reactive handover happens exactly after the link layer handover to the new 
AP is complete. Isn't this what you were saying in your previous email?

>But what is the reactive case? A MIPv6 case with late forwarding (to save 
>ourselved from the BU latency) and stateful (i.e. DHCP of some funky fast 
>sort - not the one we have currently). Since the DHCP is pretty slow 
>currently I am yet to be convinced that currently FMIPv6 reactive will not 
>yield a handoff that is in fact SLOWER than the plain MIPv6 one. Basically 
>on the reactive FMIPv6 handoff, we are going to have to focus ONLY on the 
>DHCP latency optimisation. I have currently a number of doubts whether DHCP 
>can be optimised for this purpose successfully (and realistically).
>

Don't have to use DHCP, oDAD would work as well.

> against while reducing SIGNIFICANTLY latency (if we want to produce a spec 
> that does make a difference). Basically what I am saying here is that we 
> also have to value the complexity of the protocol too against the latency 
> performance optimisation instead of digging cases which will add more 
> protos and make the FMIPv6 operation as big as the IPv6 spec SUITE!!!
>

I don't agree with this. That's like saying that MIP6 is bad because it is 
MIP6 + ND + IPsec. Protocol reuse is your friend. There's no need to 
reinvent the wheel all the time.

            jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Mon, 29 Aug 2005 18:46:34 +0100

James Kempf wrote:
>> Well maybe if you consider that you set up the WRONG PCoA/NCoA tunnel 
>> so your packet forwarding went south. There you will unavoidably have 
>> to do the whole thing reactively.
> 
> 
> Reactive handover happens exactly after the link layer handover to the 
> new AP is complete. Isn't this what you were saying in your previous email?

yes, but a reactive handover can well happen when the FBU is sent on the 
PAR link set the wrong tunnel and then had to do the whole thing again 
(i.e. the reactive handoff itself)..

> 
>> But what is the reactive case? A MIPv6 case with late forwarding (to 
>> save ourselved from the BU latency) and stateful (i.e. DHCP of some 
>> funky fast sort - not the one we have currently). Since the DHCP is 
>> pretty slow currently I am yet to be convinced that currently FMIPv6 
>> reactive will not yield a handoff that is in fact SLOWER than the 
>> plain MIPv6 one. Basically on the reactive FMIPv6 handoff, we are 
>> going to have to focus ONLY on the DHCP latency optimisation. I have 
>> currently a number of doubts whether DHCP can be optimised for this 
>> purpose successfully (and realistically).
>>
> 

I have some questions on oDAD that I need to float to Greg..
> 
>>
>> Also IF FMIPv6 MUST have FAST DHCPv6 to do a reactive handoff it is 
>> NOT anymore FMIPV6 BUT  FMIPv6+FAST DHCPv6. Remember when comparing 
>> MIPv6 we are comparing it MIPv6 vanilla, not MIPv6+CARD+FAST 
>> DHCPv6+the kitchen sink.. And this is the killer winner of MIPv6 which 
>> we have to work against while reducing SIGNIFICANTLY latency (if we 
>> want to produce a spec that does make a difference). Basically what I 
>> am saying here is that we also have to value the complexity of the 
>> protocol too against the latency performance optimisation instead of 
>> digging cases which will add more protos and make the FMIPv6 operation 
>> as big as the IPv6 spec SUITE!!!
>>
> 
> I don't agree with this. That's like saying that MIP6 is bad because it 
> is MIP6 + ND + IPsec. Protocol reuse is your friend. There's no need to 

respectfully no.. FMIPv6 claims fast handoff. However it needs
'FMIPv6 + X + Y' to achieve the "FAST" handoff claim. As a result FMIPv6 
by itself is insufficient to achieve a fast handoff since X and Y are 
required.

On the contrary, the sum you mentioned 'MIPv6 + ND + IPsec' (where ND is 
in fact a core requirement for IPv6 to exist and thus is superfluous), 
the 'associated' qualifying claim is "SECURE MIPv6". But MIPv6 by itself 
*never* claimed to do IP security. Hence, the derivation that 'MIPv6 is 
bad...' is (a) inspecific (b) unsubstantiated with respect to the 
functional claims of MIPv6 and thus (c) irrelevant.

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Aug 2005 10:58:54 -0700

> (i.e. the reactive handoff itself)..

The definition of reactive handover, for FMIP purposes, is that the FBU is 
done on the NAR.

            jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Mon, 29 Aug 2005 19:24:31 +0100

James Kempf wrote:
>> yes, but a reactive handover can well happen when the FBU is sent on 
>> the PAR link set the wrong tunnel and then had to do the whole thing 
>> again (i.e. the reactive handoff itself)..
>>
> 
> The definition of reactive handover, for FMIP purposes, is that the FBU 
> is done on the NAR.

ok. Even as such, IMHO the train of thought still applies. The MN 
reactively sets up a tunnel with the configured nCoA but by the time the 
first packet arrives (i.e. one RTT between the NAR and the PAR) it has 
bounced on a new AP cell. This case applies only for a multi-AP overlap 
of M APs (where M >= 3).  Such case is NOT infrequent..

t.