Subject: [Roll] Ew: RPL Design Questions

From: "Anders Jagd" <[email-masked]>
Date: Thu, 15 Oct 2009 13:27:27 -0400

Tim,

As for your questions:

>Question A:  Should RPL make use of the currently proposed local ...
>Question B:  Should RPL make use of a hold-up timer and related ...
>Question C:  Should RPL make use of a hold-down timer and related ...

A+B: 

My opinion would be that a Sequence number/"Heartbeat" scheme generally
provides a more reliable, efficient, and simple method compared to timer
based approaches. 

Determining reasonable settings for timer(s) may prove difficult, and no
matter what value is chosen, there is no guarantee that the scheme achieves
the intended goal, rather a likelihood. Not that I am in general against
"likelihoods", as long as they are not "too small" (not good enough),
neither "too large" (too expensive/conservative) - something not trivial to
achieve, in particular since nodes/roots rarely/never have complete atomic
snapshots in time of the full DAG, and even if they did, the DAG could be
quite unbalanced with a mix of short and long branches. 

After deciding on (or occasionally adjusting) proper timer values, those
values then have to be propagated. As of 03 this is through RA-DIO. It does
appear a bit wasteful to continuously broadcast values that typically are
quite static. However, new nodes need to be informed, so if it is not done
regularly through RA-DIO, some other way would have to be defined, basically
some signaling scheme. Either way, this sounds "expensive".

The sequence number approach has little to no timers involved; as soon as a
new sequence number is observed, a node is good to go (merge). It appears to
basically be a semi "self-timed" approach ("semi" since root, but only root,
may need a timer for triggering the heartbeat). How frequently should this
heartbeat (sequence number increment) then happen ? Again, we run into the
"too short/too long" discussion. But what if a node wishing to merge into a
DAG (and thus needing to see a new SQN), could be allowed to request the
root to increment the sequence number ? If any other heartbeat trigger is
required, it could probably be chosen quite conservatively, and the value
certainly would not have to be propagated.

Bursts of such "increment SQN" requests could be reduced by some form of
aggregation: Any node issuing or forwarding a "SQN update request" would
stop forwarding other such requests (drop them) until it sees a new SQN.

C: I think some form of mechanism to limit flapping is important, but again,
I would ask how to determine and configure/propagate a proper timer value.
Can we somehow base it on the heartbeat instead (maybe multiple heartbeats)
?

/Anders

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 16 Oct 2009 07:50:46 +0200

Hi Anders:

All you're saying makes good sense. You might want to include additional
things in your reasoning about A+B)

As you point out, our route poisoning technique aims at lowering the
odds of jumping in a hole. The chances can be estimated from the loss
ratio on RAs. The timer can be set to cover one round trip RA/ RA echo,
or multiple trickled RAs if that is determined to influence the odds in
an important fashion.

The protocol as will be complemented by a loop detection mechanism. A
proposal was already posted "A proposal for Traffic Loop avoidance,
detection and recovery". The loop detection is required even if we do
not do A+B, to cover the window till DAG rebuilds, siblings loops and
DAO loss loops.

The local route poisoning and the global DAG rebuild provide really
different services and operate at a very different level.
 
My own take is to have both if we can afford that.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf Of
Anders Jagd
>Sent: jeudi 15 octobre 2009 19:27
>To: [email-masked]
>Cc: [email-masked]
>Subject: [Roll] Ew: RPL Design Questions
>
>Tim,
>
>As for your questions:
>
>_______________________________________________
>Roll mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/roll