 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
Hi JP: What we end up with at the moment is too many routers and then
blind suppression of routing updates. I’d rather have less routers and less-to-no suppression.
IOW suppress the role of routers as opposed to the control messages. Same “trickle” thinking though, but applied on a
different level (router role as opposed to control message). Loss of control messages is the source of all evils in DV. That’s
what cause count to infinity in RIP in the first place. The way we use it, C is equivalent to forcing control packet
loss. CTP copes by having reactive detection. Detection causes the
message to be resent so at the end of the day it is not saved. In the meantime,
convergence was delayed and risk of CTI increased. In the meantime, packets are lost which might be acceptable in
some environment and not in other. Same reasoning as poisoning. The thing that helps a bit is that amongst the many routers that
are not needed as routers, a good number is actually not used as routers, so no
detection, and thus no retrigger. But: ·
Those guys still issue useless DIOs ·
We end up with more routers and more fine grained paths than
necessary ·
Those paths all need to be maintained thus more control messages
etc… I’m advocating that the graph should have less (and larger)
branches, and that those branches could be reevaluated at each new sequence,
for instance to adapt to the battery level of the active routers. That’s
good for control overhead and that’s good for multicast. I’m claiming that we can do that using trickle, for all
the great properties that Phil has listed in many places. Once we are at that we
can discuss the algorithm but there’s enough info in this thread for people
to figure out how. I still see the value of trickling the control packets because
of the exponential backoff piece but wish to limit the suppression of routing
information as much as possible. Pascal From: JP Vasseur (jvasseur)
Hi Pascal, On Nov 17, 2009, at 8:13 AM, Pascal Thubert (pthubert)
wrote:
Hi: The current RPL draft uses trickle to address density. Trickle has
a number of fine properties to throttle the control when things are stable. Still, when an accident occurs, like a parent high in the DAG
degrades its rank, possibly most of the nodes in the whole network will have to
reassess their rank and reset their trickle timer. My understanding of that process is that it can yield quite
a bit of activity, that grows with the number of nodes acting as routers. What I think is that even if we have trickle, we should be
considering some control on the density of nodes that act as a router. To
address that, there’s already ample work and large WSN deployments that
leverage the concept of dominating set. A dominating set is a connected set of routers that enables
connectivity for all, that is all nodes in the network is connected to at least
one member of the dominating set. Because we have trickle, such a set does not need to be
shrink to minimal/optimal. In fact, we’d want that each node in the
network sees at least 2 members of the dominating set. Can that be achieved simply? Possibly. Each time a new sequence is spread, nodes are entitled to reassess
their need to be a router. When the sequence spreads, a form of trickle could
be used to decide Not TO advertise self as a router and act as a host for the
new sequence. Like if enough neighbor routers advertise the new sequence before
T elapse, then there might be no need for self to act as a router. Thoughts? I do see your reasoning and that notion is indeed used in
other protocols but the issue here is that you need to determined who you put
in the set since they need to have connectivity. If you use C and set it low
enough, isn't it sufficient ? Cheers. JP.
Pascal _______________________________________________ |