draft-ietf-dna-cpl-02.txt

JinHyeock Choi <jinchoegmail.com> writes:

> > But, the current document includes a number of
things that I am not
> > sure are needed at all, and some that I think are
backwards.
> >
> > 1) the document is rather long and verbose. I
actually find the text
> >   somewhat hard to follow, since the discussions
seems fairly lengthy
> >   given what I understand to be a fairly simple
algorithm.
> >
> >   For example, it talks about numbers of times to
transmit things,
> >   etc. I think this is all covered in 2461/2462
and shouldn't be
> >   mentioned here (I find it confusing to read
about it because I'm
> >   not sure what is "new" to DNA vs. what
is just being taken from
> >   other documents and should already be existing
practice).

> We try to make a host correctly declare a link change
when it receives
> an RA with only unknown prefixes. Without maintaining
the Complete
> Prefix List, that would be difficult.

rereading section 4.5:  Receiving valid Router
Advertisements,

I'm (generally) fine with the first part of this section.
I.e., it
says that when a host receives the first RA (after a link up
event):

1) if it contains a prefix in the CCL, assume no link
change.

2) if it contains a prefix in retained Candidate Link
Object, assume
   host has moved back to that link.

The interesting case is where one receives an RA containing
only
prefixes that one has not seen before. It is this case that
makes use
of the "complete" state. I.e., if the CCL is
complete, one assumes
that learning a new prefix means an immediate move. But if
the CCL is
not complete, one doesn't assume one has moved (yet).
Specifically:

>  However, it does not yet treat this as a new link; it
is merely a
>  candidate.  Thus it MUST NOT perform the actions in
Section 4.6 at
>  this point in time.  Instead, the host should wait for
MAX_RA_WAIT
>  seconds, and all RAs that are received during that
time interval are
>  processed as specified above.

>    This processing might result in finding a prefix in
common between a
>    Candidate Link object and the CCL, in which case the
host knows
>    whether and to which link it has moved.  But should
the MAX_RA_WAIT
>    seconds expire without any common prefix, then it
will conclude that
>    it has moved to a new link and inform the rest of
the host of the
>    movement (Section 4.6.) 

Could you clarify for me how the above relates to normal
2461/2462
processing? I.e., I would assume that the new prefix should
be
configured on the link immediately. Is this the case?

Also, I'm not sure it's worth the complexity of waiting
another 4
seconds to gather additional RAs before declaring a move.

Or maybe I don't understand what it means to "declare a
move" and what
impact that has on the addresses configured on the
interface. This
goes back to my message yesterday asking what processing we
are
assuming happens upon a "link down" event.

Given that as far as we know,  most RAs include complete
information,
why go to so much trouble to handle the case where this is
not the
case, and where the cached information is
"incomplete" (which also is
probably not the normal case), etc.

I agree that having a Complete Prefix List would be good, in
the sense
that upon receipt of an RA, one is more likely to make a
correct
determination about whether one has rejoined an existing
link.

However, the current document formalizes this too much,
including
algorithms that are used to (in some sense)
"declare" when one has a
complete list as opposed to maybe not having a complete
list. I'm just
not convinced (yet) that this complexity has sufficient
benefit in
practice.

> > 4)  3.2  Erroneous Prefix Lists
> >
> > >    The host may generate either 1) the
Incomplete Prefix List, i.e. the
> > >    prefix list that does not include all the
prefixes that are assigned
> > >    to the link or 2) the Superfluous Prefix
List, i.e. the prefix list
> > >    that contains some prefix that is not
assigned to the link.
> >
> > How does this happen? why should we worry about
this case? 2461/2462
> > doesn't...

> The Incomplete Prefix List may result from packet
losses and the
> Superfluous Prefix List may result from the node
mistakenly combines
> the prefixes from different links to produce a single
list. The first
> may make a node mistakenly assume it has moved to a
different link,
> whereas the second may make a node mistakenly assume it
remains at the
> same link.


> > >    work.  Thus the host needs to create a new
Candidate Link object
> > >    based on the received RA, and make this
object the CCL.  However, it
> > >    does not yet treat this as a new link; it
is merely a candidate.
> > >    Thus it MUST NOT perform the actions in
Section 4.6 at this point in
> > >    time.  Instead, the host should wait for
MAX_RA_WAIT seconds, and all
> > >    RAs that are received during that time
interval are processed as
> > >    specified above.
> >
> > Again, I think this logic is wrong (and too
complex). You always
> > assume a link is new as a starting point...
> >
> > or:
> >
> > >    Subject to local policy, and perhaps also
the host's knowledge of the
> > >    packet loss characteristics of the
interface or type of L2
> > >    technology, the host can try harder than
just waiting for MAX_RA_WAIT
> > >    seconds, by sending additional Router
Solicitations.  It is allowed
> > >    to multicast up to MAX_RTR_SOLICITATIONS
[1] RS messages spaced
> > >    RTR_SOLICITATION_INTERVAL apart.  In the
most conservative approach
> > >    this means a 12 second delay until the
host will declare that is has
> > >    moved to a new link.  Just as above, this
process should be
> > >    terminated should a new link UP
notification arrive during the 12
> > >    seconds.
> >
> > this seems overkill, as it doesn't take 12 seconds
to configure a link
> > in the first place... so why are we making this so
detailed/complex?
> > (and again why not just assume we are attaching to
a new link, unless
> > we learn otherwise?)

> We present this as the most conservative approach and
doesn't
> recommend it. Even without the Complete Prefix List, it
will take 4
> secs to finish DNA according to our recommendation.

So, it takes 4 seconds to complete  DNA? I thought the whole
point was
for DNA to complete quickly. Recall, using normal 2461/2462
in _MOST_
cases, a single RS will trigger the transmission of RAs from
_all_
routers, and this will complete within .5 seconds. Thus,
having DNA
operate for 4 seconds seems to miss the bigger picture.

Thomas

> > We present this as the most conservative approach
and doesn't
> > recommend it. Even without the Complete Prefix
List, it will take 4
> > secs to finish DNA according to our
recommendation.
>
> So, it takes 4 seconds to complete  DNA? I thought the
whole point was
> for DNA to complete quickly. Recall, using normal
2461/2462 in _MOST_
> cases, a single RS will trigger the transmission of RAs
from _all_
> routers, and this will complete within .5 seconds.
Thus, having DNA
> operate for 4 seconds seems to miss the bigger picture.

draft-ietf-dna-cpl-02 is for unmodified routers. Actual
DNAv6 draft
can be found at

http://www.ctie.monash.edu.au/dna-dt/
draft-pentland-dna-protocol3-pre02.txt

This protocol requires the modifications to both Routers (at
least one
on the link)
and Hosts.

With this protocol, the host can make a link change decision
with one
RS/RA exchange. This draft also defines Fast RA, which
ensures that
two routers will not respond at exactly the same time while
allowing
one of the routers on the link to respond immediately.


From the draft-ietf-dna-cpl-02
...
   MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5
Sec)
   + network propagation delay is the maximum delay between
an RS and
   the resulting RAs [1]. 4 seconds would be a safe number
for the host
   to wait for the solicited RAs.  Assuming no packet loss,
within 4
   seconds, the host would receive all the RAs and know all
the
   prefixes.  Thus we pick 4 seconds as the value for
MAX_RA_WAIT.
...

An implementation, may choose to compare the prefixes as and
when
it receives an RA, if there is a common prefix, host can
make the
decision that it is at the same link and need not wait for 4
sec.
4 sec wait may be required for the cases where there is a
link change.

In most cases if the RA contains all the prefixes, the
receipt of first
RA is sufficient to check for link change. In such cases a
host can
wait for 4 sec to receive an RA, at that time the host can
resend
the RS (the first RS might not have reached the router).

- Syam

Dear Thomas

> >  However, it does not yet treat this as a new
link; it is merely a
> >  candidate.  Thus it MUST NOT perform the actions
in Section 4.6 at
> >  this point in time.  Instead, the host should
wait for MAX_RA_WAIT
> >  seconds, and all RAs that are received during
that time interval are
> >  processed as specified above.
>
> >    This processing might result in finding a
prefix in common between a
> >    Candidate Link object and the CCL, in which
case the host knows
> >    whether and to which link it has moved.  But
should the MAX_RA_WAIT
> >    seconds expire without any common prefix, then
it will conclude that
> >    it has moved to a new link and inform the rest
of the host of the
> >    movement (Section 4.6.)
>
> Could you clarify for me how the above relates to
normal 2461/2462
> processing? I.e., I would assume that the new prefix
should be
> configured on the link immediately. Is this the case?

The new prefix is immediately assumed to be assigned on the
currently
attached link (which is obvious). Main issue is what we will
do with
the existing prefix list.

In case the host remains at the same link, the new prefix is
added to
the existing prefix list. In case of a link change, the host
makes a
new prefix list with the new prefix.

> Also, I'm not sure it's worth the complexity of waiting
another 4
> seconds to gather additional RAs before declaring a
move.
>
> Or maybe I don't understand what it means to
"declare a move" and what
> impact that has on the addresses configured on the
interface. This
> goes back to my message yesterday asking what
processing we are
> assuming happens upon a "link down" event.

When a host declare a move, it should discard current IP
configuration
information such as IP address. Declaring a move implies not
only the
host's existing link is down but also the host  is attached
to a
different link. So on the currently attached link, the host
can't use
its existing configuration information and needs new one.
The host
should configure a new IP address and re-establish its TCP
connections
(assuming no MIPv6).

> Given that as far as we know,  most RAs include
complete information,
> why go to so much trouble to handle the case where this
is not the
> case, and where the cached information is
"incomplete" (which also is
> probably not the normal case), etc.
>
> I agree that having a Complete Prefix List would be
good, in the sense
> that upon receipt of an RA, one is more likely to make
a correct
> determination about whether one has rejoined an
existing link.
>
> However, the current document formalizes this too much,
including
> algorithms that are used to (in some sense)
"declare" when one has a
> complete list as opposed to maybe not having a complete
list. I'm just
> not convinced (yet) that this complexity has sufficient
benefit in
> practice.

Usually a host will keep the Complete Prefix List and check
for link
change with just one RA. Most complexity is from maintaining
Complete
Prefix List to make DNA more precise/ stable.

> > We present this as the most conservative approach
and doesn't
> > recommend it. Even without the Complete Prefix
List, it will take 4
> > secs to finish DNA according to our
recommendation.
>
> So, it takes 4 seconds to complete  DNA?

This is the worst case, an upper bound. In general DNA will
be
completed upon the receipt of the first RA.

> I thought the whole point was
> for DNA to complete quickly. Recall, using normal
2461/2462 in _MOST_
> cases, a single RS will trigger the transmission of RAs
from _all_
> routers, and this will complete within .5 seconds.
Thus, having DNA
> operate for 4 seconds seems to miss the bigger picture.

I agree that DNA is to complete quickly but think it also is
to decide
correctly. We aimed both Speed and Precision (sounds like a
NIKE ad.
)

Usually Speed and Precision is in a kind of trade off, the
quicker you
decide, the less precise the decision. We try to strike a
healthy
balance between them.

To increase the speed, we may make the policy that the host
makes a
decision upon receiving the first RA (even without the
Complete Prefix
List). But that will decrease the precision and may result
in falsely
declaring a move. When a host declare a move, it should
discard its IP
address and tear down TCP connections. Hence we recommend a
different
policy for the host to wait up till 4 secs (this is upper
bound) to
enhance the precision. It may worthwhile to wait a few
additional
seconds instead of instantly jumping to the conclusion and
tearing
down all TCP connections.

Thanks for your kind consideration.

Best Regards

JinHyeock

Thomas Narten wrote:

> rereading section 4.5:  Receiving valid Router
Advertisements,
> 
> I'm (generally) fine with the first part of this
section. I.e., it
> says that when a host receives the first RA (after a
link up event):
> 
> 1) if it contains a prefix in the CCL, assume no link
change.
> 
> 2) if it contains a prefix in retained Candidate Link
Object, assume
>    host has moved back to that link.
> 
> The interesting case is where one receives an RA
containing only
> prefixes that one has not seen before. It is this case
that makes use
> of the "complete" state. I.e., if the CCL is
complete, one assumes
> that learning a new prefix means an immediate move. But
if the CCL is
> not complete, one doesn't assume one has moved (yet).
Specifically:
>
> [...]
> 
> Could you clarify for me how the above relates to
normal 2461/2462
> processing? I.e., I would assume that the new prefix
should be
> configured on the link immediately. Is this the case?

We tried to make it clear that the host needs to separately
track the 
prefixes it received before the link up and those that were
received 
after, so that no matter what it does on the reception on
the RA it can 
do the right thing should it later determine that it indeed
moved to a 
different link.

Thus an implementation could immediately add the prefix to
the current 
set of prefixes. But then should it determine that it did
move to a 
different link it needs to remove that prefix from the old
candidate 
link object, and only use that prefix in the new candidate
link object.

Alternatively, an implementation could defer doing anything
with the new 
prefix until DNA has completed. Then, if the host didn't
move to a new 
link, it would add the prefix to the current list of
prefixes. And if it 
did move to a different link it would know to only use the
new prefix as 
the initial prefix list for that link.

> Also, I'm not sure it's worth the complexity of waiting
another 4
> seconds to gather additional RAs before declaring a
move.

Yes, but this is an unfortunate side effect of the
generality of how 
prefixes can be advertised in RFC 2461/62. We know who to
blame for that 
generality 

> Or maybe I don't understand what it means to
"declare a move" and what
> impact that has on the addresses configured on the
interface. This
> goes back to my message yesterday asking what
processing we are
> assuming happens upon a "link down" event.
> 
> Given that as far as we know,  most RAs include
complete information,
> why go to so much trouble to handle the case where this
is not the
> case, and where the cached information is
"incomplete" (which also is
> probably not the normal case), etc.

FWIW this observation was what lead to one of the early
proposals by 
JinHyeock for how to make DNA better - just including a
"this RA is 
complete" bit in the Router Advertisement.

> I agree that having a Complete Prefix List would be
good, in the sense
> that upon receipt of an RA, one is more likely to make
a correct
> determination about whether one has rejoined an
existing link.
> 
> However, the current document formalizes this too much,
including
> algorithms that are used to (in some sense)
"declare" when one has a
> complete list as opposed to maybe not having a complete
list. I'm just
> not convinced (yet) that this complexity has sufficient
benefit in
> practice.

The notion is really more probabilistic than "know for
sure" vs. "don't 
know yet". But in terms of the resulting behavior,
there is a point 
where the host behaves as if it knows all the prefixes for a
link, hence 
the "declare" aspect seemed to help when
describing the behavior. If it 
doesn't help, we can certainly revisit the description.

> So, it takes 4 seconds to complete  DNA? I thought the
whole point was
> for DNA to complete quickly. Recall, using normal
2461/2462 in _MOST_
> cases, a single RS will trigger the transmission of RAs
from _all_
> routers, and this will complete within .5 seconds.
Thus, having DNA
> operate for 4 seconds seems to miss the bigger picture.

If we want reasonably robust and fast DNA, we do need some
changes in 
the routers behavior.

If we had a time machine and could go back and mandate in
RFC 2461/62 
that the list of prefixes each router advertises on the link
MUST be 
identical, and that all prefixes for the link MUST fit in a
single 1280 
byte RA, then we could assume that every RA is complete.

But given that 2461/62 doesn't mandate that, we sort of have
to deal 
with what's might be out there.

    Erik