Re: [DNA] Re: RS/RA Exchange

[Greg Daley <greg.daley@eng.monash.edu.au>]

Erik Nordmark wrote:
>>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.

I agree, that in the case that we have only two routers,
the effect may not be very bad (so long as the media contention
doesn't cause packet loss: I'd guess modern MACs would be OK).

In this case, the binary decision has 50% chance of picking
the same number.  It makes as much sense to just allow two
routers to transmit simultaneously.

In general though, the scheduling is likely to be based on a
slotting mechanism.

The RS reception is synchronized, and all routers on a subnet may
be of the same manufacture.  In this case, they're likely to have
similar granularity for timers.

When we have fairly synchronized schedulers,
the transmissions on a particular slot may be
aligned enough to cause MAC contention.

If we were fairly sure that collisions with c RAs
on the same slot were OK, it would be possible to
provide a heuristic that minimized the chance
of collisions of order c.

If we're OK with 2 RA's going out at the same time,
it would be sufficient to provide schedules which
overlap such that a maximum of 2 devices could transmit
simultaneously.

Maximum of 1 is easier to justify to some people, though.

> 
>>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.

I think this is a good default strategy (link-local order).
Manually configured addresses are likely to be first, though.

Notably, older equipment from the same manufacturer is
likely to be selected first (same as in 802.1D STP root bridge
selection), if the link-local addresses are based on EUI/MAC.

So long as the routers know how many are in the ranked list, and
what position they are it's not a big problem, though reliability
of the highest ranked routers may be.

Router List membership could be secured with SEND.  There are
already mechanisms for determining routing authority in SEND.
It could be configurable policy to only believe authorized
routers.

In this case, the routers may have CGA addresses anyway so the
ordering of the link-local prefixes is fairly unpredictable
with regards to age and manufacture.

This may mean more processing work is done by a router if the same
CGA link-local address is used on multiple interfaces, and the
same selection criteria were used on both links.

I'd guess that the ordering and selection issue is a generic one.
It would be good if we didn't re-invent solutions.

The actual scheduling (apart from order) seems orthogonal.

Greg