Subject: Re: [Roll] 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

From: Phoebus Chen <[email-masked]>
Date: Fri, 08 Oct 2010 09:27:04 +0200

Forwarding my response to JP to the list.

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

-------- Original Message --------
Subject: Re: 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
Date: Fri, 8 Oct 2010 09:20:00 +0200
From: Phoebus Chen <[email-masked]>
Reply-To: <[email-masked]>
Organization: KTH, Royal Institute of Technology
To: JP Vasseur <[email-masked]>

JP,
	Thanks for addressing my concern about the A bit limiting how to
combine the metrics.  More detailed comments are inline below.

Phoebus

On 10/8/10 8:45 AM, JP Vasseur wrote:
> Hi Phoebus,
>
> Thanks for your comment. See below
>
> Begin forwarded message:
>
>> *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]>
>>
>> #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.
>
> 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.
>

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.

>
>>
>> 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."
>
> 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.

Excellent!

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

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.

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

> We will update the document accordingly and close the ticket.
>
> Thanks for your comments.
>
> JP.
>
>> 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] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/roll
>> _______________________________________________
>> Roll mailing list
>> [email-masked] <mailto:[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/>
>>
>