Hi all,
I think this topic is finished now. Thanks for all your comments. A couple
of comments just as a reply in-line:
On Tue, May 5, 2015 at 4:07 PM, John Dowdell <john.dowdell486@xxxxxxxxx>
wrote:
Hi all
On 30/04/15 15:38, Victoria Mercieca wrote:
Hi all,
Just refreshing this email:
- We refer to RFC6551. This defines more than just HopCount = 3.implementation, if they worked out the Cost and LoopFree functions, might
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
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?
Any comments?
Sounds good to me.
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 constantincreasing" then?
(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
Covered in last Hangout, see next comment.
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?
Covered in last Hangout.
So the text I have referring to this is in the Alternate Metrics section
and says:
Metrics may be additive (sum of link costs), concave (minimum of link
costs), convex (maximum of
link costs), or multiplicative (product of link costs), as discussed in
RFC 6551. The Cost and
LoopFree functions will differ for each type.
AODVv2 can support additive metrics using the Cost(R) and LoopFree(R1, R2)
functions defined for
the default metric. Further, any strictly increasing metric can be
supported using the LoopFree
function defined. It is, however, out of the scope of this document to
specify for alternate metrics
the correct Cost(L), Cost(R), and LoopFree() functions. Where possible
these should take into account
differences in the link cost in each direction.
Any comments?
Also sounds good. There could be catcalls from the gallery, but it's
abundantly clear that catering from metrics that are not additive is for a
later draft, in the spirit of the IETF. We should perhaps make this clear
in tomorrow's manet webex.
- 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.
Any comments?
Following a similar food fight on another draft, I'm inclined to ask that
routing messages received for metrics that are not supported SHOULD be
dropped. Otherwise we *could* have a security risk where a router starts
deliberately (or perhaps mistakenly) flooding routing messages with unknown
metrics which then get forwarded around the network ad infinitum. However
that might not fit a system implementers vision so they have the option to
relay the messages should they wish to risk the flooding.
But I'm open to discussion.
my phone which had too many ">"'s in to be able to read!):
- We havent decided on whether to make default metric type 0 forLotte previously said:
simplification.
Well, RFC 6551 says that hopcount is type 3, so it would be bad to also
have it be type 0.
- 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.
Me too.
Do we need text to explain this better? And where should it go? In the
"Network Wide Settings" bit in the Configuration section, where
DEFAULT_METRIC_TYPE is defined to be 3? Or the MetricType bit of the IANA
section?
Maybe we could say:
When creating AODVv2 messages which relate to the DEFAULT_METRIC_TYPE,
MetricType is not reported in the message. In the RFC 5444 representation,
the Metric TLV does not include an extension type. While RFC 5444 would
interpret this by setting extension type to zero, AODVv2 interprets an
extension type of zero as the DEFAULT_METRIC_TYPE configured on the router.
This is possible because zero is not assigned to any metric type (see RFC
6551).
What do you think?
Interesting, a 6551 / 5444 conflict. Sounds like one to bump to the manet
list for adjudication.
Repeating my comment from my last metrics email (the one I replied to on
John
Regards,
Vicky.
