Subject: [homenet] DNCP: issue with network partitions and monitoring nodes

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 28 Jun 2015 20:22:33 +0200

Markus, Steven,

Unless I'm mistaken, there's an issue with DNCP and monitoring nodes.  
Consider the following topology:

   A --- M --- B

A and B are ordinary DNCP nodes, while M is a monitoring node, as 
described in the second paragraph of Section 4.4.  So M doesn't publish 
a NODE-STATE TLV, but other than that it fully participates in the 
protocol.

Due to the silly walk described in Section 4.6, A's network state consists 
of just itself, and similarly B.  Whenever M sends a NODE-STATE TLV, 
either A's or B's Trickle timers are reset, leading to excessive traffic.

I don't see a good solution to that.  If you don't reset trickle when you 
see inconsistency from a node that doesn't publish NODE-STATE, then you 
have a bootstrapping problem (new node whose NODE-STATE is unknown).  If 
you forbid monitoring nodes from sending NODE-STATE, then you break 
Trickle for them.

Perhaps there's no good way to allow a node to participate without 
publishing NODE-STATE.  Grr.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Mon, 29 Jun 2015 13:31:38 +0300

> Consider the following topology:

I would not call that node 'monitor'; instead e.g. 'forwarding' or 
'bridge' node. To me, 'monitor' implies passive observation. This does 
not seem to be that.

> Due to the silly walk described in Section 4.6, A's network state
> consists of just itself, and similarly B.  Whenever M sends a NODE-STATE
> TLV, either A's or B's Trickle timers are reset, leading to excessive
> traffic.

I wonder if it is too late to change it to 'silly walk', it is much 
better than the boring 'topology graph traversal' that Thomas Clausen 
wanted.

> I don't see a good solution to that.  If you don't reset trickle when
> you see inconsistency from a node that doesn't publish NODE-STATE, then
> you have a bootstrapping problem (new node whose NODE-STATE is
> unknown).  If you forbid monitoring nodes from sending NODE-STATE, then
> you break Trickle for them.
>

That, essentially.

However, if you want to _bridge_ stuff, you can just forward 'things 
from A to B, and things from B to A' on the M node, and it should work. 
You can even rate limit them to some degree and do some other things I 
rather not commit in writing though :)

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 30 Jun 2015 14:12:04 +0200

>>    A --- M --- B

[...]

>> M doesn't publish a NODE-STATE TLV, but other than that it fully 
>> participates in the protocol.

> However, if you want to _bridge_ stuff, you can just forward 'things from 
> A to B, and things from B to A' on the M node, and it should work.

I'm probably missing something, then.

For a given node N, let N's Silly Walk Set, written SWS(N), be the set of 
nodes that N includes in the computation of its network hash.

If M is just forwarding beween A and B, and is not publishing a node 
state, then SWS(A) = {A} and SWS(B) = {B}.  Therefore, the network states 
published by A and B will be different, and everytime N forwards A's 
network state to B, B will reset its trickle timer, and similarly in the 
other direction.

What am I missing?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 30 Jun 2015 18:13:22 +0300

On 30.6.2015 15.12, Juliusz Chroboczek wrote:
> For a given node N, let N's Silly Walk Set, written SWS(N), be the set
> of nodes that N includes in the computation of its network hash.
>
> state, then SWS(A) = {A} and SWS(B) = {B}.  Therefore, the network
> states published by A and B will be different, and everytime N forwards
> A's network state to B, B will reset its trickle timer, and similarly in
> the other direction.
>
> What am I missing?

If node M forwards the packets verbatim between nodes A and node B, they 
think they're adjacent. ('bridging')

However, if node M wants to actually participate in the protocol instead 
of being light-weight packet forwarder (which requires keeping track of 
e.g. one node on each of two links, and just communicate with that one, 
and relay multicasts or convert them to unicasts to that particular 
tracked node on other side of the fence), it gets more complicated.

That forwarding scheme does not preclude M from also keeping it's own 
read-only dataset.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 30 Jun 2015 18:19:47 +0200

> think they're adjacent. ('bridging')

Ah!

-- Juliusz