Lorenzo,

I think we have to ensure that the specifications work for all kinds of 
devices. take a bath scale for example, that’s essentially disconnected until 
someone steps on it. there are going to be levels of deep sleep.

this particular case though sounds like a software bug, rather than an IETF RFC 
bug.

cheers,
Ole

> On 12 Jun 2015, at 10:11 , Lorenzo Colitti <[email protected]> wrote:
> 
> On Fri, Jun 12, 2015 at 4:54 PM, Ole Troan <[email protected]> wrote:
> > That sounds like a bad idea. If devices send an RS every time the user 
> > turns the screen on, and the router responds with a multicast RA, any 
> > medium-size network or larger will have multicast RAs flying around every 3 
> > seconds and killing everyone's battery.
> 
> then it turns into a silly race… the network is forced to send RAs at very 
> high frequency, because hosts that wake up with expired routers, don’t RS…
> 
> No, that's not what it turns into.
> 
> The right way to do this is for the network to send periodic RAs at a 
> reasonable interval - say, 10 minutes - and for the hosts to wake up when RAs 
> arrive, process them, and go back to sleep.
> 
> This is already how things work. Wifi chipsets already have to wake up every 
> few tens/hundred of milliseconds ms to listen for multicast packets. Hosts 
> already need to wake up when they receive unicast packets (well - on some 
> manufacturers, only unicast IPv4 packets :-)), because people want to receive 
> chat messages when the device is asleep. Hosts also need to reply when they 
> receive broadcast ARP  - because otherwise the link routers can't to talk to 
> them, and they users can't receive chat messages.
> 
> There is plenty of battery power even on a watch to wake the CPU up once 
> every 10 minutes - in fact, it's probably awake much more often than that 
> already
> 
> The only thing required to make this work well is that if a network has 
> hundreds or thousands of nodes per subnet, then it must send solicited RAs 
> unicast.
> 
> do we agree that a host that wakes up and has expired its last default router 
> should restart router discovery?
> 
> That's not necessary. For things to work well a host needs to be able to 
> maintain connectivity even when asleep. So it needs to be able to receive 
> unicast packets, and it needs to process RAs (e.g., so it can know that it 
> has lost connectivity when it receives an RA with a default lifetime of 0). 
> If it is processing RAs, then its RA will not expire.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to