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

[Rahul Jadhav <[e-mail]>]

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?

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

Best,
Rahul



On Thu, 21 Nov 2019 at 10:47, Pascal Thubert (pthubert) <[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]> On Behalf Of Rahul Jadhav
> > Sent: jeudi 21 novembre 2019 10:04
> > To: Routing Over Low power and Lossy networks <[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]> 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] on behalf of [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]>
> 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] on behalf of [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]>
> 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]
> > >     >     > https://www.ietf.org/mailman/listinfo/roll
> > >     >
> > >     >     _______________________________________________
> > >     >     Roll mailing list
> > >     >     [e-mail]
> > >     >     https://www.ietf.org/mailman/listinfo/roll
> > >     >
> > >     >
> > >     > _______________________________________________
> > >     > Roll mailing list
> > >     > [e-mail]
> > >     > https://www.ietf.org/mailman/listinfo/roll
> > >
> > >     _______________________________________________
> > >     Roll mailing list
> > >     [e-mail]
> > >     https://www.ietf.org/mailman/listinfo/roll
> > >
> > >
> > > _______________________________________________
> > > Roll mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/roll
> >
> > _______________________________________________
> > Roll mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>