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

[Andrew 👽 Yourtchenko <[e-mail]>]

My brain can not compile this pseudocode...

reset_multicast_timer resets multicast_ra_time_remaining to what value ?

In the large-scale WiFi networks I operate I send multicast RA once in
30 minutes, and an immediate unicast solicited RA upon RS.

If the "reset" is done to the MinRtrAdvInterval...MaxRtrAdvInterval,
then this algorithm would optimize last 15 seconds of these 30 minutes
?

--a

On 7/21/15, Owen DeLong <[e-mail]> wrote:
> It seems to me that the following algorithm would be relatively easy to
> implement
> and provide reasonable network optimization…
>
>
> On receipt of an RS:
>
> 	if(multicast_ra_time_remaining > 15 seconds)
> 	{
> 	  Send_Unicast_ra
> 	}
> 	else
> 	{
> 	  Send_Multicast_ra
> 	  reset_multicast_timer
> 	}
>
> In this way, if the timing is reasonably close, you multicast a packet you
> were about to send
> anyway, but if the timing isn’t close, you’re not wasting multicast
> bandwidth answering a single
> node where nobody else cares.
>
> Overall, I’ve always thought that multicast response to RS was kind of
> silly. It’s probably most
> harmful on WiFi.
>
> Owen
>
>> On Jul 21, 2015, at 02:33 , Andrew 👽 Yourtchenko <[e-mail]>
>> wrote:
>>
>> On 7/20/15, Erik Nordmark <[e-mail]> wrote:
>>> On 7/17/15 9:34 AM, Fred Baker (fred) 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.
>>>
>>> First of all I support this document as a WG document.
>>>
>>> But in terms of implementation, isn't it simpler to always(*) respond to
>>> a RS with a unicast RA?
>>
>> Yes. I did not respond on-list yet - but from operational perspective
>> "always send solRA unicast" / "always send solRA multicast" definitely
>> wins in my book, and I'd avoid premature optimizations (but maybe we
>> can say the implementers are explicitly free to do their own
>> optimizations if they see fit)
>>
>> That said, will be very interesting to hear data from folks who will
>> run "all-unicast solRA", in real networks and then compare the effect
>> of their proposal optimizations on their real-world scenarios.
>>
>>> As background, the text in RFC4861 comes from the old concern that all
>>> devices might boot at the same time when the power is re-established
>>> after a building power failure; that doesn't happen since most devices
>>> (laptops, smartphones, IoT devices) have batteries today. In that case
>>> it might have made sense to sending fewer RA messages by using
>>> multicast.
>>>
>>> (*) the only case in RFC 4861 when I think a multicast response might be
>>> considered is when the source IPv6 address in the RS is the unspecified
>>> address. Further, an implementation which rate limits received RS
>>> packets (e.g., CoPP in a router) might also want to detect when the rate
>>> limit might have dropped RS packets and multicast an RA in that case.
>>>
>>>
>>> I do wonder why implementations haven't already changed to send unicast
>>> solicited RA, and whether it would make a difference if we have an
>>
>> TBH that's my concern as well. I think we should tweak the text in
>> 4861 to encourage a bit more consideration on the implementer's side.
>>
>>> informational document asking them to do this. Alternatively we could
>>> have a proposed standard which updates section 6.2.6 to change the "MAY
>>> unicast" to a "SHOULD unicast".
>>
>> Yeah, I actually have had the different text aimed for 6man, but
>> Lorenzo's concern was 6man would say "there is no protocol update
>> here, go away", so he rewrote it for v6ops.
>>
>> We should probably discuss this at the mic and get the opinion of the
>> 6man chairs - if there is no outright "no" on this, a normative doc
>> would be a better way to convince the implementers ?
>>
>>>
>>> FWIW the draft incorrectly refers to section 6.2.4 instead of 6.2.6.
>>
>> Nice catch, thanks!
>>
>> --a
>>
>>>
>>> Thanks,
>>>    Erik
>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>