Subject: [Roll] [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field

From: "roll issue tracker" <[email-masked]>
Date: Tue, 05 Oct 2010 14:52:59 -0000

#81: Comment received during WG Last Call of draft-ietf-roll-routing-
metrics-09.txt --- Specifying how to combine metrics in the A field
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |       Owner:  jpv@…        
     Type:  defect           |      Status:  new          
 Priority:  major            |   Milestone:               
Component:  routing-metrics  |     Version:               
 Severity:  In WG Last Call  |    Keywords:               
-----------------------------+----------------------------------------------
 email sent by Phoebus Chen on September 23 (refer to the archives for the
 full discussion)

 "I'm in the midst of making a pass through routing-metrics-09, and a
 question I (and others) asked earlier keeps coming up back in my head:

 Why are we specifying how to combine the metrics in the DAG metric
 container?  Can't it be specified in the OF?

 Here was the old thread (way back in April):
 http://www.ietf.org/mail-archive/web/roll/current/msg03815.html
 JP's response:
 http://www.ietf.org/mail-archive/web/roll/current/msg03768.html

 The argument was to not have a flood of new RFCs specifying OFs for each
 possible new way of combining metrics.  OK.

 But say that we do want to use a combination of add, max, min,
 multiplication, or some other operator to combine some of these metrics.
 What do we set in the "A" field of the Routing Metric/Constraint object
 depicted in Figure 2?  I would prefer to replace "A=0x03: The routing
 metric is multiplicative" with "A=0x03: The routing metric is aggregated
 in some other fashion specified by the objective function." Or, there
 should be a sentence in the specification saying that the objective
 function can "override" and ignore this field (and MUST set A=0x00 if the
 OF plans for the A field to be ignored).

 I noticed that the text in Section 8 of routing-metrics-08 :
 "The use of compound metrics, such as a polynomial function of individual
 metric values, will be described in a future revision of this document."
 has been removed in routing-metrics-09.  Given the rigidity of the A
 field, I'm not sure that we can specify compound metrics in future OFs.

 I'll send more comments about the rest of the document soon.

 --
 Phoebus Chen
 Postdoctoral Researcher
 Automatic Control Lab, KTH (Royal Institute of Technology)
 http://www.ee.kth.se/~phoebus

 On 9/16/10 3:56 PM, David Culler wrote:
 The routing metrics draft has now gone through 9 revisions over the
 past 16 months, the diffs have narrowed to essentially wording and
 editorial changes, and the comments are few and non-controversial.
 Thus, it appears that consensus has emerged and we can LC this I-D.

 This email is to announce Working Group Last Call on
 draft-ietf-roll-routing-metrics-09.txt to complete at 12 noon PST,
 Sept. 30 2010.  Please read it thoroughly and forward all final
 comments to the authors and the WG mailing list.

 Thanks all for your good work.  We're on a ROLL.
 _______________________________________________ Roll mailing list
 [email-masked] https://www.ietf.org/mailman/listinfo/roll
 _______________________________________________
 Roll mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/roll"

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 8 Oct 2010 08:58:09 +0200

Begin forwarded message:

> From: JP Vasseur <[email-masked]>
> Date: October 8, 2010 8:45:11 AM GMT+02:00
> To: [email-masked]
> Subject: Fwd: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field
> 
> Hi Phoebus,
> 
> Thanks for your comment. See below
> 
> Begin forwarded message:
> 
>> From: "roll issue tracker" <[email-masked]>
>> Date: October 5, 2010 4:52:59 PM GMT+02:00
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [roll] routing-metrics #81 (new): Comment received during WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying how to combine metrics in the A field
>> Reply-To: [email-masked]
>> 
> Indeed. The OF and metrics are decoupled as specified in the text (and agreed
> on the list some time ago)
> 
> "   The specification of objective functions used to compute the DAG
>    built by RPL is out of the scope of this document and will be
>    specified in other documents.  Routing metrics and constraints are
>    decoupled from the objective function.  So a generic objective
>    function could for example specify the rules to select the best
>    parents in the DAG, the number of backup parents, etc.  Such
>    objective function can be used with any routing metrics and/or
>    contraints such as the ones specified in this document.
> "
> 
> That being said, this should clarified in the document. 
> How about rewording this sentence: 
> 
> OLD:
> 
>    Routing metrics and constraints are carried within the DAG Metric
>    Container object defined in [I-D.ietf-roll-rpl].
> 
> NEW:
> 
>    Routing metrics and constraints are carried within the DAG Metric
>    Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics 
>    and/or constraints be present in the DAG Metric Container, their use
>    to determine the "best" path can be defined by the Objective Function.
> 
> 
>> 
>> in some other fashion specified by the objective function."
> 
> You are right that all values for the A field being taken, there is no way to further
> define different ways to compute aggregated metrics. We will thus extend the A
> field to 3 bits. Further document could then define a new value for A specifying 
> another way to compute the metric or may indicate the presence of a TLV should
> the formula to compute the metric be too complex to be summarized with one bit.
> 
> The exact same thing could be done for the path cost computation, for example
> should you want to use a counpound metric: add a TLV in the DAG metric 
> container specifying how multiple metrics should be "combined" to update the 
> path cost.
> 
> We will update the document accordingly and close the ticket.
> 
> Thanks for your comments.
> 
> JP.
> 
>> Or, there

---

From: JP Vasseur <[email-masked]>
Date: Fri, 8 Oct 2010 09:02:18 +0200

Resending with the correct text this time.

NEW:

Routing metrics and constraints are carried within the DAG Metric
Container object defined in [I-D.ietf-roll-rpl]. Should multiple metrics 
and/or constraints be present in the DAG Metric Container, their use
to determine the "best" path can be defined by an Objective Function
or a new TLV to be defined in future documents.

> https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Fri, 8 Oct 2010 14:07:42 +0200

Hi,

On Oct 8, 2010, at 9:20 AM, Phoebus Chen wrote:

> JP,
> 	Thanks for addressing my concern about the A bit limiting how to combine the metrics.  

Sure

> More detailed comments are inline below.
> 
> Phoebus
> 
> On 10/8/10 8:45 AM, JP Vasseur wrote:
>> Hi Phoebus,
>> 
>>> *From: *"roll issue tracker" <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Date: *October 5, 2010 4:52:59 PM GMT+02:00
>>> *To: [email-masked] <mailto:[email-masked]>
>>> *Cc: [email-masked] <mailto:[email-masked]>
>>> *Subject: **[roll] routing-metrics #81 (new): Comment received during
>>> WG Last Call of draft-ietf-roll-routing-metrics-09.txt --- Specifying
>>> how to combine metrics in the A field*
>>> *Reply-To: [email-masked] <mailto:[email-masked]>
>>> 
> It's OK if the reader does not take the new sentence too literally, to mean that *only* when multiple metrics and/or constraints are present does the OF play a role in selecting the best path.
> 
> You point this out in example 1 on page 9, for paths that avoid low quality links.  There, the metrics were aggregated with the max() function, and then the objective function could select the path with the minimum aggregated metric.

Correct.

>> field to 3 bits.
> Excellent!
> Further document could then define a new value for A

Right

>> specifying
> I think I mentioned this in a follow up email, after Joakim responded to this thread, but it might save overhead to specify how to combine the metrics for an objective function in DODAG Configuration Objects, and not DAG metric containers.  I don't think the methods for combining the metrics would change that often for a given objective function (maybe changes only when the network operator reconfigures the network).   You don't need to advertise it with every DIO that contains the metrics, which might change more frequently.

That TLV specifying how to combine the metrics could potentially be somewhere else indeed, agree (to be defined by further document).

> 
> I'm asking for more work here defining a new container in a DODAG Configuration Object... if this is too much work for last call to add such a feature, what you propose above may be good enough.  

Yes this seems to deserve a separate document indeed, if OK with you.

Thanks again for the comments (we also owe you some answers about the Edits - to be done soon).

So I'll close that ticket.

JP.

> It would just waste some bandwidth / overhead.  Implementations will tell whether this waste is actually a problem and needs to be fixed in a future update / version of RPL.
> 
>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 08 Oct 2010 12:25:54 -0000

> I'll send more comments about the rest of the document soon.

New description:

--

Comment(by jpv@…):

 The document has been updated in the following fashion:

 Reply for JP
 #########

 Indeed. The OF and metrics are decoupled as specified in the text (and
 agreed
 on the list some time ago)

 OLD:

 NEW:

 other comment

 Reply:
 You are right that all values for the A field being taken, there is no way
 to further
 define different ways to compute aggregated metrics. We will thus extend
 the A
 field to 3 bits. Further document could then define a new value for A
 specifying
 another way to compute the metric or may indicate the presence of a TLV
 should
 the formula to compute the metric be too complex to be summarized with one
 bit.

 The exact same thing could be done for the path cost computation, for
 example
 should you want to use a counpound metric: add a TLV in the DAG metric
 container specifying how multiple metrics should be "combined" to update
 the
 path cost.

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

---

From: JP Vasseur <[email-masked]>
Date: Fri, 8 Oct 2010 15:07:07 +0200

Thanks.
JP.

On Oct 8, 2010, at 2:29 PM, Phoebus Chen wrote:

> JP,
> 
> <snipped from long message>
> Yes, it's OK with me.

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 08 Oct 2010 13:07:42 -0000

Changes (by jpv@…):

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

New description:

--

-- 
-----------------------------+----------------------------------------------
 Reporter:  jpv@…            |        Owner:  jpv@…        
     Type:  defect           |       Status:  closed       
 Priority:  major            |    Milestone:               
Component:  routing-metrics  |      Version:               
 Severity:  In WG Last Call  |   Resolution:  fixed        
 Keywords:                   |  
-----------------------------+----------------------------------------------
Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/81#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 08 Oct 2010 14:56:05 -0000

Comment(by jpv@…):

 Replying to [comment:1 jpv@…]:

 Reply for JP should read Reply FROM JP

 agreed
 the A
 specifying
 should
 example
 the

Ticket URL: <https://svn.tools.ietf.org/wg/roll/trac/ticket/81#comment:3>