Subject: [Roll] a few questions on ROLL

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 8 Mar 2010 13:27:24 +0200

Hi,

My experience is of PLC networks, and I have a few questions to the group
regarding ROLL that are interesting in particular to the networks we’re
working on. The draft really looks like a pertinent massive and impressive
amount of work in progress.

1) Regarding 5.2. DODAG Information Solicitation (DIS) - How would DIS
reception affect the network if there are potentially LOTS of nodes that can
respond? This invites congestion to the channel. Maybe some filters are due
(e.g. based on max-rank response, or allowing responses from lower ranks to
be sent faster, etc.)?

2) Regarding 5.3.5. DIO Transmission (the trickle reset to a minimum value
due to detected inconsistency) – In some of the cases, the inconsistencies
may be transient (pass by themselves if waiting long enough) but also
detectable by many nodes simultaneously. So reducing the timer to a minimum
by many nodes could be a little aggressive (may cause instantaneous bursts
of congestion). This is particularly problematic in case of “blinking
links/nodes” in PLC networks, which can be a timely repetitive phenomenon
(for example, due to repetitive power grid usage profile). It looks like
remaining with the same timer that would eventually solve the problem after
a longer while, so this reduction seems that critical only if a node is
really expected to transmit packets via that routing inconsistency very
often, otherwise it seems that the requirement can be more relaxed.

3) Regarding 5.3.5.1.2. Determination of Inconsistency - What about allowing
for some indications from L2 (failure to receive link layer ACKs for
example). Another question is whether an inconsistency can be learned from a
DAO message that needs to return to a node already appearing on the RR
Stack?

4) Regarding 7.1. Suggestions for Packet Forwarding – does ROLL allow to use
a similar or lower preferences via another node if it detects a failure to
transmit to a node that satisfied the best preference (for example no L2 ACK
for pref.#3 in case of a bad, asymmetric or occasional link with a neighbor
node).

5) Regarding 7.2.2.6. Forward Path Recovery – can the TTL be reset after
setting the Forwarding-Error bit to allow higher probability to reach the
originating node (in case the forwarding problem occurred more than half way
through the TTL)?

6) Regarding 12.1.1 Initialization mode - In PLC networks, there’re
occasional problems of high noise near the receiver (causing it to have bad
reception but being well-heard by others) or tx load at the transmitter
(causing other nodes to have bad reception of its transmissions, but
allowing the transmitter to have good reception of other nodes packets). In
such scenarios, it is particularly difficult to detect the only good
candidates that have a bi-directional link with the node. I’m not sure that
simply going over the candidate options one by one is a very good approach
(again filters to the DIS message could ease the problem).

In addition, I have some questions about coverage of the draft as well:

1) Should the draft address the behavior of nodes after warm starts up (what
should MUST be saved, what is recommended to be saved, trickle timer
considerations, etc.)? This is an interesting tradeoff in particular for
large PLC networks after power fails (where channel congestions should be
avoided) vs. sporadic power fail in a single or few nodes (where fast
recovery of routes is required).

2) Should the draft address the ability to gracefully replace a DODAG root
without regenerating the whole DODAG to a new DODAG root? Maybe if the root
that originated the DODAG is maintained, instead of the active one in the
DODAGID field?

Any assistance and clarifications would be very much appreciated.

Thanks in advance,

Yoav Ben-Yehezkel

Senior communications engineer

Yitran Communications LTD.