Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-information

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Rahul

Please see below :)

Le 21 nov. 2019 à 11:34, Rahul Jadhav <[e-mail]> a écrit :


Hi Pascal,

DIS does not use the Trickle timer. Only DIO is using the Trickle timer currently. Is the proposition also to use Trickle for DIS?


Yes that’s the most important piece. Then the devil in the details is whether a DIS with a filtering Information like a parent is consistent with another without that filter.


Li's proposal for using parent address in multicast DIS is interesting. But there are scenarios which concern me:
1. When other nodes attached to the same parent (P) hear multicast DIS(parent=P) then they are supposed to back off. What happens if the node who gets to multicast on the air is no more in the direct vicinity of the parent node but other nodes are. The other nodes, in this case, will back off on hearing DIS(parent=P) and will delay joining.

The key is in using trickle for DIS. The K constant for DIS should be more than one. If the parent hears any of the K messages from random children it will reset its trickle timer for DIOs.

2. The handling of DIS becomes more complicated because the node cannot indefinitely back off and at some point in time needs to start sending its own DIS. This results in managing DIS state over a period of time. Current DIS handling is very simple.


Yes and this causes issues ...


Best,
Rahul



On Thu, 21 Nov 2019 at 10:47, Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>> wrote:
Hello Rahul

This proposal is an alternate to the proposal of using a multicast address that is derived from the parent address that we discussed at the meeting. Basically after a power outage and with the premise that the nodes can store the RPL state before the outage, the network can reform more quickly with mostly the shape it had before.

What really hurts is the tempest of DIS messages. It interferes with the reformation of the network. Those should be cancelled out with a trickle mechanism. If a node hears DIS messages around, it should refrain from sending it own. RPL does not discuss that aspect. If the parent is not awaken or is gone, the trickle mechanism will exponentially back off the retries till the point where the child reparents anyway.

In this case we want the DIS to be multicast and the other (candidate) children to process it. We should define the trickle Imin of DIS to be longer than that of DIO, so when all nodes reboot there's a chance that DIOs are heard before DIS are.

One desired outcome in that case is that the DIO is responded multicast and arrives soon, which is the case with a multicast DIS. So the particular case does not need a change in the DIS bits that we are still considering for other reasons.

On top of trickling the DIS, the ask here is to specify the specific parent that answers. But we do not want to send a unicast packet to the parent because the other candidate children would miss the DIS. So Li's proposal here is to add that as a filter in the SIO.

Comparing the 2 proposals:
- the SIO enables to ask from more than one parent by placing more than one address. Also it is simpler if MLD is not implemented
- the multicast address enables the parents to list their children using MLD.

We also need to clarify what resetting trickle mean. If I goes back to Imin, you need to restart the timer as well because it would timeout out of bounds. But if it is already Imin, the timer as it is running is already compatible so it should not be restarted. This way the DIO flies quickly.

If a node does not have persistent storage then it will not specify a parent. The overall trickling stuff remains critically important. The difference is the consistency check, all DIS are consistent with one another.

Does that clarify?

Pascal


> -----Original Message-----
> From: Roll <[e-mail]<mailto:[e-mail]>> On Behalf Of Rahul Jadhav
> Sent: jeudi 21 novembre 2019 10:04
> To: Routing Over Low power and Lossy networks <[e-mail]<mailto:[e-mail]>>
> Subject: Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-
> information
>
> Please find my comments below.
>
> On Thu, 21 Nov 2019 at 09:03, Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>> wrote:
> >
> > Hello Rahul,
> >
> > Node can store preferred parent's info when outage.
>
> [RJ] Storing parent info in persistent storage seems costly. But let's go with
> this premise for this discussion.
>
> > But after reboot, it still need DIO from this parent to confirm whether this
> parent is alive. Because parent may be outage too.
>
> [RJ] In case of outage if the child node sends multicast DIS with the parent
> address, the parent node itself may not have attached to the network and may
> be still trying. So the DIS may have to be repeated till the point where parent
> node is attached as well. All the other nodes would be trying to do the same
> with their DIS as well.
>
> > Reset trickle timer can let parent inform all children and accelerate the
> network recovery. Otherwise, all nodes need to run unicast DIS request and
> unicast DIO response. It wastes too much of time.
>
> [RJ] If we let the trickle time reset then we wouldn't be solving the problem.
> Let me give an example:
> a. Assume 20 nodes using parent P
> b. there's an outage
> c. all 20 nodes sending DIS(with P address) and resetting P's trickle timer.
> P keeps on resetting the trickle because of high child density and never is able
> to dole out DIO.
>
> >
> > Does it make sense?
>
> [RJ] It is good to know the options assuming that the preferred parent is
> stored in persistent storage. But making design choices based on this (use of
> storage) assumption may not be the right way. Note that there could be
> multiple preferred parents and the parent info is much more dynamic and
> thus may require frequent updates to persistent storage.
>
> >
> > Best regards,
> > Li
> >
> >
> > On 2019/11/20, 11:52, "Roll on behalf of Rahul Jadhav" <roll-
> [e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
> >
> >     Thanks Li for elaborating.
> >
> >     Regarding the warm boot use-case you mentioned, the nodes certainly do
> >     not know whether they have individually rebooted or rebooted because
> >     of mass-outage.
> >     What I don't get is, if the child node already knows who the parent is
> >     why would it want to reset its Trickle timer?
> >
> >     On Wed, 20 Nov 2019 at 11:31, Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>> wrote:
> >     >
> >     > Hello Rahul,
> >     >
> >     > This is about " we need other nodes sending DIS to backoff on hearing
> other node's DIS ".
> >     > The use case is for warm boot case when hundreds of nodes power
> outage at the same time.
> >     > 1. Child nodes send DIS to inform given parent to reset its trickle.
> (unicast or multicast DIS both work)
> >     > 2. Child nodes suppress or backoff sibling nodes' DIS. Only multicast DIS
> works.
> >     >     And we need enhance Solicited Information option to identify this
> kind of DIS.
> >     >
> >     >
> >     > Best regards,
> >     > Li
> >     >
> >     > On 2019/11/19, 18:20, "Roll on behalf of Rahul Jadhav" <roll-
> [e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:
> >     >
> >     >     Hi Li,
> >     >
> >     >     What is the use-case where the child node needs to inform the parent
> >     >     to reset its trickle unilaterally when it already knows the parent's
> >     >     address?
> >     >     Please find my comments below.
> >     >
> >     >     Best,
> >     >     Rahul
> >     >
> >     >     On Tue, 19 Nov 2019 at 13:34, Li Zhao (liz3) <[e-mail]<mailto:[e-mail]>> wrote:
> >     >     >
> >     >     > Hello all,
> >     >     >
> >     >     >
> >     >     >
> >     >     > As we discussed today, there is a requirement that node sends out
> multicast DIS to only reset given parent’s Trickle.
> >     >
> >     >     [RJ] We discussed today that we need other nodes sending DIS to
> >     >     backoff on hearing other node's DIS. We also discussed that we need
> >     >     parent node to not keep on resetting the trickle timer all the time on
> >     >     hearing DIS.
> >     >     I am not sure we discussed about sending a multicast DIS to reset a
> >     >     given parent's Trickle. Or may be I didn't get it correctly. Can you
> >     >     please elaborate? Thanks
> >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > Can we enhance Solicited Information option to add a flag to
> identify given parent’s address as following?
> >     >     >
> >     >     >
> >     >     >
> >     >     >         0                   1                   2                   3
> >     >     >
> >     >     >         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |   Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D|P|
> Flags |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                            DODAGID                            +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |Version Number | Parent Address     (16bytes)                  |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+                                               +
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+
> >     >     >
> >     >     >
> >     >     >
> >     >     > P flag: One Bit, indicates DIS request response from given parent
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > Best regards,
> >     >     >
> >     >     > Li
> >     >     >
> >     >     > _______________________________________________
> >     >     > Roll mailing list
> >     >     > [e-mail]<mailto:[e-mail]>
> >     >     > https://www.ietf.org/mailman/listinfo/roll
> >     >
> >     >     _______________________________________________
> >     >     Roll mailing list
> >     >     [e-mail]<mailto:[e-mail]>
> >     >     https://www.ietf.org/mailman/listinfo/roll<https://www..ietf.org/mailman/listinfo/roll>
> >     >
> >     >
> >     > _______________________________________________
> >     > Roll mailing list
> >     > [e-mail]<mailto:[e-mail]>
> >     > https://www.ietf.org/mailman/listinfo/roll
> >
> >     _______________________________________________
> >     Roll mailing list
> >     [e-mail]<mailto:[e-mail]>
> >     https://www.ietf.org/mailman/listinfo/roll
> >
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]<mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll