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

From: Yusuke DOI <[email-masked]>
Date: Fri, 04 Oct 2013 17:07:16 +0900

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

---

From: peter van der Stok <[email-masked]>
Date: Fri, 04 Oct 2013 10:29:50 +0200

Hi Yusuke.

I think you may "safely" change Imin, ,k, Imax and repeat per new 
message for all involved forwarders, while leaving all earlier messages 
unaffected. BUT this needs LARGE changes to the current spec.

My 2 cents,

peter

Yusuke DOI schreef op 2013-10-04 10:07:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Yusuke DOI <[email-masked]>
Date: Fri, 04 Oct 2013 20:04:25 +0900

Hi Peter,

I have not recognized it needs LARGE change. My first idea was to replace the parameters at the very beginning of an interval (step 2 of RFC6206 section 4.2) for each trickle timer. Because it's difficult to synchronize the update, I think unbalanced retransmission may occur in transient period. I assume it's acceptable (safe enough).

Could you tell me about your concerns that requires LARGE spec update?

Regards,

Yusuke

(2013-10-04 17:29), peter van der Stok wrote:
> Hi Yusuke.
>
> I think you may "safely" change Imin, ,k, Imax and repeat per new message for all involved forwarders, while leaving all earlier messages unaffected. BUT this needs LARGE changes to the current spec.
>
> My 2 cents,
>
> peter
>
>
>

---

From: peter van der Stok <[email-masked]>
Date: Fri, 04 Oct 2013 14:02:29 +0200

Hi Yusuke,

For the moment the parameters are general for al interfaces, seeds and 
messages.
In the case of changing per message, the parameter sets need to be 
attached to each message entry. (for me that is a large change)
Second for synchronous change, parameters need to be transported in 
message from seed. (Another large change to the message format).

Please be aware that there are as many trickle timers as there are 
messages outstanding, so what is the start of the interval?

Anything I missed here?

peter

Yusuke DOI schreef op 2013-10-04 13:04:
> Hi Peter,
> 
> I have not recognized it needs LARGE change. My first idea was to
> replace the parameters at the very beginning of an interval (step 2 of
> RFC6206 section 4.2) for each trickle timer. Because it's difficult to
> synchronize the update, I think unbalanced retransmission may occur in
> transient period. I assume it's acceptable (safe enough).
>

---

From: Yusuke DOI <[email-masked]>
Date: Fri, 04 Oct 2013 22:03:12 +0900

Hi Peter,

Thanks! I think my idea can be applied only for the trickle timer for control messages.
I agree synchronous change will be difficult without changing message format. It may be done out-of-band (such as DHCP, SNMP, ...) if asynchronous per-node update is allowed.

Regards,

Yusuke

(2013-10-04 21:02), peter van der Stok wrote:
> Hi Yusuke,
>
> For the moment the parameters are general for al interfaces, seeds and messages.
> In the case of changing per message, the parameter sets need to be attached to each message entry. (for me that is a large change)
> Second for synchronous change, parameters need to be transported in message from seed. (Another large change to the message format).
>
> Please be aware that there are as many trickle timers as there are messages outstanding, so what is the start of the interval?
>
> Anything I missed here?
>
> peter
>
>

---

From: Don Sturek <[email-masked]>
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" <[email-masked]> wrote:

>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
>
>

---

From: DOI Yusuke <[email-masked]>
Date: Sat, 05 Oct 2013 00:07:03 +0900 (JST)

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 <[email-masked]>
Subject: Re: [Roll] Question on MPL: parameter update on runnning MPL forwarders
Date: Fri, 04 Oct 2013 06:45:13 -0700