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

> On 21 Jul 2015, at 16:08, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
>
>
>
> Le 17/07/2015 18:57, Andrew Yourtchenko a écrit :
>>
>> 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
>
> and:
>
> - fast handovers: on some links the more frequent the multicast RAs the
> faster the handovers are, i.e. less packet loss for end nodes, less
> glitches in the video conference stream.
>

If the network sends the periodic RAs frequently enough to avoid the
glitches of the video stream, this is explicitly *NOT* the network we
are concerned about in this draft.

Also, we wanted to be very focused what we talk about in this
document, to be able to ship it quicker.

We can say "does not apply to 802.11p, applies to 802.11(a|b|g|n|ac).
Applicability to other networks is left at readers' discretion".

Or something along these lines of that - feel free to propose the text
if the above is not what you had in mind.

--a

> Alex
>
>>
>> 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.
>>
>> --a
>>
>>> _______________________________________________
>>> v6ops mailing list
>>> v6ops@ietf.org
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops