Subject: Re: [psg.com #256] Eliminate random delay in RS transmission

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 08 Aug 2004 21:11:59 +0900

>>>>> On Fri, 30 Jul 2004 00:15:20 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> This issue is now resolved.

(Sorry for the delayed response)

The suggested resolution basically works for me, but I'd reword the
text a bit.

First, the suggested text may provide the impression that the random
delay can be omitted *unconditionally* if it is just convenient
(mainly for mobile nodes).  But it should only be justified when
congestion of solicitations can be considered rare (e.g., when a
single node roams links).  I believe the new text should clarify the
justification.

I'd also move the added part to a separate paragraph (but it may be a
matter of taste).

So, I'd suggest the following:

   Before a host sends an initial solicitation, it SHOULD delay the
   transmission for a random amount of time between 0 and
   MAX_RTR_SOLICITATION_DELAY.  [...]
        ...
   again before sending the first Router Solicitation message.
(no change from RFC2461 so far)

   If the host knows the congestion is unlikely to happen, the host
   MAY omit the random delay 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.  Additionally, when the node (re)enables the interface
   after moving to the new link independently, there should be no
   worry about the congestion.  Hence, if such 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 and is outside the scope of
   this specification.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

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