Subject: [Roll] Is a routing constraint mutable?

From: Mukul Goyal <[email-masked]>
Date: Wed, 2 Feb 2011 05:17:52 -0600 (CST)

Hi JP

So far I had the impression that the routing constraints are not mutable. A Routing constraint specifies a constraint on the corresponding routing metric value. This means that whenever a routing constraint object is included, the corresponding routing metric object must also be included. Adrian pointed this out in his AD review of the metrics draft. I quote below the relevant text:

">> Section 3.3
>>
>> It looks to me that if the object is used as a constraint, it MUST
>> also be present as a metric. This seems to be different from the
>>burble at the top of the section. 
>
> JP> Not sure why ... you could use it as a constraint (say to avoid
> too much of delays if you know that the number of traversed hop
> may be an issue) and still want to optimize against another metric 
> such as the bandwidth ?

Well, the text says...

   The HP object may be used as a constraint or a metric.  When used as
   a constraint, the DAG root indicates the maximum number of hops that
   a path may traverse.  When that number is reached, no other node can
   join that path. 

But, if the object states how many hops are allowed (i.e. is a constraint) then
how will you know how many hops have actually been traversed? For that you need
the metric.

Actually, this would apply to the use of all metric-based constraints. E.g., if
you set a constraint that the path cost must not be greater than x, you can
include this in a constraint variant of the object, but you also need to record
the metric as you go. See my comment on Section 4.2...

"

In response, version 14 of the metrics draft included the following text in the beginning of Section 3:

"In the presence of a constraint and a metric (which may or may not be
   of the same type), a node MUST update the constraint before
   advertising the updated metric and constraints.  For example, if the
   constraint is the number of hops (e.g. the maximum number of hops is
   n) and the path is optimized against the delay: if a node selects a
   parent advertising a maximum number of hops of n (constraint), it
   must advertises DIO messages containing a hop count metrics
   constraint with a field value equal of (n-1) and the newly computed
   path metric.  This applies to the following constraints defined
   below: hop-count, latency and path ETX."

This text vaguely implies that a routing constraint is mutable or that a routing constraint involving hop-count/latency/ETX is mutable. 

First, the text quoted above conflicts with the following text from Hop-count section (3.3):

"The HP object may be used as a constraint or a metric.  When used as
   a constraint, the DAG root indicates the maximum number of hops that
   a path may traverse.  When that number is reached, no other node can
   join that path. "

The text above implies that DAG root sets the hop-count constraint value and no one should touch it.

In my view, the routing constraints should be immutable. When required, the constraint should be accompanied by a corresponding metric object. Breaking the semantic purity of the constraint (some constraint mutable; some not) is inelegant. 

This also raises questions about the meaning of the O flag inside a routing constraint. Consider a hop-count constraint with O flag set. If the meaning associated with the hop-count constraint is that it indicates the remaining number of hops that the DIO can further travel, the hop-count constraint must be updated at each hop and hence can not have O flag set.

For P2P extension, the implication is that the mutable constraints (that necessarily need to be processed at each hop) can not be considered as route constraints (only the target is required to enforce route constraints).

Please consider modifying the metrics draft to clearly specify that routing constraints are not mutable and, when required, a routing constraint object must be accompanied by a corresponding routing metric object.

Thanks
Mukul