Hi Charlie, Hi Vicky,
Am 29.04.2015 um 18:21 schrieb Charlie Perkins <charles.perkins@xxxxxxxxxxxxx>:
Good morning Vicky,
On 4/29/2015 8:02 AM, Victoria Mercieca wrote:
Hi Charlie,
Thanks for the replies on this - I'm gradually catching up.
Further comments in line...
On Thu, Apr 16, 2015 at 10:32 PM, Charlie Perkins
<charles.perkins@xxxxxxxxxxxxx> wrote:
Hello Vicky,
Follow-up below...
On 4/16/2015 7:00 AM, Victoria Mercieca wrote:
This email is about metrics (Section 7 in Version 9a or Section 5 in
Version 9b):
We refer to RFC6551. This defines more than just HopCount = 3. e.g. node
energy, link throughput, link latency, link reliability and ETX
reliability. Our IANA section doesn't list these under MetricTypes,
actually it says those numbers are unallocated. Should we change this?
The problem is that some of the metrics in RFC 6551 are not monotonically
increasing,
like the reliability metrics. In my opinion this is a problem that needs to
be fixed, but
we can't do that right now.
We dont support them, fair enough, but someone writing an implementation, if
they worked out the Cost and LoopFree functions, might be able to.
I would suggest that we dont mark those numbers as unallocated in our AODVv2
draft. Perhaps at a minimum do it like this:
MetricType Type
------------------ ----
Unassigned 0
Currently Unsupported 1 - 2
Hop Count 3
Currently Unsupported 4 - 8
Unallocated 9 - 254
Reserved 255
What do you think?
Interestingly there are fields mentioned in RFC 6551 which signal that the
metric is additive, maximum, minimum or multiplicative. For future
discussion perhaps.
"monotonically increasing" means increasing or remaining constant (i.e.
anything but decreasing), so is it more correct to say "strictly
increasing"? For hopcount at least, Cost(L) is always 1 and route cost will
always increase with number of links. We can support any strictly
increasing metric using Cost(R) = sum of Cost(L), and our current LoopFree
function, I think. Charlie previously said link cost could be less than one
for some metrics. Since alternate metrics are out of scope anyway, I don't
know if that's relevant. They would need different Cost and LoopFree
functions. Is "strictly increasing" the same as "additive"? From some
Google searching, "additive" seems to refer to metrics themselves, whereas
"monotonically" or "strictly increasing" would refer to the route cost
function.
I think that strictly increasing is better actually.
Should I replace uses of "monotonically increasing" with "strictly
increasing" then?
The definitions of our abstract functions should not depend on whether the
minimum positive metric is 1.
Latency is a good example of such an strictly increasing (and additive)
metric. I reckon that as soon as we
get into Last Call, we (or I) should be looking at enlarging the number of
metrics available.
Strictly increasing is not the same as additive.
So I'm still a bit confused. What's the difference?
Should we have a configuration option for MetricTypes in use? Or should we
support all metric types we see in received messages? Or is this what is
meant by "check that the metric type is known"?
I am O.K. to describe this as a configuration option. However, it is new
text about
something that no one was complaining about. But if the text is written, I
am sure
no one would complain about that either :-)
What about this:
An AODVv2 implementation MAY be configured to use a limited set of the
supported metric types. In the processing described in [Section on
messages], a known MetricType can be
interpreted as a configured MetricType. If a message is received using an
unknown or non-configured
MetricType it will be ignored. If the message is not regenerated, other
routers which do support the
MetricType will not be able to route through a router which does not support
the MetricType.
We havent decided on whether to make default metric type 0 for
simplification.
Well, RFC 6551 says that hopcount is type 3, so it would be bad to also have
it be type 0.
Lotte previously said:
- Henning confirmed to me what he wrote on the list[1]: When using
extension types, If we set DEFAULT_METRIC_TYPE to 0, this will save us 1
byte as opposed to leaving DEFAULT_METRIC_TYPE at 3, because: the
*variable* tlv-type-ext is *always* set, and it is set to 0 by default. If
the <tlv-type-ext> *flag* is set, too, tlv-type-ext will have the value
that <tlv-type-ext> has. So the exttype 0 is always set, and we just need
to make use of it.
RFC 5444 says:
tlv-type-ext is a variable, defined to equal <tlv-type-ext>, if present, or
0 otherwise.
I might not completely understand, but this is what I was thinking:
If our configuration says DEFAULT_METRIC_TYPE is 3 (HopCount) and we dont
include a MetricType when we are talking about DEFAULT_METRIC_TYPE, isn't
the lack of a value in RFC5444 kind of the same as including a value of
zero? What does the receiving node see - either metricType 0, or no
MetricType included. Either way, wont it interpret this as
DEFAULT_METRIC_TYPE, i.e., 3?
I think this is a good solution.
Metric Type 0 according to RFC 6551 is Unassigned, I dont think it will ever
be used to mean a specific metric type?
Yes, I agree.
Regards,
Charlie P.
