Re: [DNA] Scope of solutions discussion document

[Sathya Narayanan <sathya@research.panasonic.com>]

Hello Brett -

I agree - they are all 'SHOULDs' - but some information on the 
implementations will be useful?

The problem with RTR_SOLICITATION_INTERVAL is not only when a node is 
moving rapidly between links, it will also cause problems when there is 
packet loss. If the packet loss probability is p, then the prob of  a 4 
second delay being added will be (p + p^NR) where NR is the number of 
routers on the link that can respond. If NR is 1, the prob is 2p. I 
don't know if this is acceptable, so we can ignore this. My gut feeling 
is that we can not. We must be a bit more resilient to packet loss 
problems, 4 seconds is too much. I think it will be useful to 
differentiate the delay between re-transmission of RS becasue RA was not 
received, from delay between RS with a corresponding RA  and another 
following RS due to link trigger. In the later case, 4 second delay 
could avoid too many RS message due to fluctuating wireless link signal.

And, I agree,  MAX_RTR_SOLICITATION_DELAY is the trickier one.

rgds,
Sathya

Brett Pentland wrote:

> Hi Sathya,
>
> I seem to remember some discussion on this on the old mobile-ip list
> some time ago, but I don't think there were any concrete conclusions.
>
> As you say, they are all "SHOULDs" so there's no immediate show
> stoppers, but all should be considered carefully.
>
> MAX_RTR_SOLICITATIONS is not really an issue, since the section also
> says later:
>
>    Once the host sends a Router Solicitation, and receives a valid
>    Router Advertisement with a non-zero Router Lifetime, the host MUST
>    desist from sending additional solicitations on that interface, until
>    the next time one of the above events occurs.  Moreover, a host
>
> where the "above events" include attaching to a link for the first time.
>
> RTR_SOLICITATION_INTERVAL could potentially slow things down if a host
> is moving rapidly between links (less than 4 sec on a link), however the
> text doesn't seem to say that "a host can never send RSs spaced closer
> RTR_SOLICITATION_INTERVAL".  The implication seems to be that when a
> host is trying to get an RA on a link, it should space its RSs by
> RTR_SOLICITATION_INTERVAL until it gets an RA and then stop.  If it
> got a hint that it had moved to a new link, it could start the whole
> process again.  At least that's my interpretation.
>
> MAX_RTR_SOLICITATION_DELAY is a trickier one.  As you note it is a
> "SHOULD" delay.  Perhaps on power-up a host might delay, but not when
> movement is detected, but still doesn't address the issue of a whole
> lot of mobile nodes in a fast moving vehicle.  I think Greg has done
> some simulations on groups of nodes moving at once and may have some
> comment to add.
>
> Cheers,
> Brett.
>
> Sathya Narayanan wrote:
>
>> Brett -
>>
>> <snip>
>>
>>> The basic asssumptions that we made were that: - hints from layer 2
>>> would be available to trigger router solicitations
>>
>>
>> I was thinking about this particular assumption we made while driving
>> to work today. I checked 2461 and in section 6.3.7, the following
>> statements are made:
>>
>> "To obtain Router Advertisements quickly, a host SHOULD transmit up
>> to MAX_RTR_SOLICITATIONS Router Solicitation messages each separated
>> by at least RTR_SOLICITATION_INTERVAL seconds."
>>
>> and " 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."
>>
>> What does 'initial solicitation' mean in ,'Before a host sends an
>> initial solicitation ...'? - does this refer to the RS sent when 'The
>> interface is initialized at system startup time' or 'The host
>> re-attaches to a link after being detached for some time'?
>>
>> The values for these three variables are: MAX_RTR_SOLICITATION_DELAY
>> 1 second RTR_SOLICITATION_INTERVAL         4 seconds 
>> MAX_RTR_SOLICITATIONS             3 transmissions
>>
>> The MAX_RTR_SOLICITATIONS limit is alright. But, the requirment to
>> delay between 0..1 seconds before sending RS, and maintain inter-RS
>> delay of 4 seconds, I think, will have a negative impact on rapid
>> DNA. BTW, both the restrictions are 'SHOULD's.
>>
>> Does it make sense to consider relaxing these conditions? 0..1
>> seconds delay restriction is useful though in avoiding congestion if
>> many hosts change their points of attachment at the same time.
>>
>> with regards, Sathya
>>