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

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Sat, 27 Aug 2005 11:19:41 -0500

Hi Theo,
I do agree that reactive handovers with stateful CoA configuration is likely to be too slow - I won't be surprised if that is actually slower than MIP, as you say. In the case of reactive handovers, only stateless autoconfig seems to make sense to me. Even in the IPv4 world, post-MIT like approaches worked well when there were FA CoAs. With CCoAs, the DHCP delays were ugly. 

The DHCP latency can surely be improved - but that is more complex and probably work that needs to occur separately. 

Vidya

> -----Original Message-----
> From: Theodoros Pagtzis [mailto:[email-masked]] 
> Sent: Saturday, August 27, 2005 5:24 AM
> To: Narayanan Vidya-CVN065
> Cc: James Kempf; Soliman, Hesham; mipshop; Rajeev Koodli
> Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?
> 
> 
> Hi Vidya,
> 
> Narayanan Vidya-CVN065 wrote:
> > 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?
> 
> 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.
> 
> -- 
> theo
> Nets & Mobile Systems Group
> UCL-CS
> 

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

---

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

Vidya,

Stateful configuration can't possibly be slower than MIP,  because the MN 
has to have an nCoA before it can do the BU to the HA and correspondent 
nodes.

But it could be substantially slower than stateless autoconfiguration, 
especially if the MN must send a DHCP CONFIRM for movement detection to 
check whether the old address is still valid after the handover, which the 
DHCPv6 spec currently requires.

        jak

----- Original Message ----- 
From: "Narayanan Vidya-CVN065" <[email-masked]>
To: "'Theodoros Pagtzis'" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; "mipshop" <[email-masked]>; "Rajeev Koodli" 
<[email-masked]>
Sent: Saturday, August 27, 2005 9:19 AM
Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

> Hi Theo,
> I do agree that reactive handovers with stateful CoA configuration is 
> likely to be too slow - I won't be surprised if that is actually slower 
> than MIP, as you say. In the case of reactive handovers, only stateless 
> autoconfig seems to make sense to me. Even in the IPv4 world, post-MIT 
> like approaches worked well when there were FA CoAs. With CCoAs, the DHCP 
> delays were ugly.
>
> The DHCP latency can surely be improved - but that is more complex and 
> probably work that needs to occur separately.
>
> Vidya
>

---

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

James Kempf wrote:
> Vidya,
> 
> Stateful configuration can't possibly be slower than MIP,  because the
> MN has to have an nCoA before it can do the BU to the HA and 
> correspondent nodes.

I am confused with the above statement..When 'saying slower than MIPv6' 
I assume you mean 'slower than the stateless autoconfig under MIPv6 
yes?' If this is the case, then the aquisition of the nCoA statefully 
(i.e. DHCP) even if used to do BUs to peers how can it not be slower 
than MIP if the stateful process takes longer than plain DAD..?

> check whether the old address is still valid after the handover, which 
> the DHCPv6 spec currently requires.

right, but this seems to refute your first statement.. Am I missing 
something?..

t.

---

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

> I am confused with the above statement..When 'saying slower than MIPv6' I 
> assume you mean 'slower than the stateless autoconfig under MIPv6 yes?' If 
> this is the case, then the aquisition of the nCoA statefully (i.e. DHCP) 
> even if used to do BUs to peers how can it not be slower than MIP if the 
> stateful process takes longer than plain DAD..?
>

No, I meant "slower than sending a BU to the HA and to any correspondent 
nodes with which the MN is doing route optimization".

Address configuration, whether stateless (oDAD or not) or stateful, is a 
completely separate issue.

            jak