Re: [DNA] Re: RS/RA Exchange

[Erik Nordmark <Erik.Nordmark@sun.com>]

> I like this idea.   I guess that the current FastRA draft
> is a less well specified version of this behaviour.
> even distribution when the delay has 10ms granularity may be 
> difficult to achieve in some OS's.  For Linux, the scheduling
> timer is run every 10ms.  Therefore the delay @10ms becomes a
> binary decision (delay or not).  If the clocks are sufficiently
> unsynchronized, then this is OK.  Perhaps it wouldn't be for
> similar devices which recently rebooted.  

I thought 1 ms timer granularity was common these days, but perhaps
is hasn't become the default.
You presumably need a bit of variation, but even a yes/no (0 or 10 ms
delay) when there are two routers might be sufficient.

> The random delay mechanism could actually be applied so that 
> the routers were ranked ( not sure how to do this ).
> The fastest router would never delay.  The next fastest would
> delay have a longer delay bound, the next may be double that 
> (or a constant addition) until the maximum bound was reached.
> say:  [0-0,0-100,0-200,0-400,0-600,0-600...]

I was thinking similar thoughts.
If the routers know how many routers are on the link they
could also maintain a sorted list (e.g. by sorting on the link-local addresses
of the routers) and respond to RS messages in turn instead of randomly.

  Erik