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

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

> On 22 Jul 2015, at 14:00, Alexandru Petrescu <[e-mail]> wrote:
> 
> 
> 
> Le 22/07/2015 09:20, Andrew 👽  Yourtchenko a écrit :
>>> On 21 Jul 2015, at 16:08, Alexandru Petrescu <[e-mail]> wrote:
>>> 
>>> 
>>> 
>>> Le 17/07/2015 18:57, Andrew Yourtchenko a écrit :
>>>> 
>>>> On 17 Jul 2015, at 09:34, Fred Baker (fred) <[e-mail]> 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.
> 
> But mentioning 'mobile' for the nodes, makes think so.  Because fast address auto-configuration is a characteristic of mobile nodes.  One wants to spend as little time as possible waiting for RAs.  For that reason the multicast RAs period was reduced to milliseconds.

Yes. We made changes in the newly submitted -01 to make it clearer which networks it will apply to, hopefully it clarifies the scope enough.

--a

> 
>> Also, we wanted to be very focused what we talk about in this
>> document, to be able to ship it quicker.
> 
> I agree.
> 
>> 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".
> 
> I agree.  It should also say it does not apply to LTE.  BEcause in LTE an RA is sent on only one ptp link, there is no risk of waking up somebody
> 
>> Or something along these lines of that - feel free to propose the text
>> if the above is not what you had in mind.
> 
> On a scale MUST NOT, MAY, SHOULD - SHOULD is the right term.
> 
> "SHOULD [...] unless the network is of type LTE or 802.11p".
> 
> Or:
> 
> "SHOULD [...] unless there is an interest in as numerous RAs as possible to help in fast address auto-configuration to large number of mobiles".
> 
> or
> 
> "SHOULD [...] unless the Hosts are allowed to explicitely express interest in the multicast group dst of RA".
> 
> or
> 
> "SHOULD [...] unless RFC-MLD is updated to require Hosts to express interest in the multicast group dst of RA".
> 
> Alex
> 
>> 
>> --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
>>>>> [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
>