Subject: [Roll] S bit

From: Philip Levis <[email-masked]>
Date: Tue, 1 Jun 2010 10:42:10 -0700

A recurring theme in feedback on RPL is that simpler is better; LLNs are often very cost-sensitive for microcontrollers, so less code is better. It's easy to add mechanisms, bells and whistles: it's harder to simplify.

I propose that we remove the S bit (sibling bit used in routing, Section 8.2). Four reasons:

1) The justification for the S bit comes from an idea proposed by Dominique a year or so ago, which he evaluated in simulation. The S bit has never been used or tested in an operational protocol. It is a "new" idea, rather than standardizing common practice. This seems like too low a bar to make it into a proposed standard in a domain where there's huge operational experience.

2) The real benefit of the S bit comes from when a node that used to send directly to a DODAG root loses that link, forcing it to move down in the DODAG (increase Rank), which used to be illegal within a DODAG iteration. Now that there's MaxDAGRankIncrease, this benefit is not nearly as great.

3) It increases OF complexity. The S bit allows a node to advertise a Rank that does not reflect the actual path packets take, as it does not include the link between the node and its sibling. It could be that this link is poor, metric-wise, yet the node cannot express this poorness to its children. The result is that an OF needs to constrain what sibling links can be used.

4) It consumes an extra bit in a packet and adds additional code to packet processing

In short, it has a significant cost, not a clear benefit, and is additional complexity that no-one is certain about. I believe we should remove it from -09.

Thoughts?

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Jun 2010 22:48:33 +0200

co-chair hat-off

On Jun 1, 2010, at 7:42 PM, Philip Levis wrote:

> A recurring theme in feedback on RPL is that simpler is better; LLNs  
> are often very cost-sensitive for microcontrollers, so less code is  
> better. It's easy to add mechanisms, bells and whistles: it's harder  
> to simplify.
>
> 1) The justification for the S bit comes from an idea proposed by  
> Dominique a year or so ago, which he evaluated in simulation. The S  
> bit has never been used or tested in an operational protocol. It is  
> a "new" idea, rather than standardizing common practice. This seems  
> like too low a bar to make it into a proposed standard in a domain  
> where there's huge operational experience.
>
> 2) The real benefit of the S bit comes from when a node that used to  
> send directly to a DODAG root loses that link, forcing it to move  
> down in the DODAG (increase Rank), which used to be illegal within a  
> DODAG iteration. Now that there's MaxDAGRankIncrease, this benefit  
> is not nearly as great.
>
> 3) It increases OF complexity. The S bit allows a node to advertise  
> a Rank that does not reflect the actual path packets take, as it  
> does not include the link between the node and its sibling. It could  
> be that this link is poor, metric-wise, yet the node cannot express  
> this poorness to its children. The result is that an OF needs to  
> constrain what sibling links can be used.
>

to be completely fair and the WG will provide feed-back, it allows for  
using sibling ... while limiting risk of loops, which may be quite  
beneficial in a number of topologies where detaching or poisoning the  
sub-DAG may take some time, thus helping with convergence time.

> In short, it has a significant cost, not a clear benefit, and is  
> additional complexity that no-one is certain about. I believe we  
> should remove it from -09.
>
> Thoughts?
>
> Phil
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Philip Levis <[email-masked]>
Date: Tue, 1 Jun 2010 13:51:45 -0700

On Jun 1, 2010, at 1:48 PM, JP Vasseur wrote:

> to be completely fair and the WG will provide feed-back, it allows for using sibling ... while limiting risk of loops, which may be quite beneficial in a number of topologies where detaching or poisoning the sub-DAG may take some time, thus helping with convergence time.

I agree -- but there are no experimental results that this matters. I covered the major case in 2. 

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Jun 2010 22:56:16 +0200

On Jun 1, 2010, at 10:51 PM, Philip Levis wrote:

>>> A recurring theme in feedback on RPL is that simpler is better;  
>>> LLNs are often very cost-sensitive for microcontrollers, so less  
>>> code is better. It's easy to add mechanisms, bells and whistles:  
>>> it's harder to simplify.
>>>
>>> Dominique a year or so ago, which he evaluated in simulation. The  
>>> S bit has never been used or tested in an operational protocol. It  
>>> is a "new" idea, rather than standardizing common practice. This  
>>> seems like too low a bar to make it into a proposed standard in a  
>>> domain where there's huge operational experience.
>>>
>>> 2) The real benefit of the S bit comes from when a node that used  
>>> to send directly to a DODAG root loses that link, forcing it to  
>>> move down in the DODAG (increase Rank), which used to be illegal  
>>> within a DODAG iteration. Now that there's MaxDAGRankIncrease,  
>>> this benefit is not nearly as great.
>>>
>>> 3) It increases OF complexity. The S bit allows a node to  
>>> advertise a Rank that does not reflect the actual path packets  
>>> take, as it does not include the link between the node and its  
>>> sibling. It could be that this link is poor, metric-wise, yet the  
>>> node cannot express this poorness to its children. The result is  
>>> that an OF needs to constrain what sibling links can be used.
>>>
>> to be completely fair and the WG will provide feed-back, it allows  
>> for using sibling ... while limiting risk of loops, which may be  
>> quite beneficial in a number of topologies where detaching or  
>> poisoning the sub-DAG may take some time, thus helping with  
>> convergence time.
>

But we also do not have strong evidence that 2) will work in all cases  
either and this is code-wise more challenging.
Not sure that the S is an issue really.

Cheers.

jP.

---

From: Philip Levis <[email-masked]>
Date: Tue, 1 Jun 2010 14:02:10 -0700

On Jun 1, 2010, at 1:56 PM, JP Vasseur wrote:

> But we also do not have strong evidence that 2) will work in all cases either and this is code-wise more challenging.

How is it code-wise more challenging? The S bit is on the forwarding path; max increase is part of routing. As I said, it seems to be an unnecessary bell and whistle. I'd hope that the bar for inclusion in an IETF proposed standard is higher than a slide deck and a few simulations.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Jun 2010 23:52:15 +0200

On Jun 1, 2010, at 11:02 PM, Philip Levis wrote:

>>>>> 1) The justification for the S bit comes from an idea proposed  
>>>>> by Dominique a year or so ago, which he evaluated in simulation.  
>>>>> The S bit has never been used or tested in an operational  
>>>>> protocol. It is a "new" idea, rather than standardizing common  
>>>>> practice. This seems like too low a bar to make it into a  
>>>>> proposed standard in a domain where there's huge operational  
>>>>> experience.
>>>>>
>>>>> 2) The real benefit of the S bit comes from when a node that  
>>>>> used to send directly to a DODAG root loses that link, forcing  
>>>>> it to move down in the DODAG (increase Rank), which used to be  
>>>>> illegal within a DODAG iteration. Now that there's  
>>>>> MaxDAGRankIncrease, this benefit is not nearly as great.
>>>>>
>>>>> sibling. It could be that this link is poor, metric-wise, yet  
>>>>> the node cannot express this poorness to its children. The  
>>>>> result is that an OF needs to constrain what sibling links can  
>>>>> be used.
>>>>>
>>>> to be completely fair and the WG will provide feed-back, it  
>>>> allows for using sibling ... while limiting risk of loops, which  
>>>> may be quite beneficial in a number of topologies where detaching  
>>>> or poisoning the sub-DAG may take some time, thus helping with  
>>>> convergence time.
>>>
>> But we also do not have strong evidence that 2) will work in all  
>> cases either and this is code-wise more challenging.
> How is it code-wise more challenging? The S bit is on the forwarding  
> path; max increase is part of routing. As I said, it seems to be an  
> unnecessary bell and whistle. I'd hope that the bar for inclusion in  
> an IETF proposed standard is higher than a slide deck and a few  
> simulations.
>

This is a trade-off ... what I was trying to say is that "some"  
mechanisms have been introduced that are new in the RPL spec. The S  
bit is one of them, which provides pretty obvious benefits for very  
reasonable cost. In general I do agree with your comments though:  
anything not necessary should be removed whenever possible. In that  
particular case, I'm not sure that the S bit adds that much complexity  
(we still need to perform other checks for the F, ... bits). Just my  
thoughts. Let's see what others think.

Cheers.

JP.

---

From: Philip Levis <[email-masked]>
Date: Tue, 1 Jun 2010 14:55:26 -0700

On Jun 1, 2010, at 2:52 PM, JP Vasseur wrote:

>> 
>> 
> 
> This is a trade-off ... what I was trying to say is that "some" mechanisms have been introduced that are new in the RPL spec. The S bit is one of them, which provides pretty obvious benefits for very reasonable cost.

I disagree that there's sufficient evidence that

  1) there are worthwhile benefits, or
  2) the cost is reasonable.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Jun 2010 23:56:48 +0200

On Jun 1, 2010, at 11:55 PM, Philip Levis wrote:

>> reasonable cost.

I have a different opinion (which is OK !) but let's see what others  
think.

Cheers.

JP.

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 1 Jun 2010 23:06:44 -0700

On Tue, Jun 1, 2010 at 2:56 PM, JP Vasseur <[email-masked]> wrote:
>>> mechanisms have been introduced that are new in the RPL spec. The S bit is
>>> one of them, which provides pretty obvious benefits for very reasonable
>>> cost.
>>
> I have a different opinion (which is OK !) but let's see what others think.

Increasing the bar is good, especially when it seems other mechanisms
in RPL also address the same problem, albeit differently (Phil's #2).

- om_p

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jun 2010 08:26:45 +0200

Hi Om and all:

I disagree with Phil that #2 addresses the same thing.

Say we have a simple triangle, A , B and C. A is root, B and C are siblings. 

If B fails to pass a packet directly to A for some transient link issue, it may use C without impacting the topology.

With #2, B has to either drop the packet or augment its rank. If it chooses the latter too quickly, and C does the same seconds later when it hits the same problem, then they rapidly count to whatever infinity limit is placed there. But they do not solve the problem. When infinity is reached, the packets will be dropped.

IMHO, #2 is a local repair mechanism when something is really broken. S addresses transients issues by enabling an alternate successor to both B and C in my simple triangle. And we have experimental evidence that it is actually a good idea.

I support keeping S.

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Omprakash Gnawali
> Sent: Wednesday, June 02, 2010 8:07 AM
> To: JP Vasseur
> Cc: ROLL WG
> Subject: Re: [Roll] S bit
> 
> Increasing the bar is good, especially when it seems other mechanisms in RPL
> also address the same problem, albeit differently (Phil's #2).
> 
> - om_p

---

From: Philip Levis <[email-masked]>
Date: Wed, 2 Jun 2010 05:58:07 -0700

> With #2, B has to either drop the packet or augment its rank. If it chooses the latter too quickly, and C does the same seconds later when it hits the same problem, then they rapidly count to whate…

This is a non-problem; you're still holding to a conception of adaption speed which doesn't actually occur. These kinds of misconceptions are exactly why we don't want to incorporate mechanisms based on convincing arguments. We want to set a higher bar, of implementations and experimental data.

Here's what happens:

1) B and C are sending messages to A. 

2) Link BA becomes poor. B increases its Rank to be greater than C's, starts routing through C.

3) Link CA becomes poor. Link BA becomes good again. C increases its Rank to be greater than B's, starts routing through B.

4) The packet passes from C to B, then back to C. C detects that there is a inconsistency, and resets its trickle timer. It sends a DIO that tells B it has a higher Rank. B compares the cost of routing through C and routing directly to A, and chooses A.

5) Node B finds that link BA is good again, and reduces its Rank.

That being said, the case you're arguing for: where we have two links that are oscillating in a mutually exclusive way, seems like a very, very narrow edge case whose presence or prevalence is dubious at best.

> IMHO, #2 is a local repair mechanism when something is really broken. S addresses transients issues by enabling an alternate successor to both B and C in my simple triangle. And we have experimenta…

There are plenty of protocols out there that work fine without S. There is no real evidence on its efficacy.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jun 2010 15:21:45 +0200

Hum:
> 2) Link BA becomes poor. B increases its Rank to be greater than C's,
starts
> routing through C.

2a) packets are lost that could have been routed via sibling
2b) after *some time* that we have enough evidence of persisting B->A
problems, B decides it should impact the topology
2c) B increases its Rank to be able to route to C and advertises it. C
gets the info it in time ... or not

> 
> 3) Link CA becomes poor. Link BA becomes good again. C increases its
Rank to
> be greater than B's, starts routing through B.

[Pascal] If C is aware of B's change then C goes deeper. 
If B has not reparented to A yet, then B being still parented to C, it
follows. Till infinity.

> 
> 4) The packet passes from C to B, then back to C. C detects that there
is a
> inconsistency, and resets its trickle timer. It sends a DIO that tells
B it has a
> higher Rank. B compares the cost of routing through C and routing
directly to
> A, and chooses A.

[Pascal] True, if one's Rank increase had been lost or not advertised
yet, we go through this resolution. 

The end result is still that B and C both go down, one at a time, each
time they reach a transmission problem, until they reach the floor.
This is the greedy behavior we tried to avoid from the start.

> That being said, the case you're arguing for: where we have two links
that are
> oscillating in a mutually exclusive way, seems like a very, very
narrow edge
> case whose presence or prevalence is dubious at best.

[Pascal] They do not know that are mutually exclusive. B fails to send
to A, so it tries C. If C is also unlucky, the S bit cause the drop.
Your approach is the one that actually require the mutually exclusive.
What's the point for B to go below C unless it expects that C has a
better transmission.
But then, how does it know? 
> 
> There are plenty of protocols out there that work fine without S.
There is no
> real evidence on its efficacy.

[Pascal] I think Dominique published such evidence. I found it quite
convincing.

Pascal]

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 02 Jun 2010 13:08:29 -0400

> From: Philip Levis <[email-masked]>
> Date: Tue, 1 Jun 2010 10:42:10 -0700
> 
> I propose that we remove the S bit (sibling bit used in routing,
> Section 8.2). 

I am in favor of removing the S bit.  I do not find the
experiments that have been run particularly convincing.
While it's a small thing in itself, as Phil says,
simplifying is hard.  You don't get a simple protocol by
only removing things that have no value at all.  For those
that think we should keep the S bit, can you suggest some
other ways to simplify RPL?

If the S bit does remain, it would be good if processing
it were made optional.  If a node never routes to
siblings it will never set the S bit and it should be
allowed to ignore the S bit in incoming packets.
As things stand it must check the S bit in order to
detect routing inconsistencies.

                           -Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Wed, 2 Jun 2010 12:32:27 -0700

> gets the info it in time ... or not

I don't understand any of this text. In my example, B is routing through C, hence through what was once a sibling. Can you please describe a precise set of packet and stage changes that make the problem happen?

> If B has not reparented to A yet, then B being still parented to C, it

Why hasn't B chosen A as one of the preferred parents? You seem to be operating under the assumption that there's delay in applying the objective function? I don't understand -- no wireless mesh or LLN protocol I know of works this way.

> This is the greedy behavior we tried to avoid from the start.

It doesn't happen, though -- hence my comment that I think you're operating under assumptions that aren't true.

> But then, how does it know? 

DIOs.

> [Pascal] I think Dominique published such evidence. I found it quite

You believe that a set of narrow simulation experiments are convincing evidence for an IETF standard? That's not even sufficient to publish an academic paper!

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Jun 2010 15:07:13 +0200

Hi Phil:

I am operating under the assumption that the time scale of the decision
that a link is going too bad is orders of magnitude longer than the
packet processing.
I do not think that exhausting retries on a single packet should cause
the topological churn. And until the topology changes, B's packets are
lost if it cannot use C.

My 2a, b, c is simply breaking your 'link BA becomes poor' in steps.
Without the sibling, we have packet loss and unnecessary topological
churn and correction.
If the link B->A is virtually B->A OR B->C +C->A then BA gains in
reliability.

Pascal

> From: Philip Levis [mailto:[email-masked]]
> Sent: Wednesday, June 02, 2010 9:32 PM
> To: Pascal Thubert (pthubert)
> Cc: Omprakash Gnawali; JP Vasseur; ROLL WG
> I don't understand any of this text. In my example, B is routing
through C,
> hence through what was once a sibling. Can you please describe a
precise set
> of packet and stage changes that make the problem happen?
> 
> >
> >>
> Why hasn't B chosen A as one of the preferred parents? You seem to be
> operating under the assumption that there's delay in applying the
objective
> function? I don't understand -- no wireless mesh or LLN protocol I
know of
> works this way.
> It doesn't happen, though -- hence my comment that I think you're
operating
> under assumptions that aren't true.
> 
> >
> You believe that a set of narrow simulation experiments are convincing
> evidence for an IETF standard? That's not even sufficient to publish
an
> academic paper!

---

From: Philip Levis <[email-masked]>
Date: Thu, 3 Jun 2010 07:38:07 -0700

> the topological churn. And until the topology changes, B's packets are

In both cases, it uses C; the only difference is whether B's Rank changes. The S bit basically says "there's a link being used whose metrics are not being included." I think this is a very poor idea. It made sense and was a good idea (worth evaluating) when nodes could only increase Rank with a sequence number change; now that they can safely increase Rank, the S bit seems superfluous. 

> If the link B->A is virtually B->A OR B->C +C->A then BA gains in

Right -- but the problem with this is that you're making a virtual link that does not actually express its cost. B continues to advertise a Rank derived from B->A when in reality its Rank should be derived from B->C + C->A. Pushing this to the Objective Function, saying it constrains which siblings can be used, adds even more complexity.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jun 2010 08:28:59 +0200

Hi Phil

> >
> > I am operating under the assumption that the time scale of the
> > decision that a link is going too bad is orders of magnitude longer
> > than the packet processing.
> In both cases, it uses C; the only difference is whether B's Rank
changes. The
> S bit basically says "there's a link being used whose metrics are not
being
> included." I think this is a very poor idea. It made sense and was a
good idea
> (worth evaluating) when nodes could only increase Rank with a sequence
> number change; now that they can safely increase Rank, the S bit seems
> superfluous.
> 
[Pascal] I certainly agree with you on the repair mechanisms in RPL. We
spent a lot of effort to put them in place and hopefully they are quite
stable now. We'll note that the DAGMaxRankIncrease can be set to zero in
which case from the above we agree that siblings seem like a good idea.

We seem to disagree on one major point that is not the repair, that's
how quickly B decides to augment its rank.  I do not think that making
decisions such as augmenting Rank too quickly is a good idea. I do not
believe in any convergence in those networks, but I hope that most of
the time, we can make steady, quasi-static changes that nodes adapt to
before other changes happen. To get there, we need to take time to
observe a situation before we act on it, and to do that, we need
alternate parents, or in the absence of such, siblings, to forward the
traffic in the meantime.

In the example above, if C also sends a packet, and it also fails to do
it, then it will also augment its rank. Now, both B and C think they are
parented to one another and we are in the collision that we also took
measures  to avoid in another chapter. I expect that without the
protective measures, the nodes will count to our controlled infinity
(DAGMaxRankIncrease), which is the greedy behavior we tried to avoid
since we started this spec. I really wish to see a simulation of  that
case. It seems that during all that churn, no packet can get out the
network. Sadly, the sibling situation always happens at least in one
place, that's the node closest to the root, one of the most critical
nodes in the network bar the root itself.

Our collision avoidance and the sibling operation are here to limit the
causes of loops and CTI. Those causes exist even in wired or WIFI.
Similarly, the minimum workable car has no safety belt. And I have
limited personal experience that the safety belt is really useful.
Still, it costs very little compared to my whole car. More importantly,
the real value is neither the car nor the cost of the belt, it is the
operational consequences of the crash for the driver. In a similar
fashion, I am not ready to remove a mechanism that could avoid the
consequences of losing packets for the customer installation.

I do agree with you that the real time operation in radio networks often
defeats expectations. But before, at the last minute, we remove our
security belts that have been there for all the RPL simulations and
implementations so far, I'd like to see that those are not impacted, and
I'd like to see a simulation of the triangle above, whether the protocol
operates as we expect or not, with sibling on / off, and
DAGMaxRankIncrease set to various values including 0 and high ones.

> Right -- but the problem with this is that you're making a virtual
link that does
> not actually express its cost. B continues to advertise a Rank derived
from B-
> >A when in reality its Rank should be derived from B->C + C->A.
Pushing this
> to the Objective Function, saying it constrains which siblings can be
used,
> adds even more complexity.
> 

[Pascal] Agreed. It is a transient fix, hot potato handling. A safety
belt does not prevent a crash but it may limit the consequences to your
body, which is appreciable enough.

At another time scale, again, I think we perfectly agree on what the
protocol should be doing and hopefully actually does.

Pascal

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 04 Jun 2010 07:50:46 -0400

> Date: Fri, 4 Jun 2010 08:28:59 +0200
> From: "Pascal Thubert (pthubert)" <[email-masked]>
> 
> [...] But before, at the last minute, we remove our
> implementations so far, I'd like to see that those are not impacted,

Pascal,

I think you make a some good points, but this is not one of
them.  We don't know how many of the RPL simulations and
implementations so far have ever turned on an S bit.  All we
know is that no one has reported any results, positive or
negative.  We have not tried it here at Ember.  I rather
doubt many people have, given that it is an optional feature
that may or may not have a significant impact.

How about if reserve the bit, requiring that implementations
accept either a one or a zero there but always send a zero?
The S bit can then be added back in at any point, should the
group decide to do so.  We might as well reserve a few bits
this way, given that there are lots of other ways to route
through siblings.

                                 -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jun 2010 15:58:50 +0200

Hi Richard:

You are correct, I do not have enough insight of what the current
implementations and simulations have been doing/testing. I hope someone
shimes in to give us more insight.

Being in the blind somewhat, I have to agree that we need to do
something about this; but then, dropping the sibling entirely seems like
a risk and a waste.

I'd favor a resolution that enables a given supplier to implement it
while keeping compatibility with another supplier that would not. 

Would you accept to give it a chance? If you do please read on:

One thing to note is that siblings are used to progress upwards, not
downwards, so when the S bit is set, the O bit is always reset. 
Say we have one node B that supports siblings and another node, C, which
does not.

Normal times (B and C really have a same Rank)
---------------------------------------------------------
B can send packets to C because it supports siblings but C cannot send
packets to B. So loops are impossible and we're cool.
C does not need to check the S bit. It just needs to reset it to avoid
misleading the next hop.

loop detection / repair (B and C have a different Rank)
------------------------------------------------------------------
- C is higher (smaller Rank). Since the O bit is reset, and B is of
lesser Rank, this is not detected as an error, and the packet can
progress as expected by B. We're cool.
- C is lower (higher Rank). Using C is actually a mistake and it is
detected because the O bit should be set for downwards traffic. Again,
we're fine.

Conclusion:

We can safely say that sibling support is completely optional. A node
that does not support sibling must reset the S bit, that's all it has to
do.

What do you think?

Pascal

> From: Richard Kelsey [mailto:[email-masked]]
> Sent: Friday, June 04, 2010 1:51 PM
> Cc: [email-masked]; [email-masked]
> > [...] But before, at the last minute, we remove our security belts
> > that have been there for all the RPL simulations and implementations
> > so far, I'd like to see that those are not impacted,
> 
> Pascal,
> 
> I think you make a some good points, but this is not one of them.  We
don't
> know how many of the RPL simulations and implementations so far have
> ever turned on an S bit.  All we know is that no one has reported any
results,
> positive or negative.  We have not tried it here at Ember.  I rather
doubt
> many people have, given that it is an optional feature that may or may
not
> have a significant impact.
> 
> How about if reserve the bit, requiring that implementations accept
either a
> one or a zero there but always send a zero?
> The S bit can then be added back in at any point, should the group
decide to
> do so.  We might as well reserve a few bits this way, given that there
are lots
> of other ways to route through siblings.
> 
>                                  -Richard Kelsey

---

From: Philip Levis <[email-masked]>
Date: Fri, 4 Jun 2010 07:35:48 -0700

Pascal,

There are many routing protocols today for LLNs which work well; none of them has the S bit. What is the risk? 

Our mantra from implementers since -06 has been to simplify. *Including* the S bit is a waste: a waste of reader's cognitive load, implementer's effort, and administrator's troubleshooting. The goal of RPL is to standardize current, well-understood, and well-accepted practice, right? 

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Jun 2010 17:46:19 +0200

Hi Phil: 

> There are many routing protocols today for LLNs which work well; none
of
> them has the S bit. What is the risk?

Work well is in the eye of the beholder. Are there really so many of
them deployed for any mission critical operation? And no one will come
up saying that the protocol he sells today might have severe issues if
used that way. RPL has a pretty high bar since there is no higher-end
protocol for this environment at the IETF. And it is well known to
routing people that control churn and count to infinity are not
desirable behaviors; it does not take a 24th degree in LLNs to know
that.

> The goal of RPL is to standardize
> current, well-understood, and well-accepted practice, right?

I agree with the general principle. I disagree to take such principle as
an absolute constraints, because very few things in this world are
actually well understood, and nothing in this spec would actually pass
that bar. OTOH there is value in a protocol to provide openings for
different implementations to propose a competitive edge on the market,
as long as compatibility is guaranteed. From my analysis, people do not
have to understand siblings if they do not want to. An implementation is
free to ignore it, and see if that makes a better, cheaper
implementation.  

Anyway I think you and I have exhausted our arguments. Someone else as
to give his say now. I'd like to hear from people who actually deployed
these things to a relevant scale and had to troubleshoot it  whether he
thinks that we're better off with or without siblings.

What troubles me from your words is that removing the sibling seems to
force people to use a non-zero DAGMaxRankIncrease. I do not think that
this is acceptable.
In fact, if I was coned to simplify RPL further, I'd start there. I
think that the proposal I made gives adequate chances to implementers to
do what they think relevant for their businesses and I'd leave it at
that.

Best,

Pascal

> Sent: Friday, June 04, 2010 4:36 PM
> Cc: Richard Kelsey; [email-masked]
> > implementations and simulations have been doing/testing. I hope
> > someone shimes in to give us more insight.
> >
> > something about this; but then, dropping the sibling entirely seems
> > like a risk and a waste.
> 
> Pascal,
> 
> There are many routing protocols today for LLNs which work well; none
of
> them has the S bit. What is the risk?
> 
> Our mantra from implementers since -06 has been to simplify.
*Including*
> the S bit is a waste: a waste of reader's cognitive load,
implementer's effort,
> and administrator's troubleshooting. The goal of RPL is to standardize
> current, well-understood, and well-accepted practice, right?
> 
> Phil

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Fri, 4 Jun 2010 18:44:40 -0400

Hi.

> other ways to simplify RPL?

I think what Richard is saying is exactly my opinion.

> detect routing inconsistencies.

In terms of implementation, although I haven't gone through serious stress tests with my code yet, I don't recall seeing any cases where the S-bit played a critical role. Very vague but still I guess this post will be the only post up to now based on real implementation experience. I've been doing a few tests recently (mostly for the goal of debugging) but in no cases have I seen the use of the S-bit. Of course this can be an implementation specific and environment specific observation but that's what I see from here :) I don't see the point of having a backup plan after another back up plan to deal with a routing inconsistency.

-John 

>                           -Richard Kelsey

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 14:02:53 +0200

Hi John

 > I don't
> see the point of having a backup plan after another back up plan to
deal with
> a routing inconsistency.

The current spec has 3 degrees of response to 3 degrees of problems, not
backup plans for backup plans.

1) transient link failure 
 This is addressed by having multiple parents and for the lack of enough
parents, siblings; because they can forward traffic, nodes with alt
parents and siblings may stay longer expecting the preferred parent to
come back and avoid topological churn.

2) permanent link failure with recoverable impact
 This is addressed by the local repair mechanism. A node can either play
it in classical DV (RIP) fashion, or poison/repair.

3) irrecoverable damage
When the local repair fails, a global repair throws a new version of the
DODAG that rebuilds the whole topology.

It has been discussed early in this ML that 3) could potentially be
enough. There was good support for this and it seems that a piece of the
industry lives like that. But sometime it would mean either wait a too
long a time to fix things, or killing a fly with an expensive bazooka.
So the group decided to have faster local mechanisms on top.

At a different but still sensible order of magnitude, the same reasoning
applies between 1 and 2). It can reasonably be asserted that we could
live with 2 only. Yet parents and siblings avoid the topological churn
of a node going down that 2) causes. Parents could be enough if all
nodes had them; sadly, parents are not always there when you need them,
and the most sensitive node is actually the one closest to the root,
because by definition it has no alternate parent. If that node goes down
and back up, a large chunk of the DODAG will follow the pumping effect. 

So the node that does not have a alternate parent is effectively the one
that will cause the most churn if its uplink has a transient failure. If
we do not give this node an alternative, we force it to react too
quickly to transient failures, or lose many packets. No good choice
there. 

How long does your implementation wait till it decides that a link is
goes down? Does it react instantly to the loss of the last parent and
start local repair?

Pascal

> Sent: Saturday, June 05, 2010 12:45 AM
> To: Richard Kelsey
> Cc: [email-masked]
LLNs
> > I am in favor of removing the S bit.  I do not find the experiments
> > that have been run particularly convincing.
> > While it's a small thing in itself, as Phil says, simplifying is
hard.
> > You don't get a simple protocol by only removing things that have no
> > value at all.  For those that think we should keep the S bit, can
you
> > suggest some other ways to simplify RPL?
> >
> 
> > If the S bit does remain, it would be good if processing it were
made
> > optional.  If a node never routes to siblings it will never set the
S
> > bit and it should be allowed to ignore the S bit in incoming
packets.
> > As things stand it must check the S bit in order to detect routing
> > inconsistencies.
> >
> 
> In terms of implementation, although I haven't gone through serious
stress
> tests with my code yet, I don't recall seeing any cases where the
S-bit played
> a critical role. Very vague but still I guess this post will be the
only post up to
> now based on real implementation experience. I've been doing a few
tests
> recently (mostly for the goal of debugging) but in no cases have I
seen the
> use of the S-bit. Of course this can be an implementation specific and
> environment specific observation but that's what I see from here :) I
don't
> see the point of having a backup plan after another back up plan to
deal with
> a routing inconsistency.

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Mon, 7 Jun 2010 09:12:11 -0400

Pascal,
> goes down? Does it react instantly to the loss of the last parent and

My argument was that having a pool of three (at least in my implementation) potential parents seems to neglect the need for the S-bit. It seems that there is not a case where all three potential parents die out simultaneously unless there is a node fault on the transmitting node itself (yes... my code is still buggy). Indeed, my implementations do react directly to the lack of parents in the parent set but this as well has never (strong word but true for my case until now) been seen. :)

-John

------
JeongGil Ko (John)
Ph.D. Student

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Mon, 7 Jun 2010 11:40:51 -0400

Pascal.

You can probably imply this in the previous email that if a node is the 'closest' to the root, then the root will be the only parent. "Three 'at most'" may be a clearer way of saying this. If you can only hear a single node that has a lower rank than you (in any case) then that will be the only (potential) parent.

-John

On Jun 7, 2010, at 11:36 AM, Pascal Thubert (pthubert) wrote:

> So John,  does your sentence “three (at least in my implementation) potential parents seems to neglect the need for the S-bit.” apply to the node closest to the root?
>  
> Pascal
>  
> From: JeongGil (John) Ko [mailto:[email-masked]] On Behalf Of JeongGil Ko (John)
> Sent: Monday, June 07, 2010 5:24 PM
> Those nodes will only have a single parent, the root. 
> Given a node rank R > root rank = 1, other nodes with rank values 1 < R' < R will also be added to the potential parent list. 
> If the root (rank = 1) is the only node that it can hear, than that will be the only potential parent.
>  
> -john
>  
> On Jun 7, 2010, at 11:12 AM, Pascal Thubert (pthubert) wrote:
> 
> 
> Hi John:
>  
> How does the node closest to the root find 3 parents?
>  
> Pascal
>  
> From: JeongGil (John) Ko [mailto:[email-masked]] On Behalf Of JeongGil Ko (John)
> Sent: Monday, June 07, 2010 3:12 PM

------
JeongGil Ko (John)
Ph.D. Student

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Mon, 7 Jun 2010 11:24:06 -0400

Pascal

-john

------
JeongGil Ko (John)
Ph.D. Student

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 17:12:59 +0200

Hi John:

Pascal

From: JeongGil (John) Ko [mailto:[email-masked]] On Behalf Of
JeongGil Ko (John)

Pascal,

	How long does your implementation wait till it decides that a
link is
	goes down? Does it react instantly to the loss of the last
parent and
	start local repair?

My argument was that having a pool of three (at least in my
implementation) potential parents seems to neglect the need for the
S-bit. It seems that there is not a case where all three potential
parents die out simultaneously unless there is a node fault on the
transmitting node itself (yes... my code is still buggy). Indeed, my
implementations do react directly to the lack of parents in the parent
set but this as well has never (strong word but true for my case until
now) been seen. :)

-John

Pascal

-----Original Message-----

	From: [email-masked] [mailto:[email-masked]] On
Behalf

Of

JeongGil Ko (John)

	To: Richard Kelsey

	Cc: [email-masked]

	Hi.

			A recurring theme in feedback on RPL is that
simpler is better;

LLNs

		are often very cost-sensitive for microcontrollers, so
less code is

			better. It's easy to add mechanisms, bells and
whistles: it's

harder

		to simplify.

			I propose that we remove the S bit (sibling bit
used in routing,

			Section 8.2).

experiments

simplifying is

hard.

	You don't get a simple protocol by only removing things that
have no

		value at all.  For those that think we should keep the S
bit, can

you

	 

it were

made

	optional.  If a node never routes to siblings it will never set
the

S

packets.

	As things stand it must check the S bit in order to detect
routing

		inconsistencies.

	In terms of implementation, although I haven't gone through
serious

stress

S-bit played

only post up to

tests

seen the

	environment specific observation but that's what I see from here
:) I

don't

deal with

a routing inconsistency.

	-John

		                         -Richard Kelsey

		Roll mailing list

		[email-masked]

	 

	------

	JeongGil Ko (John)

	Ph.D. Student

	Johns Hopkins University

	Roll mailing list

	[email-masked]

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 17:36:02 +0200

So John,  does your sentence "three (at least in my implementation)
potential parents seems to neglect the need for the S-bit." apply to the
node closest to the root?

Pascal

Pascal

Given a node rank R > root rank = 1, other nodes with rank values 1 < R'
< R will also be added to the potential parent list. 

If the root (rank = 1) is the only node that it can hear, than that will
be the only potential parent.

-john

Hi John:

Pascal

Pascal,

-John

Pascal

-----Original Message-----

Of

JeongGil Ko (John)

	To: Richard Kelsey

	Cc: [email-masked]

	Hi.

LLNs

harder

		to simplify.

			Section 8.2).

hard.

you

	 

made

S

packets.

		inconsistencies.

stress

S-bit played

only post up to

tests

seen the

don't

deal with

a routing inconsistency.

	-John

		                         -Richard Kelsey

		Roll mailing list

		[email-masked]

	 

	------

	JeongGil Ko (John)

	Ph.D. Student

	Johns Hopkins University

	Roll mailing list

	[email-masked]

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 7 Jun 2010 18:26:11 +0200

John:

Ø  You can probably imply this in the previous email that if a node is the 'closest' to the root, then the root will be the only parent

I certainly do. I also gathered that the presence of 3 parents allowed to  "neglect the need for the S-bit", iow no need for siblings when you have 3 parents.

And I agree with both. But then, it appears that to the node closest to the root does not have 3 parents. So it needs sibling to get an alternate doesn't it? 

Pascal

Sent: Monday, June 07, 2010 5:41 PM

Pascal.

-John

So John,  does your sentence "three (at least in my implementation) potential parents seems to neglect the need for the S-bit." apply to the node closest to the root?

Pascal

Pascal

-john

Hi John:

Pascal

Pascal,

-John

Pascal

-----Original Message-----

	From: [email-masked] [mailto:[email-masked]] On Behalf

Of

JeongGil Ko (John)

	To: Richard Kelsey

	Cc: [email-masked]

	Hi.

LLNs

			better. It's easy to add mechanisms, bells and whistles: it's

harder

		to simplify.

			Section 8.2).

hard.

you

	 

made

S

packets.

		inconsistencies.

stress

S-bit played

only post up to

tests

seen the

don't

deal with

a routing inconsistency.

	-John

		                         -Richard Kelsey

		Roll mailing list

		[email-masked]

	 

	------

	JeongGil Ko (John)

	Ph.D. Student

	Johns Hopkins University

	Roll mailing list

	[email-masked]

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

---

From: Philip Levis <[email-masked]>
Date: Mon, 7 Jun 2010 09:43:14 -0700

Pascal,

We need to make RPL simpler whenever we can. The tendency is always to add options and add complexity. It's hard, but when we can, we also need to remove mechanisms that have become of very limited benefit. Here we have someone actually implementing and testing RPL commenting that the S bit doesn't seem to be useful. If you think he's mistaken, maybe you should implement RPL and experimentally examine the cases you're presenting?

Phil

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Mon, 7 Jun 2010 12:45:37 -0400

Pascal.

Let me do some more testing with the code but I find it an unlikely case that many of the nodes will stand alone with the root as its only potential parent. Even so, having the sibling forwarding for this case 'only' seems like a waste of resources for all the other nodes (given that practically the same code will be programmed on all the nodes in compile time -- all the other nodes are going to have the sibling forwarding code without a good use case). I believe we can simplify the RPL specs and say that the node (that has a single connection to the root) will perform recovery at the point it loses connection. I don't see this as a huge bazooka and neither do I see disconnection at a link close to the root a 'fly' :) It seems as though you are also agreeing with me that for other cases (besides this extreme case with the root) just having substitute potential parents can do the trick. I can probably grab some numbers on the additional resource usage with and without the sibling support in the next few weeks and quantify the overhead (really busy with random stuff lately). 

- John

On Jun 7, 2010, at 12:26 PM, Pascal Thubert (pthubert) wrote:

> I certainly do. I also gathered that the presence of 3 parents allowed to  “neglect the need for the S-bit”, iow no need for siblings when you have 3 parents.
> And I agree with both. But then, it appears that to the node closest to the root does not have 3 parents. So it needs sibling to get an alternate doesn’t it?
>  
> Pascal
>  

------
JeongGil Ko (John)
Ph.D. Student

---

From: Philip Levis <[email-masked]>
Date: Mon, 7 Jun 2010 10:49:41 -0700

> And I agree with both. But then, it appears that to the node closest to the root does not have 3 parents. So it needs sibling to get an alternate doesn’t it?

It's worth noting that there are many different implemented and successfully deployed protocols that do not have this feature yet seem to work fine. There are several options:

1) Move deeper in the DODAG (if DAGMaxRankIncrease allows it).
2) Wait for a global repair event.
3) Wait until the link returns; if it's a persistent failure you don't want to be using the S bit regardless.

My concern with this discussion is that it doesn't seem to be one of tradeoffs. Of course the S bit can possibly be useful. But we need to trade off the possible benefit with its cost (increased complexity). John's point is that the benefit seems very very marginal.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jun 2010 08:50:11 +0200

Hi John:

I am not talking about many. I am talking about the node closest to the root. It appears to me that 100% of the networks have such a node.

As a result, 100% of the networks have at least one node that can only have a sibling as alternate path. That's not exactly marginal.

If RPL has something dramatically different than the art iof routing, it is that absolute requirement to allow multiple alternates, because of the very nature of the links we're dealing with.

This is why RPL has implemented the 3 lines of defense I discussed earlier. Removing siblings is dropping the first line on the most critical node in the network, bar the root itself.

About the bazooka, say you have a network with hundreds of nodes; and the node closest to the root has to augment its Rank. How many nodes in the network will have to do so?

Pascal

Sent: Monday, June 07, 2010 6:46 PM

Pascal.

- John

John:

Pascal

Pascal.

-John

Pascal

Pascal

-john

Hi John:

Pascal

Pascal,

-John

Pascal

-----Original Message-----

Of

JeongGil Ko (John)

	To: Richard Kelsey

	Cc: [email-masked]

	Hi.

LLNs

harder

		to simplify.

			Section 8.2).

hard.

you

	 

made

S

packets.

		inconsistencies.

stress

S-bit played

only post up to

tests

seen the

don't

deal with

a routing inconsistency.

	-John

		                         -Richard Kelsey

		Roll mailing list

		[email-masked]

	 

	------

	JeongGil Ko (John)

	Ph.D. Student

	Johns Hopkins University

	Roll mailing list

	[email-masked]

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

---

From: "JeongGil Ko (John)" <[email-masked]>
Date: Tue, 8 Jun 2010 09:18:01 -0400

Pascal,

> As a result, 100% of the networks have at least one node that can only have a sibling as alternate path. That’s not exactly marginal.

Not all nodes that are connected to the root will have the root as the only potential parent. I'm sure you can see the case where a node is connected to a root but also has parents with a lower rank (that can also be connected to the root; may be only to the root and maybe not). Therefore, on a network's perspective, losing the 'critical path' (the path where the only alternative path is a sibling) will not be blocking data delivery and the network should have time to recover from link faults while the packets go through different paths. 

>  
> If RPL has something dramatically different than the art iof routing, it is that absolute requirement to allow multiple alternates, because of the very nature of the links we’re dealing with.

Agreed that the nodes close to the node closest to the root will have to change their rank values. However, as the distance gets farther this will go away given that we do not have a single path but multiple potential parent sets. Thus, the node closest to the root will not necessarily affect the rank computation to all 'hundreds of nodes'.

-John 

------
JeongGil Ko (John)
Ph.D. Student

---

From: Richard Kelsey <[email-masked]>
Date: Tue, 08 Jun 2010 09:52:00 -0400

> Date: Tue, 8 Jun 2010 08:50:11 +0200
> I am not talking about many. I am talking about the node closest to the =
> root. It appears to me that 100% of the networks have such a node.

But not a unique such node.  Unless the rank is very
fine-grained, many if not most neworks will have two or more
nodes at that minimum distance.  If there is only one such
node then sibling routing won't help it.

> About the bazooka, say you have a network with hundreds of nodes; and
> the node closest to the root has to augment its Rank. How many nodes in
> the network will have to do so?

You can't have it both ways.  If that closest node has no
siblings then the ranks will go up whether or not we have
the 'S' bit.  If that closest node has siblings at the same
rank, then having it increase its rank may not affect any
other nodes, if those other nodes can route through a sibling
instead.

I think that we should move the 'S' bit to a separate draft,
for two reasons.  The first is that, as Pascal says, RPL now
has three ways to react to link changes ('S' bit, local rank
increase, rebuild from root).  That seems like too much belt
and suspenders for what is supposed to be a simple protocol.

The other reason is that I don't think we have a good
understanding of how to best make use of siblings.  Is one
sibling hop the right number?  How to pick which sibling?
How does rank granularity affect sibling routing?  No one
seems to have much experience with this.

                                 -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jun 2010 17:02:29 +0200

> > I am not talking about many. I am talking about the node closest to
> > the = root. It appears to me that 100% of the networks have such a
node.
> 
> But not a unique such node.  Unless the rank is very fine-grained,
many if not
> most neworks will have two or more nodes at that minimum distance.  If
> there is only one such node then sibling routing won't help it.

[Pascal] Yes, that's the expectation. Density has it that there are
multiple 
siblings but the strict topological order prevents from using it. This
the sibling
model that makes the strict order a per packet thing as opposed to a
global
thing. 

> > the node closest to the root has to augment its Rank. How many nodes
> > in the network will have to do so?
> 
> You can't have it both ways.  If that closest node has no siblings
then the
> ranks will go up whether or not we have the 'S' bit.  If that closest
node has
> siblings at the same rank, then having it increase its rank may not
affect any
> other nodes, if those other nodes can route through a sibling instead.

[Pascal] 
The fact that siblings are at a same rank does not mean that a child
sees equal path
Through them. There's probably a shadow cone behind that node that does
not
Have equal cost multipath, though nodes inside the cone might have
alternate parents
with a rank between self and preferred parent. 

That cone will be impacted each time the top link fluctuates. 
Some nodes will have to augment their rank, others will have to update
their set of parents.

Let's draw it for clarity:

In this picture, the diagonals cost 1.4 whereas the edges cost 1.

                                              A

                             B             root          C 

                             D               E              F

           G              H               I                J
K

          M            N               O               P
Q          

A, B, C, and D are at a same rank  1. D and F are at 1.4.
I is at 2, J and H are at 2.4, G and K at 2.8, 
M and Q at 3.8, P and N and 3.4, and O at 3.

Say that we have a strict order and E is the node closest to the root. 
In order to keep routing, it has to increment its rank and make it 2.4,
to that it can use some of {B, D, F, C}.

Now:

I is at 2.8,  and O at 3.8 .... that's the piece of the shadow cone
that's all dark
H, J have to remove E from their parent set
N, P have to remove I from their parent set

Etc...

As soon as the transient error on the link terminates, E restores its
position as 
1 and O and I are pumped back up. The real question is how often
transient link 
errors happen and what is their duration if there are many short errors,
then
the pumping might be annoying.

The cone might close at a certain distance, or on the contrary grow
larger. 

> I think that we should move the 'S' bit to a separate draft, for two
reasons.
> The first is that, as Pascal says, RPL now has three ways to react to
link
> changes ('S' bit, local rank increase, rebuild from root).  That seems
like too
> much belt and suspenders for what is supposed to be a simple protocol.

[Pascal] Sibling and parents are the same method of alternate
forwarding;
sibling just augments the set of feasible successors so that more nodes
can play that game
Then as you say, local repair, and then global repair.

> The other reason is that I don't think we have a good understanding of
how
> to best make use of siblings.  Is one sibling hop the right number?
How to
> pick which sibling?
> How does rank granularity affect sibling routing?  No one seems to
have
> much experience with this.

[Pascal] Agreed. 
What I want to make sure is that the group understand as much as
possible 
the choice that is being made here. Then we can make a poll and see
whether
we keep, remove or make siblings optional.

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 8 Jun 2010 17:11:42 +0200

Hi John:

Thus, the node closest to the root will not necessarily affect the rank computation to all 'hundreds of nodes'.

Certainly. But the shadow cone might spread to the end of the network. What I want to get to is the influence of short disruptions, and how quickly a node reacts to a link apparently down.

I do not know if the spec has enough text about it. If you have a certain history and or certain guess of the stats of the link failure, then you can figure a good time to wait before you declare the link down and augment your rank. During that time, it's good that you have an alternate parent or a sibling to forward your packets to. If you don't wait, then you cannot filter out the many transient failures that you see on radios. But if you wait and have no alternate, you drop packets. 

Anyway. I trust that most that needed to be said to make the stakes clear was said. Let's see what the group decides.

Pascal

Sent: Tuesday, June 08, 2010 3:18 PM

Pascal,

 

 

-John 

Pascal

Pascal.

- John

John:

Pascal

Pascal.

-John

Pascal

Pascal

-john

Hi John:

Pascal

Pascal,

-John

Pascal

-----Original Message-----

Of

JeongGil Ko (John)

	To: Richard Kelsey

	Cc: [email-masked]

	Hi.

LLNs

harder

		to simplify.

			Section 8.2).

hard.

you

	 

made

S

packets.

		inconsistencies.

stress

S-bit played

only post up to

tests

seen the

don't

deal with

a routing inconsistency.

	-John

		                         -Richard Kelsey

		Roll mailing list

		[email-masked]

	 

	------

	JeongGil Ko (John)

	Ph.D. Student

	Johns Hopkins University

	Roll mailing list

	[email-masked]

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

 

------

JeongGil Ko (John)

Ph.D. Student

Johns Hopkins University

---

From: JP Vasseur <[email-masked]>
Date: Wed, 9 Jun 2010 15:26:44 +0200

Hi Pascal,

Co-chair hat off -- I think that this is a good summary. I personally  
do see
situations where sibling could help especially with failures closer to  
the
root or sparser networks. Just one opinion among others. Let's see what
people say on the list and hopefully we'll quickly get a consensus.

JP.

---

From: Philip Levis <[email-masked]>
Date: Wed, 9 Jun 2010 08:30:22 -0700

On Jun 9, 2010, at 6:26 AM, JP Vasseur wrote:

> Hi Pascal,
> 
> Co-chair hat off -- I think that this is a good summary. I personally do see
> situations where sibling could help especially with failures closer to the

Experimental results and implementation experience should have much more weight than vision or imagination. Our goal in RPL is to standardize current practice, not re-invent the wheel.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 9 Jun 2010 17:35:35 +0200

On Jun 9, 2010, at 5:30 PM, Philip Levis wrote:

> Experimental results and implementation experience should have much  
> more weight than vision or imagination. Our goal in RPL is to  
> standardize current practice, not re-invent the wheel.

Phil, IETF is driven by consensus. Everybody should express his opinion.

Thanks.

JP.

---

From: "Pete St. Pierre" <[email-masked]>
Date: Wed, 9 Jun 2010 08:39:49 -0700

> Experimental results and implementation experience should have much more weight than vision or imagination. Our goal in RPL is to standardize current practice, not re-invent the wheel.

Since I'm not currently working on an implementation of RPL, I've sat mostly on the sidelines of this discussion. But considering that it seems that most of the feedback from implementers is that it is either being ignored (as a MAY requirement), or is implemented but of limited value in practice, I'd favor simplification by omitting this feature.

If anyone has practical experience or data that shows the 'S' bit to be of significant value, I'm willing to re-evaluate. For now, I'd rather see -09 simplified.

...Pete

--
Pete St. Pierre
[email-masked]
Sun Labs
Oracle 
16 Network Circle
Menlo Park, CA 94025

---

From: Joakim Eriksson <[email-masked]>
Date: Wed, 09 Jun 2010 18:16:24 +0200

> If anyone has practical experience or data that shows the 'S' bit to be of significant value, I'm willing to re-evaluate. For now, I'd rather see -09 simplified.

We ignore it in our imlementation so for us it is fine to remove it from the
specification.

Best regards,
-- Joakim Eriksson, SICS

---

From: Omprakash Gnawali <[email-masked]>
Date: Wed, 9 Jun 2010 11:44:20 -0700

On Wed, Jun 9, 2010 at 9:16 AM, Joakim Eriksson <[email-masked]> wrote:
>>> Experimental results and implementation experience should have much more
>>> weight than vision or imagination. Our goal in RPL is to standardize current
>>> practice, not re-invent the wheel.
>>>
>>> Phil
>>
>> Since I'm not currently working on an implementation of RPL, I've sat
>> mostly on the sidelines of this discussion. But considering that it seems
>> that most of the feedback from implementers is that it is either being
>> ignored (as a MAY requirement), or is implemented but of limited value in
>> practice, I'd favor simplification by omitting this feature.
>>
>> If anyone has practical experience or data that shows the 'S' bit to be of
>> significant value, I'm willing to re-evaluate. For now, I'd rather see -09
>> simplified.
>

For lack of evidence that the implementers have found this feature
useful, I vote for dropping the S bit.

- om_p

---

From: Nicolas DEJEAN <[email-masked]>
Date: Thu, 10 Jun 2010 12:52:01 +0200

WG,

In my opinion, completely forgetting siblings does not seem a good idea.
I think we should at least keep some extra bits in the RPL specs and
provide a separate draft for the siblings.

However, Pascal's summary about DAG repair (3 different cases) clearly
underlines that siblings usage will solve the transcient issues
without generating additional control traffic.
I would prefer keeping the mechanism in the RPL specs.

An additional comment:
The description of repair mechanisms provided by Pascal is quite clear
(in fact quite much clearer than in rpl-08).
It would be fine if rpl-09 clarify DAG repair mechanisms by using
Pascal's description.

Best regards,

Nicolas.

---

From: <[email-masked]>
Date: Thu, 10 Jun 2010 16:25:13 +0200

Hello all,

Sorry for being late in joining the pie throwing party ;-)

My name has been associated a couple times with the now infamous S bit, so I feel I'm allowed to provide some opinion on the topic, although I reckon I don't currently have a large real network running RPL with siblings routing enabled.

First, some story straightening to http://www.ietf.org/mail-archive/web/roll/current/msg04147.html especially to point 1) The S bit was proposed as a simplification to the previously existing mechanism of routing through siblings, which was in need of some loop prevention/detection mechanism. The S bit in itself was therefore not an addition to RPL, but already a simplification. So, without knowing, Phil is actually fighting alongside with me, not against me. Just he goes one step further.

To come back to facts, our study used simulation and static analysis based on link data captured on a real sensor network. At the time (summer 2009), that network did not run RPL as a routing protocol.

Our findings were (sligthly reformulated for the spirit of this discussion ;-) :
1) it's easy to show that siblings are useless if you use too fine-grained ranks.
2) it's easy to show that siblings are useless if you have a high density of good links. 
3) once 1) and 2) are out of the way, the benefit of siblings cannot be replaced by that of more parents, because the parenthood relationship is unidirectional whereas the siblings relationship is bidirectional. In other words, only one node in a pair can be a parent to the other one, whereas both nodes in a pair can be siblings to each other.
4) on the data set we used, one sibling hop provided most of the benefits of siblings, while being very simple to implement. And I mean very. One bit to set or test while forwarding. No impact on the routing plane. The question again is not the complexity of the S bit, it's the complexity of siblings.
For those of you interested, these findings were accepted as an academic paper at WCNC2010, probably while the program committee was not looking.

As Richard very relevently points out at the bottom of http://www.ietf.org/mail-archive/web/roll/current/msg04210.html , there are still some questions on how to make the best use of one-sibling forwarding, and I don't argue with that.

However, from a previous real world experiment, we learned than adjusting the structure too quickly is very energy consuming. I'm concerned at reading in http://www.ietf.org/mail-archive/web/roll/current/msg04163.html
"4)... C detects that there is a inconsistency, and resets its trickle timer. It sends a DIO ..."
As Pascal expressed several times, I believe that forwarding through siblings is a quick fix for a transient situation. Then, when the node has assessed the mid-term situation, OF and DAGRanks kick in again if they need to and reflect actual costs.

Energy-consumption is a tighter constraint on most LLN nodes than code-size.
Code-size was the first argument in http://www.ietf.org/mail-archive/web/roll/current/msg04147.html for removing "the S bit".
Until I see experimental comparative data on energy-consumption of the alternate proposal, I suggest we keep siblings in RPL. Either with a single S bit, or 2 bits as in an earlier version.  Leave to the systems that want to use siblings the possibility to do so. If this proves a differentiating feature on the market, it will become pervasive.
If cognitive load is an issue, keep the bits reserved and move the text to a separate draft.

Best,

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de JP Vasseur Envoyé : mercredi 9 juin 2010 15:27 À : Pascal Thubert (pthubert) Cc : [email-masked] Objet : Re: [Roll] S bit

Hi Pascal,

Co-chair hat off -- I think that this is a good summary. I personally do see situations where sibling could help especially with failures closer to the root or sparser networks. Just one opinion among others. Let's see what people say on the list and hopefully we'll quickly get a consensus.

JP.