Subject: [Roll] Bringing the S-bit discussion to a close

From: culler <[email-masked]>
Date: Thu, 10 Jun 2010 21:11:20 -0700

Over the course of the RPL design process we have proposed a number of  
important and interesting ideas and gone through a process of  
improvement and refinement on them.  We have also demonstrated  
tremendous discipline in being able to take an interesting and  
potentially beneficial idea that we have worked on for a great deal of  
time, put a lot of good work into, and yet decided to put it aside  
when it was determined that it presented significant complexity and  
that there was not a body of established practice in LLNs to  
substantiate the value of the particular optimization.  And that it  
was an optimization.

An important prior example was the piecewise source routing that was  
in RPL for many versions.  We recognized that it addressed an  
important issue.  At the same time it introduced considerable  
complexity.  It had benefits.  It had costs.  It would be possible to  
move forward without it, learn more through experience, and  
reconsider.  We reached consensus that the minimum viable protocol  
(MVP) approach would be to drop the general scheme and just support  
the two extremes - stateless and stateful - which addressed the most  
prevalent usage scenarios.  As a result of the simplification, we were  
able to make key decisions and focus our attention on other important  
outstanding issues. RPL progress accelerated and we moved closer to  
achieving our goal of getting a high quality solution into the world  
on time.

We have now had  considerable discussion on the mailing list and on  
the author calls reconsidering the S-bit.  We all understand that  
there are particular situations where a path might reach a point where  
it has only one choice and that link has gone away, but it could make  
progress if it could detour through a sibling.  We understand that in  
these situations the other mechanisms in RPL will eventually repair  
the problem.  We understand that sibling routes amplify the potential  
for loops and change the repair and convergence behavior.  We  
understand that there are numerous mechanisms for addressing the  
problems presented by siblings.  S-bit is just one of the  
possibilities.  We also recognize that there is not a substantial body  
of established practice to guide choices related to this  
optimization.  It is an important area that deserves substantial  
further investigation.  We can move forward with the simpler  
approach.  We can leave room to introduce the s-bit later, or we might  
use ids to break ties.  We can produce a separate draft that fully  
develops the approach as we learn from the body of soon (hopefully) to  
be deployed LLNs.  It is an optimization, not a fundamental  
requirement.  One of potential many.

Thus, we have reached a second opportunity to demonstrate our design  
discipline in the context of these challenging links, austere  
resources, and the need to minimize complexity on devices that needs  
to run for years unattended.  It is time to push forward with the more  
minimal and clearly still viable protocol without the s-bit.  Complete  
our initial work (sooner) and revisit the issue (later) with more  
complete empirical basis.

We have a (growing shorter) list of remaining outstanding questions.   
We have need come together, focus on those, AND running code.  It is  
time for that.

---

From: culler <[email-masked]>
Date: Fri, 11 Jun 2010 10:36:47 -0700

Expanding on this a little more, these "Occam Razor" analyses also  
apply to the SLLA and MTU discussions, as well.  They have put a  
number of key issues on the table.  But it is also clear that this is  
an optimization, rather than a base requirement.  And that we will be  
an a much better position to resolve choices among the specific ways  
of addressing the goals these optimizations seek to obtain.  It is  
extremely valuable to socialize such potential improvements.  But it  
also is critical to be able to defer inessential ones to get the MVP  
in place while taking care not to cut off avenues for improvement  
going forward.

On Jun 10, 2010, at 9:11 PM, culler wrote:

> Over the course of the RPL design process we have proposed a number  
> of important and interesting ideas and gone through a process of  
> potentially beneficial idea that we have worked on for a great deal  
> of time, put a lot of good work into, and yet decided to put it  
> aside when it was determined that it presented significant  
> complexity and that there was not a body of established practice in  
> LLNs to substantiate the value of the particular optimization.  And  
> that it was an optimization.
>
> complexity.  It had benefits.  It had costs.  It would be possible  
> to move forward without it, learn more through experience, and  
> prevalent usage scenarios.  As a result of the simplification, we  
> were able to make key decisions and focus our attention on other  
> important outstanding issues. RPL progress accelerated and we moved  
> closer to achieving our goal of getting a high quality solution into  
> the world on time.
>
> there are particular situations where a path might reach a point  
> where it has only one choice and that link has gone away, but it  
> could make progress if it could detour through a sibling.  We  
> understand that in these situations the other mechanisms in RPL will  
> eventually repair the problem.  We understand that sibling routes  
> amplify the potential for loops and change the repair and  
> convergence behavior.  We understand that there are numerous  
> mechanisms for addressing the problems presented by siblings.  S-bit  
> is just one of the possibilities.  We also recognize that there is  
> not a substantial body of established practice to guide choices  
> related to this optimization.  It is an important area that deserves  
> substantial further investigation.  We can move forward with the  
> simpler approach.  We can leave room to introduce the s-bit later,  
> or we might use ids to break ties.  We can produce a separate draft  
> that fully develops the approach as we learn from the body of soon  
> (hopefully) to be deployed LLNs.  It is an optimization, not a  
> fundamental requirement.  One of potential many.
>
> to run for years unattended.  It is time to push forward with the  
> more minimal and clearly still viable protocol without the s-bit.   
> Complete our initial work (sooner) and revisit the issue (later)  
> with more complete empirical basis.
>
> We have a (growing shorter) list of remaining outstanding  
> questions.  We have need come together, focus on those, AND running  
> code.  It is time for that.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 11 Jun 2010 19:49:20 +0200

Hi Dave:

I understand how your logic can apply to the SLLA. I think that the MTU
needs more discussion and a better understanding by all parties.

Have a great week end,

Pascal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> culler
> Sent: Friday, June 11, 2010 7:37 PM
> To: culler
> Cc: [email-masked]
> Subject: Re: [Roll] Bringing the S-bit discussion to a close
> 
apply to
> the SLLA and MTU discussions, as well.  They have put a number of key
issues
> on the table.  But it is also clear that this is an optimization,
rather than a base
> requirement.  And that we will be an a much better position to resolve
> choices among the specific ways of addressing the goals these
optimizations
> seek to obtain.  It is extremely valuable to socialize such potential
> improvements.  But it also is critical to be able to defer inessential
ones to get
> the MVP in place while taking care not to cut off avenues for
improvement
> > Over the course of the RPL design process we have proposed a number
of
> > potentially beneficial idea that we have worked on for a great deal
of
> > complexity.  It had benefits.  It had costs.  It would be possible
to
> > prevalent usage scenarios.  As a result of the simplification, we
were
> > there are particular situations where a path might reach a point
where
> > of established practice to guide choices related to this
optimization.
> > It is an important area that deserves substantial further
> > investigation.  We can move forward with the simpler approach.  We
can
> > leave room to introduce the s-bit later, or we might use ids to
break
> > ties.  We can produce a separate draft that fully develops the
> > approach as we learn from the body of soon
with
> > more complete empirical basis.
> >