Re: [v6ops] new draft: draft-yc-v6ops-solicited-ra-unicast

On 18 July 2015 at 02:57, Andrew Yourtchenko <ayourtch@gmail.com> wrote:
>
> On 17 Jul 2015, at 09:34, Fred Baker (fred) <fred@cisco.com> wrote:
>
>>>
>>> So the next logical thing to do would be to have the router default to
>>> unicast Router Advertisements, measure the rate of received Router
>>> Solicitations, and switch to multicast RA mode past a certain
>>> threshold to cover this sort of situation. Once the number of RSes
>>> falls, it switches back to unicast RA mode.
>>>
>>> That would get rid of the configuration knob proposed in this ID, and
>>> is behaviour that I think could be universal for all link types,
>>> rather than just for the case of wireless ones with mobile devices.
>>
>> If it were me implementing it, I think I would go about this in a little different way, hopefully simpler. I would want to send at most one (e.g., either zero or one) RA per some interval (a second?). In the normal case, that is sent unicast. However, having sent a unicast RA at time t, if I now receive another RS before t+1, I send the next one (at time t+1) as a multicast.
>
> values of T less than 3 seconds would make performance worse than today.
>
> There are many things to optimize for:
>
> - wireless airtime
> - bandwidth used by RAs
> - CPU usage sending unicast RAs by router
> - energy consumption on devices for more than one medium
>
> Some of them are orthogonal, some of them contradict each other, some of them align. People may want to optimize differently.
>
> I'd opt for simplicity - and use the text Erik Kline posted in another email.
>
> This would allow the developers to adapt for individual use cases on the spot.
>

I think specifically calling out the above optimisation considerations
would be good to do in this draft.

While providing flexibility is useful to cover the unexpected, I also
think it is also important to have consistency. Specific case
optimisations can be beneficial, but they're also variations and
exceptions. The more variations and exceptions there are, the more
things people have to try to understand and remember, which makes then
makes configuration and troubleshooting harder.

So, for example, it would be good to have a consistent default
behaviour for all Wifi links (likely unicast solicited RAs, because
hosts (PCs, laptops, smartphones) come and go regularly), and a
consistent default behaviour for all wired links (likely multicast
solicited RAs, because hosts (servers) don't come and go regularly, so
the recovery from power outage scenario flood of RSes is the likely
common scenario for solicited RAs).

Regards,
Mark.

> --a
>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops