Re: Reducing the battery impact of ND

[Ole Troan <[e-mail]>]

Erik,

>> To my mind, sending an RS when the RA lifetime is about to expire is a
>> robustness fix, not an efficiency fix. In a world where IPv6 is optional
>> and IPv4 is the main protocol, just having your IPv6 address expire is
>> not necessarily a problem. But in a world where IPv6 is the main
>> protocol, then hosts will probably want to try harder to keep their IPv6
>> address around.
> 
> Lorenzo,
> 
> Whether you call it "efficiency" or "robustness" doesn't make much difference from a technical or a process perspective.
> 
> The approach you advocate is insufficient to ensure better robustness for at least two reasons:
> - the lifetime(s) of the prefixes are independent of the lifetimes of the default routers. Hence in this approach a host can have default routers but no prefixes.
> - the reachability state in the NCEs is independent of the default router list - per RFC 4861 the router stays in the default router list even if it is unreachable. Thus your last router might be unreachable but with remaining lifetime - it was the next-to-last router in the list that was reachable.
> 
> Solving those without risking hosts sending lots of RSs during failure events or resulting in a steady state of RSs from hosts seems tricky.
> 
>>    FWIW I don't have a problem with an opt-in update to 4861. I even
>>    think efficient-nd is the way to go because it reduces overall ND
>>    multicast traffic and not just your narrow focus on mobile phone
>>    battery life.
>> 
>> 
>> The tradeoff is that efficient ND adds more state to the network about
>> host addresses and changes a pretty core part of the IPv6 specs. I think
>> that if we can reduce the battery impact of multicast traffic, we will
>> have fixed most of the problem without doing either of those, and to my
>> mind, that's a much better tradeoff.
> 
> Changing from periodic RAs to (effectively) periodic RSs as you propose would change RFC 4861 is a very fundamental way.
> 
> It may or may not be the right thing to do for the future, but I think that requires a bit more work then forcing some edits into a document which has almost completed the WG process. I think resilient-rs has significant benefits in its current form and scope.

not trying to speak for Lorenzo, but I don't think he is proposing replacing periodic RAs with periodic RSs.
example: a host successfully does router discovery. RA lifetime is relatively short, e.g. 3 * router advertisement interval.
host doesn't receive any of the multicast RAs (network drops them or whatever).

what would be the best behaviour for the end-user?
a) host sits quietly and waits for a periodic RA
b) host restarts the initial router discovery

cheers,
Ole