Incremental De-sync. for OptiDAD? (was Re: Comment on draft-ietf-ipv6-optimistic-dad-06.txt)

[Christian Vogt <[e-mail]>]

Hi Nick.

> Ah, now, this is pushing the scope of OptiDAD, I feel.  Just as it
> has proven tricky to be sure if an address is "manually assigned"
> vs. assigned by a higher layer (or a script, or something), I think
> it'll be hard for our poor IPv6 stack to make this call.

I see, it's an implementation issue.

OTOH, our preceding discussion suggests that OptiDAD will not provide
much improvement if you stick to the delays for MLD Reports.  Let's
consider some options:

(1)  Omit the delays on MLD Reports during OptiDAD.

OptiDAD is likely to be used on mobile nodes, and mobility serves itself
as de-synchronization.  Even when a bus full of mobile nodes passes an
access point, the mobile nodes will still need different times until
they detect this and start IP reconfiguration.

(2)  Keep the delays, but allow immediate communications through the
Optimistic Address (OA).

True, as you said earlier, the Optimistic Node (ON) may not be able to
receive a neighbor's NS if it did not send an MLD Report.  Hence, the ON
may not be able to respond to incoming connections.  But this affects
neighbor-to-neighbor communications only.  If the ON is stationary, this
may be problematic only when the ON initially configures its addresses.
 I don't think that's important.  If the ON is mobile,
neighbor-to-neighbor communications are generally unlikely to be
important IMO.

(3)  Given that you cannot really know whether the ON is stationary or
mobile, the following may be a good approach:  Send the pair of MLD
Report and NS multiple times with incremental de-synchonization delays,
but allow for immediate use of the OA:

(a) Configure OA.  (Can be used immediately.)
(b) Wait for random value btw. 0 and 10ms.
(c) Send MLD Report plus NS.
(d) Listen for NAs for 100ms.
(e) Wait for random value btw. 0 and 100ms.
(f) Send MLD Report plus NS.
(g) Listen for NAs for 1000ms.
(h) Wait for random value btw. 0 and 1000ms.
(i) Send MLD Report plus NS.

This mechanism has the following properties:

- The OA can be used ASAP.
- When there is no collision, the ON will receive incoming on-link
communications already at step (4), i.e., after at most 10ms.
- The delays of 10ms, 100ms, and 1000ms could be chosen differently.
- The maximum de-synchronization delay of 1000ms is copied from
RFC2462[bis].
- Due to retransmissions, this procedure is MORE robust to collision and
packet loss than RFC2462[bis].
- There are four more local transmissions than in RFC2462[bis], however.
 If folks think this is a big issue, maybe its already ok to drop steps
(d) through (f).  That would leave two additional transmissions.

I'd actually go with option (3), because it gives you the efficiency you
need for mobile nodes plus the robustness you need for both mobile and
stationary nodes.  This comes at the cost of a little bit more overhead,
but such a trade-off is quite normal for optimizations like OptiDAD.

Regards,
- Christian

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



Nick 'Sharkey' Moore wrote:
> On 2005-10-31, Christian Vogt wrote:
> 
>>...there was consensus on the IPv6 mailing list [1] not to include any
>>specific support for mobility into the successors to RFC2461/2462.  At
>>least, this was said in the context of delays imposed on MLD Report
>>transmissions.
>>
>>(Note:  IMO, this is a bit of a bummer, [...]
> 
> 
> Agreed!
> 
> 
>>because RFC2461bis already
>>explicitly allows mobile nodes to forego the delay for Router
>>Solicitations; see section 6.3.7 in RFC2461bis.  So it could 
>>theoretically include an equivilant passage for the MLD Report, too. 
>>Anyway...)
> 
> 
> ... and I was kind of hoping it was going to, if only, as you
> point out, for consistency.
> 
> 
>>Instead, the discussion in [1] yielded that mobility optimizations ought
>>to be specified in separate documents.  And thinking about this, 
>>draft-ietf-ipv6-optimistic-dad-06.txt is actually one such document.  So 
>>it could/should allow Optimistic Nodes to forego the delays defined in 
>>RFC2461[bis] or RFC2462[bis] where necessary and feasible.
> 
> 
> Sure, I'd be happy to explicitly talk about it in OptiDAD if it's 
> not going to be mentioned elsewhere.
> 
> 
>>it is RECOMMENDED that the Optimistic Node omit such delays if 
>>sufficient means for de-synchronization are provided otherwise.  E.g., a 
>>mobile node can omit delaying the first message sent upon arrival at a 
>>new link [RFC2461] [RFC2462] because mobility generally serves to 
>>de-synchronize signaling to an appropriate extent already.  Care must be 
>>taken, however, not to confuse an initial link attachment after boot-up 
>>with a link attachment after movement."
> 
> 
> Ah, now, this is pushing the scope of OptiDAD, I feel.  Just as it
> has proven tricky to be sure if an address is "manually assigned"
> vs. assigned by a higher layer (or a script, or something), I think
> it'll be hard for our poor IPv6 stack to make this call.
> 
> This whole desyncronised handovers thing is what I was talking about
> with Hard/Soft handovers ... not sure who that idea came from 
> originally, mind you, or if it's been written up before or since.  
> Does the DNA stuff cover this?  If there's sufficient interest from
> IPv6 WG I guess we could write it up as a separate draft ... 
> 
> Sadly, it looks like I won't make Vancouver either.  On the offchance
> that anyone's disappointed by this, they should contact me with job
> offers (or handfuls of cash, either will do :-) ).
> 
> -----N



--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------