Subject: [DNA] Feedback on draft-ietf-dna-cpl-00.txt

From: Christian Vogt <[email-masked]>
Date: Fri, 27 May 2005 17:22:40 +0200

Hi JinHyeock, hi Erik,

I took a look at the Complete Prefix List proposal.

First of all, I like the idea of not having to change any entities in 
the network but only the MN's stack.  This is a significant advantage in 
terms of applicability until more radical DNA techniques establish 
themselves.

On thing concerning reliance on unsolicited RAs.  Section 3.1 says:

    ++++
    The host forms the prefix list at any attachment point, that is, this
    process starts independently of any movement.  Though the procedure
    may take some time, that doesn't matter unless the host moves very
    fast.  A host can generate the complete prefix list with reasonable
    certainty if it remains attached to a link sufficiently long.  It
    will take approximately 12 seconds, when it actively perform 3 RS/ RA
    exchanges.  If it passively relies on unsolicited RA messages
    instead, it may take much more time.
    ++++

I see that one cannot really do much analysis for routers that send 
unsolicited RAs every 30ms to 70ms as proposed by RFC 3775 (because such 
RA might not have all of the prefixes included).  But since this high 
frequency would obviously improve the situation for CPL, it might be 
worthwhile to put a note into the draft.

I presume you are planning to do, or have already done, some 
experimental tests to find out how well CPL works when MNs move really 
fast.  Well, maybe this can be done on a theoretic basis like the 
Performance Analysis in section 9.

I do understand that CPL is 100% reliable, even in high-speed scenarios, 
when the prefix sets in RAs from the same link are guaranteed to overlap.

The draft is on its way to Proposed Standard, right?

Kind regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 30 May 2005 20:07:18 +0900

Dear Christian

Thanks for your kind and insightful feedback. 

> terms of applicability until more radical DNA techniques establish

ok. glad to hear that.  
 
> worthwhile to put a note into the draft.

ok. 

I think it is ok for a host to send 1 RS and waits for 4 secs 
to collect (solicited) RAs and declare its prefix list (CCL) complete.

Without a packet loss, the host will generate the complete prefix list.

Even some packet loss may cause an incomplete prefix list,
there is a further chance for the host to get the missing prefixes
before it receives link UP notification, i.e. moves to another AP.

Even the host moves to another AP with incomplete prefix list,
the first RA may contain the prefix in its prefix list.

Considering all those above, even if the host performs only one
RS/ RA exchange, it will be very rare for the host to falsely
assume a link change. Even in case of such a false assumption, 
there will not be a communication disruption but only unnecessary 
signaling. 

So I think such an occasional unnecessary signaling is acceptable
and 1 RS/ RA exchange is enough for the complete prefix
list generation. 

How do you think of it?
 
> Performance Analysis in section 9.

We have an implementation plan but didn't think much about 
the fast moving MN case yet. 
 
> when the prefix sets in RAs from the same link are guaranteed to overlap.
 
This is a very good point, really an acute observation. Thanks. 
Yes, there will no mistakenly assuming a link change because of 
common element (prefix) in (any two) RAs. 

> The draft is on its way to Proposed Standard, right?

We didn't decide it yet. 

Thanks for your kind consideration. 

Best Regards

JinHyeock

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 May 2005 19:59:57 +0200

Hi JinHyeock.

> I think it is ok for a host to send 1 RS and waits for 4 secs to
> collect (solicited) RAs and declare its prefix list (CCL) complete.

I agree.

Besides, has there been a discussion in DNA or elsewhere as to what a
reasonable upper bound on the handover frequency could be?  If there
was, it might be good to put a link into your document.

[...]

>> I do understand that CPL is 100% reliable, even in high-speed
>> scenarios, when the prefix sets in RAs from the same link are
>> guaranteed to overlap.
> 
> This is a very good point, really an acute observation. Thanks. Yes,
> there will no mistakenly assuming a link change because of common
> element (prefix) in (any two) RAs.

Right, and it would be easy for network administrators to set IP links
up this way.

The only issue I see at this moment is IP links which have so many
prefixes that all of them do not fit within a single RA.  In this
situation, the prefix sub-set advertised in one RA might not overlap
with the prefix sub-set advertised in another RA, even though the
complete prefix lists of any two routers on the same IP link do overlap.

Of course, a RA daemon can be configured (or patched) such that any two
successive RAs have overlapping prefix sub-sets.  A RA damon can also be
configured/patched such that the prefix sub-sets of all of its RAs
overlap (for instance, by choosing one common prefix).

However, while this approach helps, it still cannot prevent the MN from
seeing two successive RAs (from the same IP link) with disjunct prefix
sub-sets:  One reason is RA loss, another is multiple routers on the
same IP link.

To coordinate multiple routers on the same IP link, one would end up
having to choose one common prefix which all of the routers put in all
of their RAs.  And that would effectively be the Link ID proposal. ;)

- Christian

JinHyeock Choi wrote:
>> First of all, I like the idea of not having to change any entities
>> in the network but only the MN's stack.  This is a significant
>> advantage in terms of applicability until more radical DNA
>> techniques establish themselves.
> 
> 
> ok. glad to hear that.
> 
> 
>> ++++ The host forms the prefix list at any attachment point, that
>> is, this process starts independently of any movement.  Though the
>> procedure may take some time, that doesn't matter unless the host
>> moves very fast.  A host can generate the complete prefix list with
>> reasonable certainty if it remains attached to a link sufficiently
>> long.  It will take approximately 12 seconds, when it actively
>> perform 3 RS/ RA exchanges.  If it passively relies on unsolicited
>> RA messages instead, it may take much more time. ++++
>> 
>>  unsolicited RAs every 30ms to 70ms as proposed by RFC 3775
>> (because such RA might not have all of the prefixes included).  But
>> since this high frequency would obviously improve the situation for
>> CPL, it might be worthwhile to put a note into the draft.
> 
> 
> ok.
> 
> I think it is ok for a host to send 1 RS and waits for 4 secs to
> collect (solicited) RAs and declare its prefix list (CCL) complete.
> 
> Even some packet loss may cause an incomplete prefix list, there is a
> further chance for the host to get the missing prefixes before it
> receives link UP notification, i.e. moves to another AP.
> 
> Even the host moves to another AP with incomplete prefix list, the
> first RA may contain the prefix in its prefix list.
> 
> Considering all those above, even if the host performs only one RS/
> RA exchange, it will be very rare for the host to falsely assume a
> link change. Even in case of such a false assumption, there will not
> be a communication disruption but only unnecessary signaling.
> 
> So I think such an occasional unnecessary signaling is acceptable and
> 1 RS/ RA exchange is enough for the complete prefix list generation.
> 
> How do you think of it?
> 
> 
>> experimental tests to find out how well CPL works when MNs move
>> really fast.  Well, maybe this can be done on a theoretic basis
>> like the Performance Analysis in section 9.
> 
> 
> We have an implementation plan but didn't think much about the fast
> moving MN case yet.
> 
> 
>> I do understand that CPL is 100% reliable, even in high-speed
>> scenarios, when the prefix sets in RAs from the same link are
>> guaranteed to overlap.
> 
> 
> This is a very good point, really an acute observation. Thanks. Yes,
> there will no mistakenly assuming a link change because of common
> element (prefix) in (any two) RAs.
> 
>

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 31 May 2005 10:00:12 +0900

Dear Christian

> was, it might be good to put a link into your document.

No, AFAIK. 

> Right, and it would be easy for network administrators to set IP links

I guess, yes, in the most cases. 
 
> complete prefix lists of any two routers on the same IP link do overlap.

I see.  

ok. 

ok. 
 
> of their RAs.  
 
I agree. For 100% certain CPL, 

in theory, it is enough that 
 
"Any two RAs in a link have A common prefix." 

But in practice, it would be better that

"All RAs in a link have THE common prefix." 

Let me underline the above with an example. 

Assume three RAs, RA[1], RA[2] and RA[3]. 

The first one means that any two RA[i] and RA[j] have a common prefix. 
But there may not be  a common prefix among all threee RAs.  

The second one even implies that. 

> And that would effectively be the Link ID proposal. ;)

Now I see much similarity between the above and LinkID draft. 
Thanks for a new insight. 

I'll think over their relationship. Also your feedback on LinkID 
draft will be of much help. 

Thanks in advance for your kind consideration. 

Best Regards

JinHyeock