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

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

Folks, 

This issue is now resolved.

Hesham

 > ----- Original Message ----- 
 > From: <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Tuesday, July 20, 2004 12:54 AM
 > Subject: [psg.com #256] Eliminate random delay in RS transmission
 > 
 > 
 > 
 > Issue:
 > -------
 > This issue was raised in order to speed movement detection
 > for mobile nodes. The random delay added before sending
 > router solicitation slows down movement detection significantly.
 > In Seoul, we agreed to allow the removal of this delay after
 > handovers.
 > 
 > Suggestion:
 > -----------
 > 
 > The current version of 2461bis contains the following text
 > in 6.3.7
 > 
 >    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.  This serves to alleviate 
 > congestion when
 >    many hosts start up on a link at the same time, such as 
 > might happen
 >    after recovery from a power failure.  If a host has 
 > already performed
 >    a random delay since the interface became (re)enabled 
 > (e.g., as part
 >    of Duplicate Address Detection [ADDRCONF]) there is no 
 > need to delay
 >    again before sending the first Router Solicitation 
 > message. 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
 >    and is outside the scope of this specification.
 > 
 > 
 > (I'll remove the non ASCII character in the next rev).
 > 
 > Hesham
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 
 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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