Re: [DNA] Scope of solutions discussion document

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Hi Sathya,

Using your approximation, then the order of magnitude of the probability
of encountering the 4 second delay is the same as the probablility of
packet loss.  Whether this is a problem or not depends on what cost is
applied to a slow detection.  What's a reasonable packet loss rate to
consider?  10^-3?  A slow detection every thousand or so.  Is that too
bad?  It may be for some applications; I'm not sure.

As Greg mentioned, there may be scope to modify the behavior.  Perhaps
some kind of exponential backoff rather than a fixed 4 second delay?

Brett.

Sathya Narayanan wrote:
> 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
>>>
> 

-- 
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Brett Pentland                  brett.pentland@eng.monash.edu.au
  CTIE - Centre for Telecommunications and Information Engineering
  Department  of  Electrical  and   Computer  Systems  Engineering
  Monash University, VIC, 3800,                          Australia
  Phone : +61 3 9905-5245                    Fax : +61 3 9905-3454
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~