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

From: "Li Zhao (liz3)" <[email-masked]>
Date: Tue, 19 Nov 2019 05:34:08 +0000

Hello all,

As we discussed today, there is a requirement that node sends out multicast DIS to only reset given parent’s Trickle.

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

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 19 Nov 2019 18:19:04 +0800

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

> 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

> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Wed, 20 Nov 2019 03:31:05 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Li,

    Best,
    Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 20 Nov 2019 11:51:29 +0800

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?

---

From: "Li Zhao (liz3)" <[email-masked]>
Date: Thu, 21 Nov 2019 01:02:29 +0000

Hello Rahul,

Node can store preferred parent's info when outage. 
But after reboot, it still need DIO from this parent to confirm whether this parent is alive. Because parent may be outage too.
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. 

Does it make sense?

Best regards,
Li

On 2019/11/20, 11:52, "Roll on behalf of Rahul Jadhav" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Nov 2019 10:03:34 +0800

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Nov 2019 02:47:20 +0000

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 <[email-masked]> On Behalf Of Rahul Jadhav
> Sent: jeudi 21 novembre 2019 10:04
> To: Routing Over Low power and Lossy networks <[email-masked]>
> Subject: Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-
> information
> 
> [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:
> 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-
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >     > On 2019/11/19, 18:20, "Roll on behalf of Rahul Jadhav" <roll-
> [email-masked] on behalf of [email-masked]> wrote:
> >     >
> >     >     Hi Li,
> >     >
> >     >     > As we discussed today, there is a requirement that node sends out
> multicast DIS to only reset given parent’s Trickle.
> >     >
> >     >     > Can we enhance Solicited Information option to add a flag to
> identify given parent’s address as following?
> >     >     >
> >     >     >
> >     >     >
> >     >     >         0                   1                   2                   3
> >     >     >

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Nov 2019 11:33:32 +0800

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) <[email-masked]>
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.
>
> - 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
> 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
>
>
> parent
> > >     > This is about " we need other nodes sending DIS to backoff on
> hearing
> > other node's DIS ".
> > >     > 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
> > >     >
> > >     >     >         0                   1                   2
>          3
> > >     >     >        |   Type = 0x07 |Opt Length = 19| RPLInstanceID
> |V|I|D|P|
> > Flags |
> > >     >     >
> > >     >     >
> > >     >     >        |
>              |
> > >     >     >        +
>              +
> > >     >     >        |
>              |
> > >     >     >        +                            DODAGID
>             +
> > >     >     >        |
>              |
> > >     >     >        +
>              +
> > >     >     >        |
>              |
>              +
> > >     >     >        +
>              +
> > >     >     >        |
>              |
> > >     >     >        +
>              +
> > >     >     >        |
> -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > >     >     >
> > >     >     >        +-+-+-+-+-+-+-+-+
> > >     >     >
> > >     >     >
> > >     >     >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Nov 2019 06:34:14 +0000

Hello Rahul

Please see below :)

Le 21 nov. 2019 à 11:34, Rahul Jadhav <[email-masked]> 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) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Rahul

Does that clarify?

Pascal

> From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Rahul Jadhav
> To: Routing Over Low power and Lossy networks <[email-masked]<mailto:[email-masked]>>
> On Thu, 21 Nov 2019 at 09:03, Li Zhao (liz3) <[email-masked]<mailto:[email-masked]>> wrote:
> >
> > Hello Rahul,
> >
> [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
> >
> >     On Wed, 20 Nov 2019 at 11:31, Li Zhao (liz3) <[email-masked]<mailto:[email-masked]>> wrote:
> >     >
> >     > Hello Rahul,
> >     >
> [email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
> >     >
> >     >     Hi Li,
> >     >
> >     >     On Tue, 19 Nov 2019 at 13:34, Li Zhao (liz3) <[email-masked]<mailto:[email-masked]>> wrote:
> >     >     >
> >     >     > Hello all,
> >     >     >
> >     >     >
> >     >     >
> >     >     > [email-masked]<mailto:[email-masked]>
> >     >     [email-masked]<mailto:[email-masked]>
> >     >     https://www.ietf.org/mailman/listinfo/roll<https://www..ietf.org/mailman/listinfo/roll>
> >     >
> >     >
> >     > [email-masked]<mailto:[email-masked]>
> >     [email-masked]<mailto:[email-masked]>
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll