Subject: [manet] Comments on Metric TLV

From: "Teco_Boot" <[email-masked]>
Date: Tue, 14 Aug 2007 12:11:54 +0200

Hi,

I studied the proposals for a metric TLV representation.
Here some comments:

1)
I don't like fractional values. Elimination circumvents rounding or
truncating. So I prefer (16 + a) * 2^b over (1 + a/16) * 2^b.
It also extents the number of distinct values, from 207 to 256.

2)
I prefer enlarging the range between lowest and highest value. A simple
method is to subtract 15: (16 + a) * 2^b - 15.
Lowest value is 1, followed by 2, 3, ...  950.272, 983.040, 1.015.808.
Linear from 1 to 17, hereafter the exponential characteristic starts.
I my day-to-day work I deal with extremely low-speed radio links and
high-speed wired links; think of a data radio with shared 1kbps over the
radio interface and 1Gbps over the cable interface. Others could come up
with more extreme ends of the spectrum.
I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49, ...
15.204.097, 15.728.385, 16.252.673. Although the range is enlarged with
factor 16, I think it doesn't bring that much value.

3)
I see no reason for having a compact linear metric representation. 
I suggest using an uncompressed 24-bit link metric. And use a 32-bit path
metric in all cases.
The 24-bit link metric could be assigned a TLV type or subtype. This
enlarges the metric range to 1 - 16.777.216 without loss of resolution.
Using this TLV can be made fully compatible with the compressed exponential
metric; both may be used in the same MANET region.
Linear metric representations could be needed by distance vector mechanisms,
as path metric is computed hop by hop and loosing resolution could introduce
bad behavior. See comment#8 related to DYMO below.

4)
I prefer defining a Do_Not_Use metric value, to be specified as the binary
all_ones value: 255 for the single octet exponential TLV, 16.777.216 for a
24-bit linear TLV. Advertising such a value is useful for some scenarios,
e.g. graceful shutdown of interface or router.

5)
I do not see a reason for having a node metric (dean-manet-metriclv). A node
is free to add whatever offset on metrics for its links. The result of the
SPF path selection is equivalent.

6)
I like the idea having metrics for a link generated by both the transmitter
and the receiver on a link. This result in three cases for path metric
calculation: 
- no link metric
- one metric only, generated by transmitter (outbound) or receiver (inbound)
- two metrics, generated by both transmitter and receiver
First case: use a default metric; second case: use the metric that is
available and the third case: use the average, that is add the metrics and
divide by two, truncate to get an integer.
Metrics shall be direction sensitive. A link A <--> B may have four metrics,
A inbound, A outbound, B inbound and B outbound. Metrics for opposite
directions may not be used for path metric calculation, e.g. default metric
is to be used for A -> B when only A inbound and B outbound metrics are
available.
Effects caused by unsynchronized path computations are to be verified.

7)
When using a factor 16 as proposed above, the suggested default value 4096
(dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used. Note
that in my "-15" suggestion, this default value cannot be stored in a
compressed exponential value. If default-value explicit signaling is
preferred, a default value of 65.521 is to be used.

8)
In DYMO, a path metric is used, it is called distance. Behavior is similar
to distance vector. The distance field is one octet. Intermediate routers
increment distance, minimum increment is 1. Adding a higher cost value is
fully acceptable.
Personally, I prefer a uniform link metric / uniform path metric in MANET
and even to be used in other IETF protocols. 
- Enlarge the distance to 32-bit field? 
- Accept some kind of mixed mode? 
For the latter, the required incremented-by-1 update could get lost by the
compress mechanism. This is circumvented by incrementing the compressed
metric, by 1 or by setting to outbound link metric when link metric value is
higher than the to-be-forwarded distance. 
In short: we could use two distance formats, a short 8-bit path metric and a
large 32-bit path metric. Conversion is allowed, but special attention is
required for incrementing the distance hop-by-hop. 

9)
In PacketBB, hop based fields are used:
MsgHdr.HopLimit - noHopLimit bit
MsgHdr.HopCount - noHopCount bit
We could discuss allowing high decrements (HopLimit) and high increments
(HopCount) during forwarding the messages. Rules for decrementing and
incrementing are to be determined.
DYMO uses HopLimit.

During analysis I used the following formulas:
Lin_Metric = (16+MOD(Exp_Metric;16))*2^INT(Exp_Metric/16) - 15
Exp_Metric = 16*FLOOR(LOG((Lin_Metric+15)/16;2);1) + 
      INT(16*(((Lin_Metric+15)/16)/2^FLOOR(LOG((Lin_Metric+15)/16;2);1)-1))

Teco

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 14 Aug 2007 11:39:00 +0100

Comments >>> inline 

-----Original Message-----
From: Teco_Boot [mailto:[email-masked]] 
Sent: 14 August 2007 11:12
To: [email-masked]; Dearlove, Christopher (UK); 'Thomas
Clausen'; [email-masked]
Cc: [email-masked]
Subject: Comments on Metric TLV

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Hi,

1)

>>> Having less tham 256 values is only because you've chosen to
>>> use the fractional representation but prohibit fractions.
>>> That I don't think is sensible, so it's 256 either way. The
>>> scaling is also actually irrelevant, it's just an implementation
>>> detail that has no actual consequences (you send the same octets,
>>> and get the same results).

2)

>>> Interesting, but it messes up later values as the 15 is only
>>> right in the first octave. So I don't like this at all.

I evaluated using (16 + a) * 2^(b+4) - 255. Values are 1, 17, 33, 49,
...

3)

>>> I agree with you here. Note that it's not in the proposal I
>>> presented.

I suggest using an uncompressed 24-bit link metric.

>>> But not here. I think there's no need for anything but the 4/4
>>> bit value.

And use a 32-bit path metric in all cases.
The 24-bit link metric could be assigned a TLV type or subtype. This
enlarges the metric range to 1 - 16.777.216 without loss of resolution.
Using this TLV can be made fully compatible with the compressed
exponential
metric; both may be used in the same MANET region.
Linear metric representations could be needed by distance vector
mechanisms,
as path metric is computed hop by hop and loosing resolution could
introduce
bad behavior. See comment#8 related to DYMO below.

4)
I prefer defining a Do_Not_Use metric value, to be specified as the
binary
all_ones value: 255 for the single octet exponential TLV, 16.777.216 for
a
24-bit linear TLV. Advertising such a value is useful for some
scenarios,
e.g. graceful shutdown of interface or router.

>>> We don't need this in OLSRv2 - we have the concept of a LOST link.

5)
I do not see a reason for having a node metric (dean-manet-metriclv). A
node
is free to add whatever offset on metrics for its links. The result of
the
SPF path selection is equivalent.

>>> Also agreed.

6)
I like the idea having metrics for a link generated by both the
transmitter
and the receiver on a link. This result in three cases for path metric
calculation: 
- no link metric
- one metric only, generated by transmitter (outbound) or receiver
(inbound)
- two metrics, generated by both transmitter and receiver
First case: use a default metric; second case: use the metric that is
available and the third case: use the average, that is add the metrics
and
divide by two, truncate to get an integer.

>>> I don't like this case, it defeats the whole motivation of
>>> bidirectional metrics - that there is no ambiguity. With
>>> lossy messages there is ambiguity using two node's values
>>> (in an average or whatever).

Metrics shall be direction sensitive. A link A <--> B may have four
metrics,
A inbound, A outbound, B inbound and B outbound.

>>> I don't see the point of this.

Metrics for opposite
directions may not be used for path metric calculation, e.g. default
metric
is to be used for A -> B when only A inbound and B outbound metrics are
available.
Effects caused by unsynchronized path computations are to be verified.

7)
When using a factor 16 as proposed above, the suggested default value
4096
(dearlove-olsrv2-metrics) is fairly low. A value 6.5536 is to be used.
Note
that in my "-15" suggestion, this default value cannot be stored in a
compressed exponential value. If default-value explicit signaling is
preferred, a default value of 65.521 is to be used.

>>> OK, took me a second to realise . is what I'd write as comma, except
>>> I wouldn't. But I don't agree with the revision, 4096 is in the
centre
>>> of the range logarithmically, and I think that is right. (I also
think
>>> this is another argument against -15.)

8)
In DYMO, a path metric is used, it is called distance. Behavior is
similar
to distance vector. The distance field is one octet. Intermediate
routers
increment distance, minimum increment is 1. Adding a higher cost value
is
fully acceptable.
Personally, I prefer a uniform link metric / uniform path metric in
MANET
and even to be used in other IETF protocols. 
- Enlarge the distance to 32-bit field? 

>>> While I've been on the other end of efficiency arguments, I really
>>> don't want to use more than one octet for a metric, and certainly
>>> not four. I want to just use a single, exponent/mantissa, octet.
>>> (Note that I'm not committed to the 4/4 bit split - in fact in the
>>> motivating timetlv we're about to change to 5/3. I think 4/4 is
>>> better here, but an argument for 5/3 or 3/5 could be made I'm sure.)
>>> Of course I'm not considering DYMO directly.

- Accept some kind of mixed mode? 
For the latter, the required incremented-by-1 update could get lost by
the
compress mechanism. This is circumvented by incrementing the compressed
metric, by 1 or by setting to outbound link metric when link metric
value is
higher than the to-be-forwarded distance. 
In short: we could use two distance formats, a short 8-bit path metric
and a
large 32-bit path metric. Conversion is allowed, but special attention
is
required for incrementing the distance hop-by-hop. 

9)

>>> I think these are definitely intended to be hops, not metrics,
>>> and definitely should remain so.

Teco

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Teco_Boot" <[email-masked]>
Date: Tue, 14 Aug 2007 14:21:38 +0200

Hi Chris, 
Thanks for your quick response!
Comments inline.
Teco.

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: dinsdag 14 augustus 2007 12:39
> To: Teco_Boot; [email-masked]; Thomas Clausen;
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on Metric TLV
> 
> 
> Comments >>> inline
> 
[Teco] 
Agreed it is mainly representation. But still I like using integers. For
example, the "-15" would be "-0,9375".

Sorry for using "decimal point is comma". I am just using the official ISO
standards. And I am Dutch, so it is not that difficult for me:-)
Another argument on not using fractions. Fractions introduce friction.

> >>> right in the first octave. So I don't like this at all.
[Teco] 
The "-15" should be used in all cases. I think it is a minor adjustment and
it provides an important increase in the range.

> >>> But not here. I think there's no need for anything but the 4/4
[Teco] 
I like compressed metric very much. But forecasting linear metrics are not
needed by anyone, also in the future, is precarious. I think it could be
used as an escape.

> >>> (in an average or whatever).
[Teco] 
With the specified rules, there is no ambiguity. During converging, some
information could be missing on some nodes. This could introduce problems.
But routing loops during converging is a problem with link state protocols
in the first place. I think smooth metric updates circumvent micro loops in
some cases. So it could be a trade off.
Both transmitter and receiver could have a policy or lower layer indication
for the metric. I don't like signaling between those for injecting the link
metric at a single point.
My proposal provides full functionality, at low cost. Only the asymmetric
links need the enhancement, and whenever these metrics are available, on
both the transmitter and the receiver, why not using them?
FYI: inputs for outbound metric: #retransmits, load, transmit power,
battery, pricing, policy, etc.

> >>> I don't see the point of this.
[Teco] 
Node A would be able set the inbound and outbound metric fully independent
of what node B is doing.
The question is not having a valid requirement, but how to support this
without high overhead and without any overhead if some implementation does
not use this function.

> >>> this is another argument against -15.)
[Teco] 
If we keep using the (1 + a/16) * 2^b, default value 4096 is OK.
If we scale up with factor 16, the default should scale up also.
It has nothing to do with the -15.

> >>> Of course I'm not considering DYMO directly.
[Teco] 
I never suggested skipping compressed metrics.
Again, we do not know what is needed in the future.

> >>> and definitely should remain so.
[Teco] 
History repeats itself. RIP metric was intended to be hopcount. But real
world needed more and tricks using offsets are used frequently. Same for BGP
AS-list.
In the environment I am working in, some high-speed links can handle
whatever signaling load; other links are extremely constrained. The question
is how to implement some kind of filtering, based on this requirement. Using
the HopLimit is a method. Do you reject such a usage? If so, why? If not,
why not writing down it is allowed?

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 14 Aug 2007 13:39:29 +0100

Comments >>>>> inline below. (I'm not going to repeat comments,
in several cases I've made my point, we don't entirely
agree.) 

-----Original Message-----
From: Teco_Boot [mailto:[email-masked]] 
Sent: 14 August 2007 13:22
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; 'Thomas Clausen';

Hi Chris, 

[Teco] 

Sorry for using "decimal point is comma". I am just using the official
ISO
standards. And I am Dutch, so it is not that difficult for me:-)
Another argument on not using fractions. Fractions introduce friction.

> >>> right in the first octave. So I don't like this at all.
[Teco] 
The "-15" should be used in all cases. I think it is a minor adjustment
and
it provides an important increase in the range.

> >>> But not here. I think there's no need for anything but the 4/4
[Teco] 
I like compressed metric very much. But forecasting linear metrics are
not
needed by anyone, also in the future, is precarious. I think it could be
used as an escape.

[Teco] 
With the specified rules, there is no ambiguity. During converging, some
information could be missing on some nodes. This could introduce
problems.
But routing loops during converging is a problem with link state
protocols
in the first place. I think smooth metric updates circumvent micro loops
in
some cases. So it could be a trade off.
Both transmitter and receiver could have a policy or lower layer
indication
for the metric. I don't like signaling between those for injecting the
link
metric at a single point.
My proposal provides full functionality, at low cost. Only the
asymmetric
links need the enhancement, and whenever these metrics are available, on
both the transmitter and the receiver, why not using them?
FYI: inputs for outbound metric: #retransmits, load, transmit power,
battery, pricing, policy, etc.

> >>> I don't see the point of this.
[Teco] 
Node A would be able set the inbound and outbound metric fully
independent
of what node B is doing.
The question is not having a valid requirement, but how to support this
without high overhead and without any overhead if some implementation
does
not use this function.

[Teco] 

>>>>> No, the 4096 is with the x16. Without it it's 256. In the
>>>>> centre of the range - logarithmically.

[Teco] 

>>>>> There's an issue that unless you are prepared to put a major
>>>>> delay in, and I emphatically am not, there are constraints on
>>>>> what's sensible to do right now. See presentation at IETF.

[Teco] 
History repeats itself. RIP metric was intended to be hopcount. But real
world needed more and tricks using offsets are used frequently. Same for
BGP
AS-list.

>>>>> But sometimes it's the other way. IP TTL was meant to be time,
>>>>> with a minimum value, but became hops (hop limit in IPv6).

In the environment I am working in, some high-speed links can handle
whatever signaling load; other links are extremely constrained. The
question
is how to implement some kind of filtering, based on this requirement.
Using
the HopLimit is a method. Do you reject such a usage? If so, why? If
not,
why not writing down it is allowed?

>>>>> I was just indicating that I think that the hop count/limit
>>>>> in the packetbb header are intended to be, and I believe
>>>>> should remain, hops. But that doesn't stop you from using
>>>>> other things in other places.

---

From: Bo Berry <[email-masked]>
Date: Tue, 14 Aug 2007 12:23:10 -0400

Comments in-line.
-Bo

>> factor 16, I think it doesn't bring that much value.

I suggest that the metrics/cost design not be based upon low
speed (kbps) radio links.   The metrics/cost should also handle
high speed (gbps) radio links. The design should also be
capable of distinguishing the difference in the two extremes
of radio links when comparing link costs and route selections.
Perhaps we should define the cost value as a full 16-bit
unsigned range (or 32-bit) so all cost factors
can be fairly compared. If this is done then the constraints
on the equations can be relaxed.   For example, using one type
of radio may require a different set of equations than the
ones listed here.  With the standard cost range the computed
costs can be fairly compared to other costs. I don't think we
want to corner the radios into these equations.

>>>>> We don't need this in OLSRv2 - we have the concept of a LOST link.

If the node is to send a Do_Not_use metric, it is better that the
metric not be sent.

>> SPF path selection is equivalent.

If the node is battery powered, it may be useful to send
an indication that its battery is running low and traffic
should be routed around this node if possible.  This indication
would be applied to all links (radio and wired) on the
reporting node.

> battery, pricing, policy, etc.

If we define a lengthy set of metrics how would

> without high overhead and without any overhead if some implementation

This capability is dependent upon the radio.  Some
may be able to provide such metrics and others not.
We need to be sure to allow for this.

> world needed more and tricks using offsets are used frequently. Same for

I think we should clarify the meaning of metric vs cost. As written
I find the use of the terms some what confusing.  Once we clarify
the use of these two terms a lot of the discussion above becomes
easier.  I see a uniform cost being computed from the metric.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 15 Aug 2007 09:45:17 +0200

Comments inline.
Some text removed to reduce size.
Thanks, Teco

> want to corner the radios into these equations.
[Teco] 
Dimensionless metrics/cost was implicitly assumed.
My example provides a real world requirement, discussing the need for a 10^6
range or more. Linear 16-bits (like OSPF) are not sufficient here. 24-bit
linear fits much better.
I suggest using the mechanism defined by IS-IS extensions for Traffic
Engineering (RFC3784). Path calculation is performed with 32-bit unsigned
integers. This provides support for 255 hops with 24-bit link costs.
Also interesting concept in RFC3784: TLV for a default metric.

> If the node is to send a Do_Not_use metric, it is better that the
[Teco] 
Not sending a metric leads to using the default metric.
RFC3784 also defines the Do_Not_Use metric. Why not adopt OSPF and ISIS
behavior in OLSR? 

> would be applied to all links (radio and wired) on the
[Teco] 
Why not adding a large value on the metric? SPF path selection will use an
alternative path, if available. Using metrics is much more smoothly than a
battery-low bit.

> If we define a lengthy set of metrics how would
[Teco] 
(response on fragment of a comment)
The inputs are for generating a dimensionless metric value. Inputs shall not
be signaled to other routers.

> We need to be sure to allow for this.
[Teco] 
The requirement is supporting radios that provide the information. I think
cross-layering will be evolving in coming years. Let's prepare for this.

> easier.  I see a uniform cost being computed from the metric.
[Teco] 
I think the context was clear; we discuss uniform costs or metrics (without
a dimension).
ISIS uses term metric; costs have to do with money.
OSPF uses term cost and metric, "The cost of a route is described by a
single dimensionless metric."

The term metrics could also be used for certain link characteristics (with
or without a dimension), like you did in PPPoE with Credit Flow and Metrics
(RFC4938). You are right the terms are somewhat confusing.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:26:39 +0100

> speed (kbps) radio links.

I don't see the relevance of this comment at all. Where is there
any suggestion that the design is so based?

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 09:41:44 +0100

> integers.

While I have been accused of ignoring packet size issues,
it's only when I think there's a real reason for it. But
here I don't see the need for 4 octets. This suggests
metrics can be measured to a fantastic degree of precision
for a wireless network.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 15 Aug 2007 10:43:57 +0200

Some more comments on metric encoding.
Teco.

> > >>> better here, but an argument for 5/3 or 3/5 could be made I'm
I checked 5/3 and 3/5.
Using 5/3, metric value 172 already overflows a 24-bit field. Value 236
overflows a 32-bit field. It requires 48-bit integers for path calculation.
3/5 provides a very limited range, 32 - 8064.

On using (16+a)*2^b, (1+a/16)*2^b or (16+a)*2^b-15: I prefer encoding that
supports real world use cases and real world examples. 
Examples in dearlove-olsrv2-metric use link metrics 1, 2, 3 and 4. Only
(1+a/16)*2^b and (16+a)*2^b-15 support these values. 
Real world use cases are discussed on ML, there is a need for support for a
broad range of links. IMHO a 10^6 range is needed, I ever prefer more.
(16+a)*2^(b+4)-255 provides the broadest range, 1 to 16.252.673, but it does
not support the real world examples.

When looking at all options, I think (16+a)*2^b-15 is absolutely a
candidate. Maybe not 100% exponential, but it fits real world needs much
better than (16+a)*2^b. Can you argument against -15?

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 15 Aug 2007 11:05:48 +0200

I did absolutely not intend sending the 32-bits here, I used wording "path
calculation".

I suggested a 24-bits linear metric TLV, for those who can live with the
increased packet sizes and need the "fantastic degree of precision". Don't
forget it also extents the range to 1 - 16777215. 
Usage of this TLV would be optional, the compressed exponential metric would
be used were packet size is an issue.

What is the point?
Teco

> Sent: woensdag 15 augustus 2007 10:42
> To: Teco Boot; Bo Berry
> Cc: [email-masked]; [email-masked]; Thomas Clausen
> Subject: RE: [manet] RE: Comments on Metric TLV
> 
>

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 10:08:46 +0100

> What is the point?

Of what?

I think you are saying that you suggest a 24 bit "flat"
representation as an option, while I'm saying that I
think this is unnecessary as the precision is not going
to be real, and there's quite enough complexity without
adding stuff we don't need.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 10:16:11 +0100

Actually to follow myself up, the details of how
exactly metric values are encoded is a detail.
Unless we actually go ahead and use them, all the
discussion of those details is wasted time, and
I'll stop doing so now.
 
Can I urge that discussion focus on whether this
(using metrics, not defining a metric TLV) is what
we should do, or not.

-----Original Message-----
From: Dearlove, Christopher (UK) 
Sent: 15 August 2007 10:09
To: Teco Boot
Cc: [email-masked]
Subject: RE: [manet] RE: Comments on Metric TLV

               *** WARNING ***

Of what?

---

From: Bo Berry <[email-masked]>
Date: Wed, 15 Aug 2007 08:52:54 -0400

in-line
-B

> Some text removed to reduce size.
...cut...
> RFC3784 also defines the Do_Not_Use metric. Why not adopt OSPF and ISIS

If we support not sending a metric as you noted, then why is
a DNU value needed?  Do you envision the receiver taking different
actions?

> alternative path, if available. Using metrics is much more smoothly than a

But how large of a metric should the node report?  In the case of
battery life, I think it would be useful to very the metric as
battery life decreases from 100% to 0%?  A percentage would also
support the battery recharge (100%).

 ...cut...
> (RFC4938). You are right the terms are somewhat confusing.

I think of cost as a uniform value used in route selection.  I think
of metric, radio or otherwise, as a value used to compute a cost value
that is used to update the associated route.  Metrics exist in a variety
of formats and ranges.  Metrics have various scopes.  A metric
may be tied to a specific link and another metric may be nodal which
applies to all links on that node. For example, battery life would be
nodal, represented as 0-100%, effecting all links.  Data rates are
link oriented and may be expressed in kbps, mbps, gbps, etc.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 13:58:58 +0100

> support the battery recharge (100%).

Please read draft-dearlove-olsrv2-metrics-00. We're not talking
about real world measurements like battery life, we're talking
about dimensionless metrics used for route selection. In your
terminology a cost value (but use of metric in this sense is
also common).

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 15 Aug 2007 15:45:48 +0200

> a DNU value needed?  Do you envision the receiver taking different
[Teco] 
DNU and Default are very, very different.
Not sending a metric and using a default reduces packet size.
Sending DNU could be used in some cases to signal the link is
out-of-service, for whatever reason. 
Protocols could have another mechanism to signal this condition; Chris noted
NHDP has the L_lost status for links. I'll have to check how this condition
is signaled in the MANET. I checked ietf-manet-olsrv2-04, but I can't find
it.

> support the battery recharge (100%).
[Teco] 
Specifying an algorithm for dimensionless metric generation is not needed.
Guidelines are fine, for the metric value itself and for dampening and
hysteresis.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 15:56:58 +0100

> Chris noted

It's in draft-ietf-manet-nhdp-04 (or whatever we are up to). It's really
L_status == LOST, of which L_lost == true is one case.

---

From: Philip Levis <[email-masked]>
Date: Wed, 15 Aug 2007 08:54:07 -0700

> any suggestion that the design is so based?

For the record, sensor network routing protocols, which use low speed  
radio links, typically have either 8-bit (e.g., Route, MintRoute)  or  
16-bit (e.g., MultihopLQI/MLQI, CTP) cost values. Note that these  
protocols typically assume a single link layer, and the cost metric  
is expected transmissions (ETX) or some variant thereof (e.g., MLQI  
is a transformation of soft chip decision values). In the case of CTP 
[1], the 16 bits are a fixed point number with 0.01 precision,  
thereby allowing ETX values in the range of 0-655.35. We thought 8  
bits insufficient because there are existing low-power mesh  
deployments that are 48 hops long[2], and with 8 bits this would  
greatly limit the metric precision.

That being said -- and with respect to the metrics draft -- I'm wary  
of exponential metrics, or, indeed, any variable-precision metric.  
For example, let's say the metric encodes ETT (expected time of  
transmission) and you have a gigabit mesh with a kilobit uplink  
(e.g., a disaster response network designed primarily for local  
communication but also has a channel to the outside world). The ETT  
of the kilobit uplink is going to overwhelm the ETT within the  
gigabit network, and so it may be that the gigabit values are lost  
due to their being less significant bits. While in some ways this  
makes sense, it will raise problems for routing protocols as it could  
lead to loops in min-cost routing algorithms (they can't tell if its  
1, 2, or 34 gigabit hops).

Let me qualify the above concern with the fact that I haven't read  
all of the drafts out there very closely, and so in the current  
protocols and intended uses, this may not be an issue. But going  
forward it may be, and so some protocols may end up placing  
limitations on what cost metrics they will use (e.g., Foo MUST NOT  
use an exponential cost metric encoding). So this doesn't mean that  
there shouldn't be exponential metrics, but rather that some  
protocols may preclude their use.

Phil

[1] TEP 123: The Collection Tree Protocol (CTP): http:// 
www.tinyos.net/tinyos-2.x/doc/html/tep123.html
[2] Kim, Pakzad, Culler, Demmel, Fenves, Glaser, Turon, "Health  
Monitoring of Civil Infrastructures Using Wireless Sensor Networks",  
IPSN07.

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 15 Aug 2007 17:23:14 +0100

> While in some ways this  

> 1, 2, or 34 gigabit hops).

Note that we explicitly note that you can, and must, accumulate in full
precision in 20-something (I don't have the draft - I'm referring to
draft-dearlove-olsrv2-metrics-00 - in front of me) bits without
transmitting 20-something bits, and hence there is no looping
issue on this front, and no loss of precision - so you can still
differentiate between e.g. one high cost link plus two low cost links
and one same high cost link and one low cost link.

---

From: Philip Levis <[email-masked]>
Date: Wed, 15 Aug 2007 09:32:01 -0700

> and one same high cost link and one low cost link.

Perhaps I'm missing something here: are the metrics in draft-dean- 
manet-metriclv-00 intended to only be link metrics, and not route  
metrics?  For example, the text reads:

"Node metrics SHOULD represent cost values associated with routing  
though that node."

What you're saying makes sense for link metrics that accumulate to a  
higher precision node metric. But if the node metric is 8 bits...

Phil

---

From: "Justin Dean" <[email-masked]>
Date: Wed, 15 Aug 2007 15:18:47 -0400

A few comments on draft-dean-manet-metriclv-00.  First I would like to thank
everyone for reading and commenting on the document.  The discussion about
the need for larger precision metrics with uniform precision across the
value space is something I am going to try and fit into the next version of
the draft 24 bit link metrics and new 32 bit path metrics.  

I was also playing around with the (16 + a) * 2^b - 15 method of
representation as it seems to better match the scale of the flat
representation (no fractions).  The only issue I don't like with it is the
fewer number of linear representations 1-15 to 1-31, but only representing
integer values maps better with the linear representation and the trade off
may be worth it.

The inclusion of a node metric is because of the difference in wireless to
wired medium.  It may make more sense to transmit a value of say estimated
contention on a per node basis rather than a link basis.

I am also working on cleaning up the definitions of "cost value" and
"metric" used in the dean metric draft.  Cost value is the abstract or
defined unit to be conveyed. A metric in my draft is just the container and
numerical representation of the cost value.  

Justin

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 12:32 PM
To: Dearlove, Christopher ((UK))
Cc: [email-masked]; [email-masked]; Thomas Clausen
Subject: Re: [manet] RE: Comments on Metric TLV

On Aug 15, 2007, at 9:23 AM, Dearlove, Christopher ((UK)) wrote:

> Note that we explicitly note that you can, and must, accumulate in 
> full precision in 20-something (I don't have the draft - I'm referring 
> to draft-dearlove-olsrv2-metrics-00 - in front of me) bits without 
> transmitting 20-something bits, and hence there is no looping issue on 
> this front, and no loss of precision - so you can still differentiate 
> between e.g. one high cost link plus two low cost links and one same 
> high cost link and one low cost link.

Perhaps I'm missing something here: are the metrics in draft-dean-
manet-metriclv-00 intended to only be link metrics, and not route metrics?
For example, the text reads:

"Node metrics SHOULD represent cost values associated with routing though
that node."

What you're saying makes sense for link metrics that accumulate to a higher
precision node metric. But if the node metric is 8 bits...

Phil

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Thu, 16 Aug 2007 09:43:21 +0100

As I noted, I'm referring to draft-dearlove-olsrv2-metrics-00,
which doesn't have node metrics. But the node metric you refer
to is, I believe, an additional term to be accumulated, not
the accumulator.

-----Original Message-----
From: Philip Levis [mailto:[email-masked]] 
Sent: 15 August 2007 17:32
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; Thomas Clausen
Subject: Re: [manet] RE: Comments on Metric TLV

               *** WARNING ***

On Aug 15, 2007, at 9:23 AM, Dearlove, Christopher ((UK)) wrote:

> full

Phil