Re: [DNA] Alternatives to "just send RS" when DNA starts

[Christian Vogt <chvogt@tm.uka.de>]

Hi Thomas, hi Greg.

>>> I think 2461bis allows an immideate RS for mobile nodes.
>> 
>> Can you cite text? And I hope they don't make an exception just for
>>  "mobile nodes".
> 
> 
> 
> S6.3.7 draft-ietf-ipv6-2461bis-05.txt
> 
> In some cases, the random delay MAY be omitted if necessary. For 
> instance, a mobile node, using [MIPv6], moving to a new link would 
> need to discover such movement as soon as possible to minimize the 
> amount of packet losses resulting from the change in its topological 
> movement. Router Solicitations provide a useful tool for movement 
> detection in Mobile IPv6 as they allow mobile nodes to determine 
> movement to new links. Hence, if a mobile node received link layer 
> information indicating that movement might have taken place, it MAY 
> send a Router Solicitation immediately, without random delays. The 
> strength of such indications should be assessed by the mobile node's 
> implementation depending on the level of certainty of the link layer 
> hints and is outside the scope of this specification. Note that using
>  this mechanism inappropriately (e.g. based on weak or transient 
> indications) may result in Router Solicitation storms. Furthermore, 
> simultaneous mobility of a large number of mobile nodes that use this
>  mechanism can result in a large number of solicitations sent 
> simultaneously.


Unfortunately, there is some inconsistency with respect to exceptions
for "mobile nodes" in RFC2461/2462bis.  Specifically, mobile nodes
should still wait for up to 1 second before they send an MLD Report
message prior to DAD.  RFC2462bis specifies this in section 5.4.2:

   If the Neighbor Solicitation is going to be the first message to be
   sent from an interface after interface (re)initialization, the node
   SHOULD delay joining the solicited-node multicast address by a random
   delay between 0 and MAX_RTR_SOLICITATION_DELAY as specified in
   [I-D.ietf-ipv6-2461bis].  This serves to alleviate congestion when
   many nodes start up on the link at the same time, such as after a
   power failure, and may help to avoid race conditions when more than
   one node is trying to solicit for the same address at the same time.

   Even if the Neighbor Solicitation is not going to be the first
   message to be sent, the node SHOULD delay joining the solicited-node
   multicast address by a random delay between 0 and
   MAX_RTR_SOLICITATION_DELAY if the address being checked is configured
   by a router advertisement message sent to a multicast address.  The
   delay will avoid similar congestion when multiple nodes are going to
   configure addresses by receiving the same single multicast router
   advertisement.

There was quite a long discussion about this on the IPv6 mailing list
[1].  The conclusion was eventually to leave "real" mobility
optimizations to DNA.

Regards,
- Christian

[1]  "Comment on RFCs 2461bis and 2462bis",
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html

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



Greg Daley wrote:
> Hi Thomas,
> 
> Thomas Narten wrote:
> 
>> JinHyeock Choi <jinchoe@gmail.com> writes:
>> 
>> 
>>>> 2) Upon "link up", does DNA need to delay sending an RS per the
>>>>  2461/2462 rule? Are there ways to relax this that are
>>>> consistent with the original concerns that led to the existing
>>>> wording in 2461/2462?
>> 
>>> I think 2461bis allows an immideate RS for mobile nodes.
>> 
>> Can you cite text? And I hope they don't make an exception just for
>>  "mobile nodes".
> 
> 
> 
> S6.3.7 draft-ietf-ipv6-2461bis-05.txt
> 
> In some cases, the random delay MAY be omitted if necessary. For 
> instance, a mobile node, using [MIPv6], moving to a new link would 
> need to discover such movement as soon as possible to minimize the 
> amount of packet losses resulting from the change in its topological 
> movement. Router Solicitations provide a useful tool for movement 
> detection in Mobile IPv6 as they allow mobile nodes to determine 
> movement to new links. Hence, if a mobile node received link layer 
> information indicating that movement might have taken place, it MAY 
> send a Router Solicitation immediately, without random delays. The 
> strength of such indications should be assessed by the mobile node's 
> implementation depending on the level of certainty of the link layer 
> hints and is outside the scope of this specification. Note that using
>  this mechanism inappropriately (e.g. based on weak or transient 
> indications) may result in Router Solicitation storms. Furthermore, 
> simultaneous mobility of a large number of mobile nodes that use this
>  mechanism can result in a large number of solicitations sent 
> simultaneously.
> 
> 
> [cut]
> 
>>> In case a host moves to a new link, it needs an RA for new 
>>> configuration anyway, so it seems reasonable to send RS in 
>>> anticipation of a link change. Also if you use unicast meessage
>>> to known destinations, no reply will come when you have moved to
>>> a new link. This will result in delay since you can't but rely on
>>> timeout to detect a link change.
>> 
>> But one can also imagine parallel approaches. E.g, for the default 
>> routers on the list, measure the actual observed RTTs during NS/NA 
>> exchanges. Then, for DNA, send out an NS, using that RTT as an 
>> estimate of how long you are willing to wait (and I'd expect this
>> to be very short, like 10ms or less). If that doesn't work, then
>> fall back to RS. One can imagine other optimizations.
>> 
> 
> 
> Such an optimization may work, but its effectiveness is dependent on
> topology (single cell links would experience longer delays), and the
> amount of time available to upper-layer applications (for example,
> voip).
> 
> It makes sense to mention this idea as an optimization to reduce the
> effect of multicasts on the link-layer.  I'd suggest inclusion of a
> tentative link-layer address option, as the source address of the NS
> is likely to be considered optimistic for DAD purposes (it may not
> help, but may avoid the reverse NS/NA exchange if the router doesn't
> have the host in the NCE).
> 
> How about:
> 
> "... Multicast transmission has been shown to increase bandwidth 
> consumption on certain wireless media at a rate much greater than
> that caused by unicast transmission.   On such media, it MAY be
> useful to send a unicast NS transmission to the global address of one
> of the configured routers upon reception of a link-layer hint.  This
> would avoid transmission of a multicast Router Solicitation if the
> router was available. The RS could then be delayed for an interval
> corresponding to the duration required to receive the unicast NA, if
> the router is still reachable.
> 
> This optimization is dependent on topology, and increases delay and
> packet transmission if the link is composed of a single cell. 
> Additionally, hosts with applications that are not able to delay for
> the lost NA in case of link-change SHOULD use RS instead. ..."
> 
> 
> Sending to the link-local address is insufficient, as some devices
> have been known to share a MAC address across different NICs, and
> CGAs with common public keys will be the same for two interfaces on
> one router, as the link-local prefix and key are the same.
> 
> Actually, if the NS contained a landmark option and the router was a
> known DNA router, you could send to any address.
> 
> Greg