Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders

RFC6206 goes into some of the implications of mismatched parameters. It kind of assumes the values are not *tremendously* different, with the general conclusion is that there will be uneven load but it will generally continue to work alright, especially in the presence of inconsistencies. It only really breaks down when consistency criteria differ.

Phil

-------
Philip Levis
Associate Professor
Computer Science and Electrical Engineering
Stanford University
http://csl.stanford.edu/~pal

On Oct 4, 2013, at 8:14 AM, Don Sturek <d.sturek@att.net> wrote:

> Hi Yusuke,
> 
> I think it would depend on how different the settings are between the old
> imin, imax, k, etc.
> 
> Imagine a change where the values of the old imin, imax, k, etc. and the
> new ones were such that the new imax is now less than the old imin.  If
> you mix that in with the unmanaged delivery of the new values I think you
> would find that the forwarding of transmissions at that time (including
> the update of the new MPL parameters themselves) would not guarantee
> delivery to all nodes.
> 
> I do think if you were to change the imin, imax, k values in a "small" way
> then there might be little to no impact on forwarding (where "small" I
> guess would be a bit hard to quantify}
> 
> The safest solution is to use the old values to distribute the new values
> and then validate all nodes have the value (synchronization) and then have
> the new values take effect.
> 
> Don
> 
> 
> On 10/4/13 8:07 AM, "DOI Yusuke" <yusuke.doi@toshiba.co.jp> wrote:
> 
>> Hi Don,
>> 
>> I thought some unbalanced transmission could happen and acceptable,
>> but other issues may occur as you and Peter say.
>> 
>> I think it's better to find some workaround for now.
>> 
>> Thank you very much!
>> 
>> Yusuke
>> 
>> From: Don Sturek <d.sturek@att.net>
>> Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL
>> forwarders
>> Date: Fri, 04 Oct 2013 06:45:13 -0700
>> 
>>> Hi Yusuke,
>>> 
>>> <I haven't tried this with our running code however...... >
>>> 
>>> I don't believe it is possible to change imin, imax, k or any other
>>> operational MPL forwarder parameter without some sort of
>>> pre-distribution/synchronization of the new parameters.  It would work
>>> as
>>> you note if there are no transmission or valid seed set but if multicast
>>> traffic is already present using an existing seed, I would expect you
>>> would see issues in distribution of messages if you change the
>>> parameters
>>> while in operation.   Additionally, if you use MPL to distribute the
>>> change with existing multicast traffic you will find some nodes do not
>>> get
>>> the new parameters (which will create other problems when you want the
>>> new
>>> parameters to take effect)
>>> 
>>> Don
>>> 
>>> 
>>> 
>>> On 10/4/13 1:07 AM, "Yusuke DOI" <yusuke.doi@toshiba.co.jp> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I have a simple question: is it possible to update MPL parameters of
>>>> running forwarder instances?
>>>> 
>>>> To maintain the system in 'good state', I expect some sort of parameter
>>>> tuning on MPL. Especially for the systems dynamically grows, static
>>>> configuration of MPL parameters will be difficult. For example, DHCPv6
>>>> reconfigure request can be used to update MPL forwarder parameter.
>>>> However, I'm not sure it's 'safe' to update parameters (K, Imin, Imax)
>>>> of
>>>> running MPL forwarder instances.
>>>> 
>>>> I think it's safe if there are no transmission / no valid seed set. Is
>>>> it
>>>> possible to update a running MPL forwarder parameter without breaking
>>>> current state? 
>>>> 
>>>> Regards,
>>>> 
>>>> Yusuke
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Roll mailing list
>>>> Roll@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/roll
>>> 
>>> 
>>> _______________________________________________
>>> Roll mailing list
>>> Roll@ietf.org
>>> https://www.ietf.org/mailman/listinfo/roll
>> 
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll