Re: [DNA] Scope of solutions discussion document

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

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
>