Subject: [Roll] [roll] #43: S bit

From: "roll issue tracker" <[email-masked]>
Date: Tue, 01 Jun 2010 20:53:01 -0000

#43: S bit
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  pal@…              
     Type:  defect              |      Status:  new                
 Priority:  major               |   Milestone:                     
Component:  rpl                 |     Version:                     
 Severity:  Active WG Document  |    Keywords:                     
--------------------------------+-------------------------------------------
 JP> 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.

 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

 JP> 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

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/43>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 11 Jun 2010 06:35:03 -0000

#43: S bit
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |        Owner:  pal@…              
     Type:  defect              |       Status:  closed             
 Priority:  major               |    Milestone:                     
Component:  rpl                 |      Version:                     
 Severity:  Active WG Document  |   Resolution:  fixed              
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by jpv@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 From David Culler:

 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.

-- 
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/43#comment:1>
roll <http://tools.ietf.org/wg/roll/>