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

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 25 Aug 2005 15:10:05 -0400

> >- What is the problem? That includes the significance of 
 > such problem
 > 
 > The problem: The probability of duplicate addresses, while 
 > very small, is 
 > not zero.

=> This is not a problem. Please name one thing in FMIP, or 
your favourite RFC that has a zero probability. Is the probability
of collisions between Public Keys zero? We still use them in SEND
without being considered wildly adventurous.

 > Its significance: Mindful of this fact, the IESG is likely 
 > to require some 
 > means of precluding packet delivery to the wrong host in the 
 > case that the 
 > odds just happen to cut the wrong way.

=> Let's not design protocols based on our predictions of what
the IESG might do. The IESG allowed DAD, which does not reduce 
the probability of detection of collisions to zero. It also 
allowed oDAD, going to PS, also does not reduce anything to 
zero.....sigh

 > It does solve it for reactive handover, since the NAR can 
 > drop the tunneled 
 > packets if there's an NCE for another host and it gets a 
 > unsolicited NA. The 
 > unsolicited NA alerts the NAR to the fact that the new MN is 
 > trying to claim 
 > somebody else's address. The unsolicited NA will probably 
 > show up prior to 
 > the FBU getting to the PAR and triggering tunneling, since 
 > the FBU must 
 > additionally traverse the NAR/PAR link. The MN gets its own 
 > notification 
 > when the real owner of the address replies to the oDAD NS 
 > with an NA, at 
 > which time it can fix the problem.

=> This is immaterial for oDAD. oDAD means you do DAD in parallel, 
while sending and receiving packets. NAR/PAR ...etc has no impact on
this. 

 > 
 > But it doesn't solve it for predictive handover, because the 
 > PAR might start 
 > tunneling packets prior to the MN even arriving on the link. 
 > If there's 
 > another MN on the link with the same address, the NAR will 
 > send the tunneled 
 > packets to it.

=> Again, It's based on ***probability*** of what's *acceptable*. 
Every thing that could fail in a handover has a higher probability
of failing than DAD! There is no point in securing a glass
house by adding more locks on the door...

Hesham

 >             jak 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 25 Aug 2005 13:20:27 -0700

> allowed oDAD, going to PS, also does not reduce anything to

Thomas did express some reservations about oDAD, based on packets getting 
out to the Internet with a potential duplicate during the IETF review.

Perhaps we should just ask.

>house by adding more locks on the door...

Even if there are no errors and the only problem is just a duplicate 
address, the period of exposure is potentially longer than with the node 
doing oDAD on the link.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 25 Aug 2005 15:32:04 -0700

Folks,

I am not sure what problem we are trying to solve here anymore :-)
So, let me try boldly to pause for a moment and see where we are.

1. We are *not* trying to improve the collision probability of addresses 
here right? oDAD does not do that.

2. We are trying to find a collision-free address for FMIP, right? 
Hoping so, we need to figure out what to specify.

When a HI message is processed by NAR, it is supposed to proxy the NCoA. 
When doing so, it should verify its NCE, just as it does when processing 
the unsolicited NA without overwriting an existing entry.

Assume that there is no entry in NAR's NCE, but there is a node A on the 
link. (If NAR has recently forwarded traffic to node A, then it will 
detect a collision).

a) until the MN attaches to NAR, if any node B does NS for node A, NAR's 
proxy NA will be superseded by node A's solicited NA. If this happens,
should we consider NAR to specifically block packets from PAR to NCoA or 
divert it to MN's LLA?
(Caveat: NAR cannot distinguish between traffic coming from PAR to MN vs 
PAR to node A).

There are no recovery mechanisms if you send a BU and the optimistic 
address happens to be in conflict in oDAD.

Assuming scenario a) does not happen..

b) after the MN attaches to NAR and sends an unsolicited NA, NAR starts 
forwarding packets to the MN. NAR simultaneously probes NCoA, at which 
point, node A should respond. (Does Proxy NCE transition to STALE or 
REACHABLE? I am guessing STALE) The MN should deconfigure NCoA. What 
should NAR do? Should we consider specifying that NAR should drop 
packets coming from PAR to NCoA?

oDAD does not specify a corrective behavior.

Assuming the reactive case..

c) No HI/HAck exchange has taken place. This scenario is the same as b) 
except that NAR does not have Proxy NCE for NCoA.

3) NAR can maintain a pool of collision-free addresses as suggested in 
advanceDAD and return one in HAck and NAACK.

4) Even though there is a very small probability of random collision 
between two addresses, there can be intentional collisions. A MN may 
learn another node's address and send FBU binding its PCoA to the 
victim's address. It is not clear to me how oDAD will prevent such a 
thing. With HI and HAck, we can at least inform NAR that arriving 
traffic from PAR is for a node trying to handover so that NAR can verify 
its NCE instead of blindly forwarding traffic (to the victim). And, we 
could possibly suggest some recovery actions.

So, it looks like we can clarify these things in the spec.

5) Even DAD is not entirely foolproof, but the best we can resort to. 
What if there is a dormant node with a claimed address but does not 
respond to DAD NS? Since an NS can be sent at any time for an address, 
one could argue that going dormant does not make sense if you want to 
defend the address :-) But, this might be interesting on its own. That 
is, we should not worry about this here.

-Rajeev

James Kempf wrote:
> Thomas did express some reservations about oDAD, based on packets 
> getting out to the Internet with a potential duplicate during the IETF 
> review.
>

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 04:44:15 +0100

Hi Rajeev,

> defend the address :-) 

IMO your argument about dormant mode is at least flawed.. A very simple 
question shows this...How does a dormant mode wake up ? :)  A page ?!? 
what is a page? hence presto the requirement that a dormant mode CAN and 
MUST respond to a NS to proclaim a tentative address already existent is 
valid in all its magnitude.

DAD is and will be a valid mandatory requirement for one AND only one 
simple reason: _malicious_ HIJACKING of an IPv6 address (I believe that 
is what you meant by intentional collisions); IPv4 SUFFERS from it.. 
Hence it is above all a security safeguard, and then an addr allocation 
management util (coupled with reconfig of a tentative but existent 
address). The probabilities that people have cited were known from the 
first day that  the size of IPv6 address was proposed and thus a given, 
so the probabilistic dazzling to ignore DAD "to make things 'faster'" is 
more than a grave mistake. It is the HIJACKING we are worried about 
there, rather than the probability of collision.

One more thing..if FMIPv6 claims to be (significantly) faster than 
Mobile IPv6 as a spec then there should be some bounds as to what is the 
expected requirement in terms of handoff latency (if any implementation 
does any better then good for them). However, an FMIPv6 spec that claims 
to be fast and for a significant proportion of handoff is not fast, the 
in my view FMIPv6 becomes MIPv6 in disguise.. To this end the FMIPv6 
must specify

  i) how much better does it do than MIPv6 (i.e. why should I the 
developer adopt it..because it is claimed to be better or because it IS 
better)
  ii) what is the definition of FAST?  Fast by 10ms or with delay of 
<200ms?  The definition of FAST can take so many interpretations that 
can justify N different specifications.. An all encompassing 
specification seems to me too wide and ultimately detracts for the 
realism of achievable performance gains.

iii) when people cite FMIPv6 as an RFC it should be noted it is 
experimental. If it IS experimental it is important to justify CLAIMS by 
  EXPERIMENTS, i.e. some performance bounds one can rely upon to say 
"yes I should use FMIPv6 because it claims X and achieves X, not because 
we will solve the problems soon in an 'issue' tracker..stay tuned for a 
solution."

iv) the issues that are mentioned seem to me to indeed fail the claims 
of FMIPv6 for a fast handoff. On this point I reuse Hesham's wording 
because this is what he actually meant: if FMIPv6 is eventually to do 
what MIPv6 will do on the reactive case (I do not touch the 'predictive' 
case because it is at least 'optimistic' for more than 30% of the 
handoffs (and I have data for this)..then why should one bother with 
FMIPv6 in the first place. If I want context establishment I can very 
well push it with CARD...We indicated this with the proactive MIPv6 
solution..

it is important to show the added value of FMIPv6 versus MIPv6 in terms 
of a FAST HANDOFF, as this its claimed objective, rather than context 
transfers.. So I would be grateful if you could state

   i) is it faster by MIPv6 and by how much?
   ii) what is the latency target of a fast handoff. (The 'any' answer 
is at least naive and definetely not for this world's order..)
   iii) can it fail to achieve such target and WHEN?
   iv) what is the frequency of such failure to comply with the CLAIMED 
performance gains. If it is significant I'd rather stay with MIPv6 or go 
for another MIPv6 design..

thanks
t.

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 10:42:19 -0700

Theo,

> simple reason: _malicious_ HIJACKING of an IPv6 address (I believe that is 
> what you meant by intentional collisions); IPv4 SUFFERS from it.. Hence it 
> is above all a security safeguard, and then an addr allocation management 
> util (coupled with reconfig of a tentative but existent address). The 
> probabilities that people have cited were known from the first day that 
> the size of IPv6 address was proposed and thus a given, so the 
> probabilistic dazzling to ignore DAD "to make things 'faster'" is more 
> than a grave mistake. It is the HIJACKING we are worried about there, 
> rather than the probability of collision.
>

If SEND/CGAs are used, hijacking can be eliminated.

> One more thing..if FMIPv6 claims to be (significantly) faster than Mobile 
> IPv6 as a spec then there should be some bounds as to what is the expected 
> requirement in terms of handoff latency (if any implementation does any 
> better then good for them). However, an FMIPv6 spec that claims to be fast 
> and for a significant proportion of handoff is not fast, the in my view 
> FMIPv6 becomes MIPv6 in disguise.. To this end the FMIPv6 must specify
>

Well, my admittedly rough measurements of RTT between Europe and the US run 
to 190 ms or more, and from the West to East Coast US to 60 ms. Add that to 
the 90 ms that others have been citing for 802.11 L2 handover, and you can 
see why FMIP might help. Even locally, from San Jose to Berkeley is about 
15-30 ms.

Estimates of MIP6 handover performance when the home agent is one hop away 
on a 100 MB Ethernet link in a lab are not realistic.

> iv) the issues that are mentioned seem to me to indeed fail the claims of 
> FMIPv6 for a fast handoff. On this point I reuse Hesham's wording because 
> this is what he actually meant: if FMIPv6 is eventually to do what MIPv6 
> will do on the reactive case (I do not touch the 'predictive' case because 
> it is at least 'optimistic' for more than 30% of the handoffs (and I have 
> data for this)..then why should one bother with FMIPv6 in the first place. 
> If I want context establishment I can very well push it with CARD...We 
> indicated this with the proactive MIPv6 solution..
>

It seems you're arguing here about the particular protocol design, not that 
something is needed. I think we certainly can and must improve the design of 
FMIP, and that's what this discussion is about. Evidence is certainly 
useful; however, I think we need to be careful not to bring to this 
discussion particular, shall we say, predjuices for our favorite flavor of 
solution which might not be embodied in the current design. That tends to 
lead to a lack of ability to achieve concensus, and therfore a lack of 
convergence on a standard. My reading of the literature ,and some 
experiements we did a while back, has convinced me that the basic design of 
FMIP is sound, it's the details that need to be fleshed out, since the 
current spec is ambiguous or unclear on some points. I've not seen any other 
approach that is clearly superior, otherwise I'd be arguing for it.

>
> it is important to show the added value of FMIPv6 versus MIPv6 in terms of 
> a FAST HANDOFF, as this its claimed objective, rather than context 
>   ii) what is the latency target of a fast handoff. (The 'any' answer is 
> at least naive and definetely not for this world's order..)

I would certainly like to see some real experiments where such measurements 
are made for home agents at varying distances. We did some such measurements 
for Post-MIT MIP4 fast handover, which is similar to reactive FMIP, using a 
delay line between the AR and HA. The improvement over standard MIP4 was 
substantial.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 26 Aug 2005 22:10:08 +0200

James, sorry for interfering, and I've tried to stay away from the IP
distances discussion, but here's remark a few anyways...

James Kempf wrote:
> Theo,
> 
>> IMO your argument about dormant mode is at least flawed.. A very 
>> simple question shows this...How does a dormant mode wake up ? :) A
>>  page ?!? what is a page? hence presto the requirement that a 
>> dormant mode CAN and MUST respond to a NS to proclaim a tentative 
>> address already existent is valid in all its magnitude.
>> 
>> DAD is and will be a valid mandatory requirement for one AND only 
>> one simple reason: _malicious_ HIJACKING of an IPv6 address (I 
>> believe that is what you meant by intentional collisions); IPv4 
>> SUFFERS from it.. Hence it is above all a security safeguard, and 
>> then an addr allocation management util (coupled with reconfig of a
>>  tentative but existent address). The probabilities that people 
>> have cited were known from the first day that the size of IPv6 
>> address was proposed and thus a given, so the probabilistic 
>> dazzling to ignore DAD "to make things 'faster'" is more than a 
>> grave mistake. It is the HIJACKING we are worried about there, 
>> Mobile IPv6 as a spec then there should be some bounds as to what 
>> is the expected requirement in terms of handoff latency (if any 
>> implementation does any better then good for them). However, an 
>> FMIPv6 spec that claims to be fast and for a significant proportion
>>  of handoff is not fast, the in my view FMIPv6 becomes MIPv6 in 
>> disguise.. To this end the FMIPv6 must specify
>> 
> 
> Well, my admittedly rough measurements of RTT between Europe and the
>  US run to 190 ms or more, and from the West to East Coast US to 60 
> ms. Add that to the 90 ms that others have been citing for 802.11 L2
>  handover, and you can see why FMIP might help. Even locally, from
> San Jose to Berkeley is about 15-30 ms.
> 
> Estimates of MIP6 handover performance when the home agent is one hop
>  away on a 100 MB Ethernet link in a lab are not realistic.

I agree a far HA lengthens the IP config time so FMIPv6 gains could be
subsequently more important.  But then how about this:

Estimates of FMIPv6 superior handover performance when the oAR and nAR
are IP neighbours linked by same lab 100 MB Ethernet are not realistic,
because the assumption of a fast link between ARs (faster than handover
time) is key for FMIP design.  Or, many deployments don't link ARs with
fast links:

A public WiFi deployment has ARs linked with 1MB ADSL (ie 10th of lab
Ethernet) to a central operator router.  2 IP hops away.

A handover between that WiFi deployment (oAR) and a GPRS deployment
(nAR) has the oAR and the SGSN (nAR) at about 5 IP hops away.

Many deployed networks that support link-layer mobility have a "mobility
agent" that is close to the place where mobility takes place.
SGSN/GGSN, VLR/HLR.  Logical extension would give that a Mobile IPv6
deployment has HA near the place where mobility takes place, and not far.

This is to say that neither estimates of MIP6 being bad because HA is
far and nor FMIP6 being superior because ARs communicate fast are
realistic.  What is realistic is experimentation.

I am looking for experiments of a VoIP MN performing badly because of
Mobile IPv6.  The simplest way to achieve that is in lab.

I am offering descriptions of experiments of non-real-time mpeg4ip, vic,
and others (but no VoIP) that are not at all interrupted during Mobile
IPv6 handovers.  I am offering also descriptions of experiments
of non-real-time applications that perform very poorly over wireless
even though no handovers.  Also descriptions of message exchanges being
really fast but computing slow so applications get disturbed.

>> iv) the issues that are mentioned seem to me to indeed fail the 
>> claims of FMIPv6 for a fast handoff. On this point I reuse Hesham's
>>  wording because this is what he actually meant: if FMIPv6 is 
>> eventually to do what MIPv6 will do on the reactive case (I do not
>>  touch the 'predictive' case because it is at least 'optimistic'
>> for more than 30% of the handoffs (and I have data for this)..then
>> why should one bother with FMIPv6 in the first place. If I want 
>> context establishment I can very well push it with CARD...We 
> It seems you're arguing here about the particular protocol design, 
> not that something is needed. I think we certainly can and must 
> improve the design of FMIP, and that's what this discussion is about.
>  Evidence is certainly useful; however, I think we need to be careful
>  not to bring to this discussion particular, shall we say, predjuices
>  for our favorite flavor of solution which might not be embodied in 
> the current design.

It's not my case.

> That tends to lead to a lack of ability to achieve concensus, and 
> therfore a lack of convergence on a standard. My reading of the 
> literature ,and some experiements we did a while back, has convinced 
> me that the basic design of FMIP is sound, it's the details that need
>  to be fleshed out, since the current spec is ambiguous or unclear on
>  some points.

I somehow agree.  The FMIPv6 concepts are indeed sound and make sense at
least on paper: (1) pre-handover address autoconf is logically faster,
(2) tunnelling saves otherwise discarded data and (3) transferring
contexts between ARs potentially saves the messages re-establishing them.

Maybe an idea would be to have separate specs for each one of this,
maybe easier to tackle.

But still backed by demo showing what is slow and why, so there is
incentive on implementing; just using the word "fast" in its name
is little motivating.  Sorry if too strong statements, I should have
spiked IMHO's here and there.

> I've not seen any other approach that is clearly superior, otherwise
>  I'd be arguing for it.

Neither have I, I'm not arguing for any other approach.

>> it is important to show the added value of FMIPv6 versus MIPv6 in 
>> terms of a FAST HANDOFF, as this its claimed objective, rather than
>>  context transfers.. So I would be grateful if you could state
>> 
>> i) is it faster by MIPv6 and by how much? ii) what is the latency 
>> target of a fast handoff. (The 'any' answer is at least naive and 
>> definetely not for this world's order..) iii) can it fail to 
>> achieve such target and WHEN? iv) what is the frequency of such 
>> failure to comply with the CLAIMED performance gains. If it is 
>> significant I'd rather stay with MIPv6 or go for another MIPv6 
>> design..
>> 
> 
> I would certainly like to see some real experiments where such 
> measurements are made for home agents at varying distances. We did 
> some such measurements for Post-MIT MIP4 fast handover, which is 
> similar to reactive FMIP, using a delay line between the AR and HA. 
> The improvement over standard MIP4 was substantial.

Thanks for mentioning this and I'll have another look at the paper.
Just curious: a certain delay was improved or user experience was improved?

Alex

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 13:28:04 -0700

Re. GPRS to WiFi, the latency in most 3G networks is too high for FMIP to 
really be of interest.

Re. our measurements, they were time measurments.

            jak

----- Original Message ----- 
From: "Alexandru Petrescu" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Theo Pagtzis" <[email-masked]>; "Rajeev Koodli" 
<[email-masked]>; "Soliman, Hesham" <[email-masked]>; 
<[email-masked]>
Sent: Friday, August 26, 2005 1:10 PM
Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 14:01:07 -0700

> should NAR do? Should we consider specifying that NAR should drop packets 
> coming from PAR to NCoA?
>

Drop, I think. At that point, the optimization has failed, but it's a very 
low probability scenerio.

> 5) Even DAD is not entirely foolproof, but the best we can resort to. What 
> if there is a dormant node with a claimed address but does not respond to 
> DAD NS? Since an NS can be sent at any time for an address, one could 
> argue that going dormant does not make sense if you want to defend the 
> address :-) But, this might be interesting on its own. That is, we should 
> not worry about this here.
>

Like Theo said, the NS acts as a kind of page. If the MN doesn't wake up, 
then it lost the right to claim the address.

Rest of the email looked OK, but we need to clarify in the spec.

            jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 23:01:35 +0100

James Kempf wrote:
>> page ?!? what is a page? hence presto the requirement that a dormant 
>> mode CAN and MUST respond to a NS to proclaim a tentative address 
>> already existent is valid in all its magnitude.
>>
>> simple reason: _malicious_ HIJACKING of an IPv6 address (I believe 
>> that is what you meant by intentional collisions); IPv4 SUFFERS from 
>> it.. Hence it is above all a security safeguard, and then an addr 
>> allocation management util (coupled with reconfig of a tentative but 
>> existent address). The probabilities that people have cited were known 
>> from the first day that the size of IPv6 address was proposed and thus 
>> a given, so the probabilistic dazzling to ignore DAD "to make things 
>> 'faster'" is more than a grave mistake. It is the HIJACKING we are 
>> worried about there, rather than the probability of collision.
>>
> 

Sure but I have not seen FMIPv6 making a statement about REQUIRING 
SEND/CGA to do what it claims. Of course there is a possibility of using 
it, but by not mandating it, I am lead to believe that the spec does not 
need it. So

   1) if it does not need it then doing DAD takes as long as MIPv6 period.
   2) if it does need it then FMIPv6 *requires* SEND/CGA during a 
reactive handoffs and then it is not FMIPv6 anymore. It is FMIPv6 + 
SEND/CGA + CARD + whatever comes next.. (i.e. for a fast handoff 
protocol it seems pretty heavy - aside clean interoperability issues..

>> Mobile IPv6 as a spec then there should be some bounds as to what is 
>> the expected requirement in terms of handoff latency (if any 
>> implementation does any better then good for them). However, an FMIPv6 
>> spec that claims to be fast and for a significant proportion of 
>> handoff is not fast, the in my view FMIPv6 becomes MIPv6 in disguise.. 
>> To this end the FMIPv6 must specify
>>
> 
> Well, my admittedly rough measurements of RTT between Europe and the US 
> run to 190 ms or more, and from the West to East Coast US to 60 ms. Add 
> that to the 90 ms that others have been citing for 802.11 L2 handover, 
> and you can see why FMIP might help. Even locally, from San Jose to 
> Berkeley is about 15-30 ms.

James the argument is not only about the RTT but a few other things... 
the RTT was the last of my worries for FMIPv6 latency claims..there are 
far more important ones..

>> what MIPv6 will do on the reactive case (I do not touch the 
>> 'predictive' case because it is at least 'optimistic' for more than 
>> 30% of the handoffs (and I have data for this)..then why should one 
>> bother with FMIPv6 in the first place. If I want context establishment 
>> I can very well push it with CARD...We indicated this with the 
>> proactive MIPv6 solution..
>>
> 
> It seems you're arguing here about the particular protocol design, not 
> that something is needed. 

well I am not arguing about a particular protocol flavour. I am arguing 
that a fast handoff must be what it claims: "fast". How "fast" is 
"fast", what is the "fast" qualifier driven by, since the qualifier is 
not the aim in itself...

I think we certainly can and must improve the
> design of FMIP, and that's what this discussion is about. Evidence is 
> certainly useful; however, I think we need to be careful not to bring to 
> this discussion particular, shall we say, predjuices for our favorite 
> flavor of solution which might not be embodied in the current design.

I wish it was only prejudice. I will have to put it down on a paper I 
guess and run it by you..

> therfore a lack of convergence on a standard. 

the aim in my view if for robust design before its standardisation. 
There is no intention for divergence but for convergence. There are key 
issues though that render FMIPv6 as specified problematic

My reading of the
> literature ,and some experiements we did a while back, has convinced me 
> that the basic design of FMIP is sound,

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) ????????????????????

Anyway I have a lot more like this. This is exactly why I insisted back 
in 2001 on a some insights only for them to be ignored. Well here we are 
now...in a standard form..

  it's the details that need to be
> fleshed out, since the current spec is ambiguous or unclear on some 
> points. I've not seen any other approach that is clearly superior, 
> otherwise I'd be arguing for it.

Yes I have one in mind (with argument about it) but then again it may be 
called prejudice..

>> performance gains. If it is significant I'd rather stay with MIPv6 or 
>> go for another MIPv6 design..
>>
> 
> measurements are made for home agents at varying distances. We did some 
> such measurements for Post-MIT MIP4 fast handover, which is similar to 
> reactive FMIP, using a delay line between the AR and HA. The improvement 
> over standard MIP4 was substantial.

Fine! since the improvement is substantial: a) how much (even roughly) 
was it b) what was the contention ratio on the link and how much the 
offered load  c) where would the substantial latency gain be used?

I have been meticulous about this "details" for the last 4 years and 
have reasonable grounds to insist on these.

theo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 15:16:56 -0700

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

> Anyway I have a lot more like this. This is exactly why I insisted back in 
> 2001 on a some insights only for them to be ignored. Well here we are 

Well, please don't hesitate to post any issues you may have. If we want a 
good standard, we definitely need to everybody to bring up what they have, 
since there may be some that haven't been considered before.

> Yes I have one in mind (with argument about it) but then again it may be 

"Predjucie" is something like this: I have this issue and the only way to 
fix it is to accept *my* design.

> Fine! since the improvement is substantial: a) how much (even roughly) was 
> it b) what was the contention ratio on the link and how much the offered 
> load  c) where would the substantial latency gain be used?
>

I can send you the paper if you want. Or you can wait until it's published, 
it will appear shortly in Wireless Networking.

            jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Fri, 26 Aug 2005 23:33:01 +0100

>> tunnel can be established (bind NCoA to PCoA) ????????????????????

Ok, so...how do you pick one since you cannot correlate it with where 
you are moving at a single instant..????

> 
>> Anyway I have a lot more like this. This is exactly why I insisted 
>> back in 2001 on a some insights only for them to be ignored. Well here 
>> we are now...in a standard form..
>>
> 
> Well, please don't hesitate to post any issues you may have. If we want 
> a good standard, we definitely need to everybody to bring up what they 
> have, since there may be some that haven't been considered before.
> 
>> Yes I have one in mind (with argument about it) but then again it may 
>> be called prejudice..
>>
> 
> "Predjucie" is something like this: I have this issue and the only way 
> to fix it is to accept *my* design.

:) .. or alternatively: we see we have a few issues but will not accept 
anything other than X design..

The point is really not whose design you choose. The point is whether 
you can solve the problems with the existing design. I am looking 
forward to see how the above issue is corrected for instance with the 
existing design..without changing it so much it is not the original 
design standard anymore..

> I can send you the paper if you want. 

yes please!

---

From: "James Kempf" <[email-masked]>
Date: Fri, 26 Aug 2005 15:43:56 -0700

> 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? The important point is the MN has a 
mapping between the AP/BS to which it is moving and a router address. It 
gets that through the PrxyRtXX messages and/or 802.21.

I suppose there's an issue of load balancing, but once the MN is on the 
link, the NAR can send a Redirect to get the MN to move to a more lightly 
loaded router.

> anything other than X design..

X design (in this case FMIP) has been kicked around quite a bit, so we have 
a pretty good understanding of its strengths and weaknesses. It's 
experimental because we didn't understand how to remedy the weaknesses when 
it was put up for RFC publication. The point of moving it to MIPSHOP and the 
discussion we are currently having is to try to figure out how to fix those 
weaknesses (we already have some idea how to fix the most important from 
discussion in MOBOPTS). I'm not ready to start with something completely 
different at this point, because it might have unknown weaknesses that will 
take another 5 years to find and fix (which is about how long we've been 
working on FMIP).

> The point is really not whose design you choose. The point is whether you 
> can solve the problems with the existing design. I am looking forward to 
> see how the above issue is corrected for instance with the existing 
> design..without changing it so much it is not the original design standard 
> anymore..
>

Right.

            jak

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 27 Aug 2005 00:23:52 +0100

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

---

From: Greg Daley <[email-masked]>
Date: Mon, 29 Aug 2005 12:10:46 +1000

Hi Theo,

> James Kempf wrote:
[cut]
> it, but by not mandating it, I am lead to believe that the spec does not 

Ignoring the premise, which I don't agree with (It doesn't matter

>   1) if it does not need it then doing DAD takes as long as MIPv6 period.

Which, it has been argued, is effectively no time at all using
Optimistic DAD.

> protocol it seems pretty heavy - aside clean interoperability issues..

The difference between now and 2000/2001 is stark in the development
of other protocols which assist handovers.

If the FMIPv6 RFC is a snapshot of what was available
at an earlier time which illustrated what we were willing to
experiment on, then that shouldn't let us make use of (now)
pre-existing standards track mechanisms when the system gets
converted to standards track itself.

So certainly, telling people that SEND is recommended [with
appropriate context and a reference], is fine.
Telling people about optimistic DAD and knowing if there are
additional issues with it, is also fine, IMO.

Greg

---

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

Hi Greg,

Greg Daley wrote:
>> SEND/CGA to do what it claims. Of course there is a possibility of 
>> using it, but by not mandating it, I am lead to believe that the spec 
>> does not need it. So
> 
> 
> 

please correct me if I am wrong, but in version

http://www.ietf.org/internet-drafts/draft-ietf-ipv6-optimistic-dad-05.txt, 
  section 3.1 (General) you specify that it SHOULD be

  " Nodes implementing Optimistic DAD SHOULD additionally implement
         Secure Neighbor Discovery [SEND]. "

is that what you mean by saying that 'it doesn't matter whether or not 
SEND/CGA is in use'. If so why bother with implementing it?

With oDAD I have a question which IMO is pertinent to see how the 
optimism in usage of the nCoA can be sustained without implicit delays 
arising from the Addr Resolution process.

Page 7 of the above revision mentions that:

"NSs sent as part of DAD are sent from the unspecified addr WITHOUT a 
SLLAO".

I assume this is sent to the all-nodes multicast addr..

Now when the NAR receives this it sends its own NS to initiate addr 
resolution and thus derive the MN LLA. However:

page 9 mentions that the MN must not reply to a NS for an Optimistic 
addr from the unspecified address. If this is the case, and assuming the 
  Optimistic addr is pending DAD resolution (and thus cannot be used as 
the source addr in the NA), HOW will the MN notify its LLA to the NAR??

Also I was under the impression that until the nCoA becomes 'Preferred' 
as per RFC2461, the NUD cannot resolve its state in the NCE to 
REACHABLE, (lingers between INCOMPLETE and PROBE). As such packets 
cannot be forwarded in either direction. Could it be that even if the 
address appears to be usable (but optimistically DAD resolvable), is 
blocked by the NCE state of NUD??

> Which, it has been argued, is effectively no time at all using

The 'no time at all' qualifier appears to be a bit too 'optimistic'. 
Currently, the MN must deal with timeouts of a number of RA before it 
can consider a change in link and thus kickstart the address config 
process. This is 3-4 router adverts which at best is 160ms.

> of other protocols which assist handovers.

nobody denies that other protocol may have emerged to assist handoffs in 
a period of 4 years. The insights I referred to back in 2001 have to do 
with FMIPv6 problems of today identified back in 2001..

More to the point, when one designs a protocol he HAS to indicate the 
dependencies IMO, particularly IF without them the protocol fails on the 
fundamental optimisation objective (i.e. the measure of handoff latency) 
during average case scenarios (e.g. reactive handoff). Indicating the 
performance dependencies/limitations is our responsibility, it is not an 
option..

> appropriate context and a reference], is fine.

yes of course it is. It is also imperative that we show, where and why 
is necessary in FMIPv6 w.r.t its FUNDAMENTAL performance objective. 
HOWEVER, one must be aware of the growing weight of FMIPv6 not as a 
protocol but as a protocol suite..We cannot hide this under the carpet.

> additional issues with it, is also fine, IMO.

I never refuted such statement..

t.

---

From: Greg Daley <[email-masked]>
Date: Wed, 31 Aug 2005 14:44:13 +1000

Hi Theo,

Theodoros Pagtzis wrote:
[cut]
> SEND/CGA is in use'. If so why bother with implementing it?

You've missed my point.

You said below:

"1) if it does not need it then doing DAD takes as long as MIPv6 period."

It doesn't matter in this case that SEND is used.
it would take as long if SEND was used or wasn't used.

> I assume this is sent to the all-nodes multicast addr..

No! it is sent to the solicited nodes' address (RFC2461/2).

> resolution and thus derive the MN LLA. However:

No it doesn't! it sends a response to all-nodes (RFC2461/2).

> the source addr in the NA), HOW will the MN notify its LLA to the NAR??

Why would it?

an NS from the unspecified address is another device
performing DAD.

This means that the optimistic DAD node has discovered a duplicate,
and should de-configure the address.

> blocked by the NCE state of NUD??

That impression could be remedied by referring to RFC2462 and RFC2461.

Packets can be forwarded in STALE, and DELAY states, even if you
were right (which you're not).

Addrconf relies on Neighbour Discovery state, not the other way around.

> process. This is 3-4 router adverts which at best is 160ms.

This has got nothing to do with FMIPv6, though,
it's got to do with router discovery.

Actually, that's what the DNA Working Group is doing.

There's no need for timeouts if you've got a CPL.
A single RA should suffice to indicate change.
New methods have also been described which
augment RA knowledge to

RA delivery should be possible using hash-fastRA which
will give RAs with no induced delay.

i.e. the over the air round trip time.  (~< 15ms on a wireless lan).

All this is designed to work with Optimistic DAD.

here's one of the (complete) descriptions of how to
accomplish this:

http://www.ietf.org/internet-drafts/draft-pentland-dna-protocol-01.txt

Here is a description (by someone who knows FMIPv6),
of how this would interact with FMIPv6:

http://www.ietf.org/internet-drafts/draft-koodli-dna-fmip-00.txt

Clearly, the issue is being looked at closely.

> performance dependencies/limitations is our responsibility, it is not an 

Well, it seems a more fundamental thing than that is to know
the protocols which are to be analysed.

Greg

---

From: Theodoros Pagtzis <[email-masked]>
Date: Wed, 31 Aug 2005 10:44:52 +0100

Hi Greg,

> it would take as long if SEND was used or wasn't used.

ok so you say basically SEND does not achieve anything on the latency 
front. This is fine with me. It simply excluded SEND on the DAD latency. 
So why would oDAD need SEND ?

> The rest of your assumptions about DAD are incorrect too:

well not the assumptions but the pointed multicast address. The 
assumption is that 'the NS is sent somewhere without the SLLAO'. I saw 
zero impact from the mistaken address in my question and please correct 
me if am wrong.
> No! it is sent to the solicited nodes' address (RFC2461/2).

yes correct..that was the intended address reference and if I recall 
correctly the number of nodes joining the all-nodes and the 
solicited-nodes mutlicast group is exactly the same. Please correct me 
if I am wrong.

> No it doesn't! it sends a response to all-nodes (RFC2461/2).

see above..

..even if the response is sent to this address the question remains: "If 
the MN has not sent its SLLAO in the NS how does the NAR know the LLA of 
the MN to forward downstream DURING the DAD resolution? "

>> addr from the unspecified address. If this is the case, and assuming 
>> the  Optimistic addr is pending DAD resolution (and thus cannot be 
>> used as the source addr in the NA), HOW will the MN notify its LLA to 
>> the NAR??
> 
> 
> Why would it?

well, if I understand correctly, forwarding in ANY direction requires a 
neighbour resolution (the good old ARP resolution) from an IP address to 
the LLA address of the destined IP address. Otherwise how would the 
frame be forwarded to its MAC destination..?

> an NS from the unspecified address is another device

yes I am aware of that..

> and should de-configure the address.

yes I realised that too from the text..

> 
>> Also I was under the impression that until the nCoA becomes 
>> 'Preferred' as per RFC2461, the NUD cannot resolve its state in the 
>> NCE to REACHABLE, (lingers between INCOMPLETE and PROBE). As such 
>> packets cannot be forwarded in either direction. Could it be that even 
>> if the address appears to be usable (but optimistically DAD 
>> resolvable), is blocked by the NCE state of NUD??
> 
> 

I prefer a straight answer

> were right (which you're not).

assuming that the neighbour resolution IS in place (i.e. you know its 
MAC (link-layer) address. Do you have MN's (at NAR)  for downstream 
forwarding from the NAR to the MN?? This was the question in search of 
an answer instead of vague remedies. Where I am wrong please correct me 
with a straight answer to the _question_.

we know that NUD has to be effected BIDIRECTIONALY independently on MN 
and NAR. the NA sent by the NAR sort out the NUD from the MNs side (i.e. 
upstream).

I am still awaiting your answer about how the NAR will know MN's SLLAO 
during the critical period of DAD to do the forwarding downstream (since 
upstream the NA received by the MN would sort it out)..

> Addrconf relies on Neighbour Discovery state, not the other way around.

did I say the opposite???
> it's got to do with router discovery.

I am referring now to oDAD not to FMIPv6...oDAD is part of Neighbour 
Discovery. oDAD assumes that the MN picks up from the RA NAR's LLA, but 
that would happen only after 3 RAs (roughly).

In any case let us assume that DNA would do this. I will need to look at 
DNA proposal more closely..That implies that now FMIPv6 REQUIRES FMIPv6 
+ oDAD + DNAsolution... to do a fast handoff.

> Clearly, the issue is being looked at closely.

so CLEARLY the issue exists and it has not been acknowledged yet in the 
FMIPv6 spec ;) Also it has not been acknowledge that FMIPv6 is in dire 
need of this in order to achieve some measure of latency gains. Q.E.D.

>> nobody denies that other protocol may have emerged to assist handoffs 
>> in a period of 4 years. The insights I referred to back in 2001 have 
>> to do with FMIPv6 problems of today identified back in 2001..
>>
>> dependencies IMO, particularly IF without them the protocol fails on 
>> the fundamental optimisation objective (i.e. the measure of handoff 
>> latency) during average case scenarios (e.g. reactive handoff). 
>> Indicating the performance dependencies/limitations is our 
>> responsibility, it is not an option..
>>
> 

well since you know the protocols so well, please educate us on the 
above question that you still appear to have 'missed'. Where wrong I 
stand corrected but that does not debunk the question (if this is what 
you have in mind) ..especially when it has not received an answer :)

So to assist I put the question again forward: "If the MN has not sent 
its SLLAO in the NS how does the NAR know the LLA of the MN to forward 
downstream DURING the DAD resolution period (i.e. 1000ms)? "

many thanks

t.