Re: [Efficientnd-dt] Food for thought - router-controlled RS refresh

[Erik Nordmark <[e-mail]>]

On 11/10/14 8:09 PM, Lorenzo Colitti wrote:
> On Wed, Aug 20, 2014 at 9:34 PM, Erik Nordmark <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Do folks think this is a reasonable starting point for some Design
>     Team output when it comes to RS/RA?
>     If so, should we include all the RS/RA pieces in one document?
>     (implementation advise, raise the max advinterval, etc)
>
>
> Finally found the time to take a look. I'm a bit concerned by the 
> following issues:
>
> 1. If sleepy nodes are free to ignore multicast RAs, that means that 
> it's no longer possible for the network to give hosts updated 
> configuration in a timely manner. This is a regression in 
> functionality that we should consider carefully. To my mind, if a host 
> is available to receive unicast packets, then it should also listen to 
> multicast RAs.

I forgot the terms we used to distinguish between hosts that wake up 
based on packets and those that wake up based on their timer. But the 
latter would receive neither unicast and multicast when asleep.

That doesn't mean that the network admin has no control.
The Refresh Time in the RTO places an upper bound on the time it takes 
to push out new information.

Example
  - At time=0 a RA with RTO=60 minutes is sent out - might be unicast in 
response to a RS from a sleepy node.
  - At time=1 minute something changes and the router multicasts an RA 
with some changes - but sleepy node is not awake
     (Presumably this RA retransmitted a few times per RFC 4861 to make 
non-sleepy nodes more likely to receive it)
  - Suppose sleepy node wakes up at time=40 minutes, then it will not 
send a RS refresh (it has 20 minutes left).
     But before t=60 minutes it will send a RS refresh and receive the 
changed information.
  - Suppose the node wakes up at time=70 minutes, then it will 
immediately send a RS refresh.

Thus in the worst case the RTO refresh time is an upper bound on the 
time it takes to push out new information.
But if the RTO refresh time is less than the sleep time for the sleepy 
nodes, then the sleepy nodes would always refresh on wakeup.


>
> 2. If periodic RAs are turned off, then "legacy" hosts will lose 
> connectivity. That seems bad. The current spec allows a maximum router 
> lifetime of 9000 seconds, right? If so, then operators today can 
> already set the RA period to something like 4450 seconds, which allows 
> the hosts to miss one RA without losing connectivity. Is one packet 
> every 75 minutes that bad?

The issue for hosts that sleep on a schedule is that they don't want to 
have an active receiver hence they can't receive a packet sent at some 
unknown point in time; requires having the receiver turned on all the 
time, or having some router/AP which queues packets reliably until they 
wake up.

Another concern was around the paging cost in cellular networks that is 
triggered by sending periodic packets to all hosts (we discussed a draft 
about this in Toronto). If instead the host wakes up and send a packet 
(an RS) it means that the network state has been established to know the 
hosts current base station etc.

Those are two different cases where the router initiated RA doesn't work 
well.

    Erik


>
> Cheers,
> Lorenzo