[Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-11.txt

[Omprakash Gnawali <[e-mail]>]

Here are the changes made to this draft to address all the DISCUSS
items. COMMENTs were also addressed but not listed here. Here is a
link to -11:
http://tools.ietf.org/html/draft-ietf-roll-minrank-hysteresis-of-11

And here is a link to the diff between -10 and -11:
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-roll-minrank-hysteresis-of-11.txt

How the DISCUSS items were addressed ---


Brian Haberman:

1. Discuss - In sections 3.1 and 3.2.1, the draft says that messages
can be delayed but should not be delayed too much?  How much is too
much?  Is it dependent on the metric being used?  Are there guidelines
that should be provided?  If different implementations try to
interact, will their selection of delay values hinder
performance/stability of the RPL-based network?

Fixed. It now gives an example of reasonable delay: Trickle minimum
interval (6550) and says longer delays will lead to stale information,
suboptimal paths.


------


2. Discuss - Section 5 says, "The best values for these parameters
should be experimentally determined."  Is this guidance to
implementers to figure out what values to support in their
implementation or advice to operators to test a range of values for
their particular deployment?  As a standards-track document, this type
of nebulous statement concerns me from a variety of perspectives.


Fixed as:

The best values for these parameters are determined by
        the requirement of the specific RPL deployment. For instance,
        if we use ETX as the selected metric and UDP as the transport
        protocol, we should use a small MAX_LINK_METRIC (e.g., ETX of
        1.1) so that link layer retransmissions are sufficient to
        provide a good chance of end-to-end reliability.


------

3. Discuss - Section 8 asks IANA to allocate a code point, but where
in the draft is that code point used? Is it used as a part of the
transmission logic in section 3.4?

This is a RPL parameter (not used in MRHOF) as suggested in the text:

      <t>This specification requires a value allocated from the
      "Objective Code Point (OCP)" sub-registry of the "Routing
      Protocol for Low Power and Lossy Networks (RPL)" registry. A
      value of 1 is suggested.</t>


------

Comment - acronyms should be referenced/expanded in first use. Fixed.


-----


Martin Steimerling

Discuss 1: Is there any recommendation or further reading on what the
  time is to be used to perform the periodically updates?
  Re-computing state periodically might be a good thing, but I would
  expect that a Standards Track document is much more specific on
  this.


Fixed. ..

Discuss 2: How much is the 'later time'?  I would expect that a
  Standards Track document is much more specific on this, other than
  do whatever you think is appropriate.

Fixed. ...


Discuss 3: Is there any reference on how the WG came to the below
  numbers? This would be good for people trying to follow this up in
  the future. They might need to know how to came to these numbers.

Here are the recommended numbers with proper ETX representation -

  MAX_LINK_METRIC: 512.
  MAX_PATH_COST: 32768.
  PARENT_SWITCH_THRESHOLD: 192.
  PARENT_SET_SIZE: 3.
  ALLOW_FLOATING_ROOT: 0.

and the draft now cites:

IP is Dead, Long Live IP for Wireless Sensor Networks
Jonathan W. Hui and David E. Culler
Proceedings of the 6th International Conference on Embedded Networked
Sensor Systems


----


Discuss 1-4:


1.  Why is one objective function defined for several potential
metrics?  The details of MRHOF seem to preclude the establishment of
several RPL instances in an LLN, each of which uses MRHOF with a
different selected metric.

2. How are the nodes in the RPL instance informed about the selected
metric?  My understanding of RPL is that only the objective function
is included in the DIO received as an advertisement for a particular
RPL instance, which means a node can't know the selected metric for
that RPL instance and can't meaningfully decide among multiple RPL
instances all using MRHOF as the objective function.

As a followup to (1), if there were a way to encode the selected
metric for a RPL instance in the DAO, a node would be able to select
which RPL instance to use for a particular type of traffic.

3. Based on (1) and (2), would configuration and selection issues be
ameliorated if the five candidate selected metrics were each asssigned
a separate objective function?  Use of a separate OF code point for
each of the five possible selected metrics would allow multiple RPL
instances.

4. Related to the above, I don't see anything in section 6 about
managing the selected metric.  Don't all of the nodes that join a RPL
instance using MRHOF have to be configured to use the same selected
metric?



Fixed with this definition in the terminology section:


          <t hangText="Selected metric:">The metric chosen by the
          network operator to use for path selection. MRHOF supports
          using a single metric for path selection. The decision to
          use a metric (other than ETX) as the selected metric is
          indicated by the presence of the chosen metric in the DIO
          metric container. The selection of the ETX metric is
          indicated by the absence of the metric container.</t>

----

Discuss 5 - In section 3.2.2:

   a node MAY use a different objective function to select which of these
   neighbors should be considered to have the lowest cost.

seems to contradict the statement in the Introduction that "all nodes
in a network use a common OF."  Should "different objective function"
be replaced with "some other selection criteria?"


Fixed:


        <t>If there are multiple neighbors which share the smallest
          path cost, a node MAY use a different selection criteria to
          select which of these neighbors should be considered to have
          the lowest cost.</t>


----


Discuss 6 - In section 5, are the RECOMMENDED values appropriate for all
selected metrics or just for ETX?  Are there any references that might
be cited that would give background on the working group experience
with ETX and the development of the recommended values?


Fixed. See above.


----

7. In section 6.1, why not "MUST support the DODAG Configuration
option?"  I don't see any RFC 2119 requirements on the implementation
of the DODAG Configuration option (which would appera to be an
oversight), but I don't understand how a node can operate in a RPL
instance without, for example, being able to determine the Objective
Function used by that instance.


Fixed:

<t>A MRHOF implementation MUST support the DODAG Configuration
option as described in <xref target="RFC6550"/> and apply the parameters it
specifies. Care should be taken in the relationship between the MRHOF
...


- om_p


---------- Forwarded message ----------
From:  <[e-mail]>
Date: Fri, Jun 29, 2012 at 11:12 PM
Subject: New Version Notification for
draft-ietf-roll-minrank-hysteresis-of-11.txt
To: [e-mail]
Cc: [e-mail]



A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-11.txt
has been successfully submitted by Omprakash Gnawali and posted to the
IETF repository.

Filename:        draft-ietf-roll-minrank-hysteresis-of
Revision:        11
Title:           The Minimum Rank with Hysteresis Objective Function
Creation date:   2012-06-29
WG ID:           roll
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-11.txt
Status:
http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of
Htmlized:
http://tools.ietf.org/html/draft-ietf-roll-minrank-hysteresis-of-11
Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-minrank-hysteresis-of-11

Abstract:
  The Routing Protocol for Low Power and Lossy Networks (RPL) uses
  objective functions to construct routes that optimize or constrain
  the routes it selects and uses.  This specification describes the
  Minimum Rank with Hysteresis Objective Function (MRHOF), an objective
  function that selects routes that minimize a metric, while using
  hysteresis to reduce churn in response to small metric changes.
  MRHOF works with metrics that are additive along a route, and the
  metric it uses is determined by the metrics RPL Destination
  Information Object (DIO) messages advertise.




The IETF Secretariat