Re: [DNA] New I-D: draft-vogt-dna-relocation-00.txt

[Jari Arkko <jari.arkko@kolumbus.fi>]

Christian Vogt wrote:

>
> I do agree that the extent to which desynchonization should be performed
> is application- and environment-specific.  RFC246[12][bis] is tailored
> towards stationary nodes, so the delays of up to 1s
> (MAX_RTR_SOLICITATION_DELAY) are acceptable and make sense.  But we
> can't do VoIP for mobile nodes with such delays.

Right.

> The problem is that we cannot necessarily hard-code application- and
> environment-specific behavior into the nodes simply because we don't
> know a priori what the applications and environments will be.

Well, we could have (bad) default behavior and better, optimized
behaviour when the stack knows more about what's happening
underneath. But I agree that this is not the best possible solution.
What you describe below seems to work more universally.

> But maybe there may be a resort:
>
> I see a difference between messages for which collision is recoverable
> and messages for which it is not.  E.g., loss of a RS would simply be
> detected by the mobile node by lack of a responding RA.  So in the
> (unlikely) case that there was a collision, the mobile node loses some
> time, but will eventually retransmit the RS.  OTOH, loss of a MLD Report
> or NS sent during (O)DAD cannot be detected---because there is no
> expected response---and might lead to an address duplicate, which is NOT
> recoverable (in the case of RFC2462[bis]).

Right.

>
> But MLD Reports and NSs for (O)DAD can be retransmitted in background
> mode.  So an optimistic address would be considered unique only after
> two, three, or more transmissions of the MLD Report and NS resulted in
> no response.  In addition, there may be plenty of desynchronization
> delay because we are doing all this in background mode.

Ok, it makes a lot of sense. Thanks for explaining it.

>
> > Also, I find it curious that your conditions above don't call for the
> > same de-sync knowledge as the RFC 3775 text did. I'm not sure if it
> > is needed, just pointing out the difference...
>
> See above.  Maybe it makes sense to send non-critical messages (those
> for which collision is recoverable) immediately where possible, and to
> desynchronize and retransmit critical messages in background mode.

Ok.

--Jari