Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

[Erik Nordmark <[e-mail]>]

On 4/27/15 8:27 AM, Erik Kline wrote:
> A question comes to mind: what might the operational guidance be for
> setting the refresh timer value in the RA?
>
> Observation: it almost certainly shouldn't be /longer/ than the router
> lifetime, even if the prefix lifetimes are infinite.
>
> Reasonable stab in the dark: refresh timer value in the RA should be
> in the neighborhood of some fraction (1/2, 2/3) * min(router lifetime,
> prefix lifetimes...).
>
> If that turns out to be the case, then the host can compute this timer
> value for itself, sleep on its own schedule, and wake up whenever it
> wants and send a unicast RS.  At that point this isn't a protocol
> change but rather an operational document.  [1]
>
> At the very least, this is a simple enough experiment to perform for
> people writing the code on the affected devices (doesn't require
> router vendor code changes).  Has anybody done this and measured the
> outcome?
Erik,
the above wouldn't work because a RFC 4861 compliant router can delay 
sending the solicited RA (and multicast it) hence the host would have to 
wait for seconds with (at least) the radio powered on when it otherwise 
would have gone back to sleep after a few milliseconds.

That RA delay is why rs-refresh says that routers which implement the 
specification should unicast the solicited RAs immediately. Furthermore, 
the RTO option indicates to the hosts that the routers are in fact 
implementing rs-refresh which includes the immediate RA response.

That should all be covered in the document; I don't know if you've read 
it and understood it. I'd welcome suggestions for how to make this more 
clear if it turns out that it is not.

As an aside, you seem to think that a protocol specification is merely 
about packet formats. However, protocol specifications include 
behaviors, protocol constants, default values, statements about what is 
mandatory to implement etc.
The behaviors might be things that are conditionally mandatory or 
recommended i.e., of the form "if you implement option foo, then you 
SHOULD use binary exponential backoff for the retransmit timer."

Do you have any technical issues for the WG not pursuing this work?
Any non-technical reasons why not?
Please provide sufficient detail so that the WG can properly evaluate 
your concerns.

Thanks,
    Erik


>
> -Erik the Lesser
>
>
> [1]  Note that the node MUST to be ready to basically re-attach from
> scratch in the event that the router has gone (I swapped my IoT device
> access point for a new model, and it got a new prefix too, while
> everyone listening was asleep, for example).  So guessing a wrong
> timer value must be non-fatal for the node.  At worst it won't be
> "optimal" but i'm curious to know what the impact of deviation from
> "optimal" would really be in these networks, given that nodes are all
> going to go for the longest possible timer value.
>