Re: Reducing the battery impact of ND

[Erik Nordmark <[e-mail]>]

On 1/22/14 3:41 PM, Ole Troan wrote:
> I cannot claim credit for cooking up that dish. aren't you proposing 
> to do exactly that, replace periodic RAs with periodic RSs in: 
> draft-chakrabarti-nordmark-6man-efficient-nd 
Ole,

The difference is between trying to replace periodic RAs by adding 
periodic RSs from all the hosts, but still needing the periodic RAs 
versus actually removing the need for periodic and muticast RAs.

efficient-nd has the hosts tell the routers "I don't need a periodic RA" 
by the hosts including the ARO.
Thus even on a potentially mixed link, the routers can be smart.

But trying to accomplish the same thing without some additional 
information in the packets can't remove the periodic RAs as far as I can 
tell - it can only add load.
>>> 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).
>> You are speculating about some particular failure or misfeature in the network that makes it (persistently? sometimes?) drop multicast RAs. It would be good to flesh out that particular failure mode to see
>> - whether it is realistic, and
>> - what impact it has elsewhere.
> it's relatively trivial to reproduce, but I suppose you can argue that setting timers that way is a misconfiguration.
> 802.11 networks are multicast challenged, so I would expect drops to be somewhat common.
> a more robust RS retransmit mechanism will help that somewhat.
Occasional loss is handled by having the period RA timer be less than 
the default router lifetime (by 3x in the default values). Thus some RAs 
can be lost without any effect. If your multicast loss rate is higher 
than the config on the routers can change that ratio.

Using unicast RSs could be more efficient (FWIW resilent-rs is about 
multicast RS - hard to know what proposal we are talking about when 
there isn't an actual complete proposal written up). But if the 
multicast period RAs have to be there to handle unmodified hosts you 
haven't gained much.
>> For instance, the failure could be that all ICMP packets to the host are dropped (due to some misconfigured security policy - we've seen those in IPv4). That would drop unicast RAs as well, and affect the old path MTU discovery protocol.
>>
>> Or it could be that link-local multicast is misconfigured or broken, resulting in DNSSD and other protocols breaking.
>>
>> Having every host on the planet send a RS every 30 seconds "just in case" doesn't sound helpful.
> true, although it wouldn't be 'just in case'. I think you are making a good argument that the current RS/RA mechanism is designed quite well.
I'm merely arguing that it has a consistent design - worked well on 
yellow coax Ethernet.
A different consistent and complete design might make sense for today's 
more multicast challenged networks.

But I don't think that is just a tweak here and there - it would be a 
different design.
I've been exploring this space for a while (starting in 6lowpan) and I'd 
be interested in working out a different design.
There are ideas in efficient-nd, but that isn't complete.

The frustrating thing is that the same folks that argue that the WG 
shouldn't work on a different design (targeting multicast challenged 
links), keep on suggesting tweaks. If the WG thinks we should work on 
improving ND for such links (and perhaps also improve it for battery 
operated hosts), then let's do that work. If not, then let's stop 
suggesting tweaks.

    Erik