Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 31 Mar 2014 01:08:29 -0700

Hello folks,

I finally got around to reading some of the draft.  I did notice a
couple of typos (can supply on request), but have a couple of
other issues.  Maybe they would be answered if I finished the
draft, but that has to wait at least a few more days...

- I understand the point to be that connectivity and thus
   topology is determined by existence of a link where the
   routers are "willing" and can satisfy the desired metric (say,
   to have sufficient bandwidth).  One could imagine a topology
   where only links of > 10kb/sec were allowed, and another
   topology where only links of > 10Mb/sec were allowed.  Does
   the draft intend to enable this?

- I have always understood a metric to be a function that assigns
   a metric value to a routing path.  Then, a metric type defines
   the way that the function associates a value to a routing path.
   Using typical functional notation, we would have:
     v = f(path), where f is the metric and v is the value that f
            assigns to the path.
   Going a step further, we can consider the space of all routing
   metrics, and have a "big" function F that assigns a metric value
   to a path given two parameters -- namely, metric_type, and path.
   Using typical functional notation, we would have:
   v = F(type, path)

   Using this notation, then, the domain of f is "paths" and the
   range is some set of allowable values.  Let's say that the domain
   of f is D(f) and the range is R(f).  Then, as for any function,
   we have f(D(f)) "is a subset" of R(f).  Here, D(f) is {paths},
   and R(f) depends on the metric type of f (f is a metric).  We
   can also say that D(F) == {metric_types} x {paths}, where 'x'
   is cross product and {metric_types} is the set of all metric
   types.

   The terminology in the draft should not be at odds with these
   conventional mathematical notations.
   map[range -> type]  seems to say that the "range" is the domain.
   It is confusing in multiple ways to say that "metric types" are
   either:
         boolean,
         a willingness (a 4 bit unsigned integer from 0 to 15),
         a number of hops (an 8 bit unsigned integer ..),
         or a metric-value (as defined somewhere else).

   because (a) boolean and #hops are already allowable metric values, and
   (b) these are actually possible ranges for certain metric functions,
       which take as input a path and provide as output a value within
       the range of allowable values for the metric type.  Moreover, if
       it were really intended for the "range" to be the argument of the
       abovementioned map, then the discussion can no longer be
       well-formed without terrible restrictions on the types of metrics
       considered.

- The draft restricts applicability to "managed" MANETs.  That is
    probably appropriate, but could stand to have somewhat better
    definition.  For the purposes of the draft, I imagine that
    "manageability" means "running a specific predetermined set of
    applications".

-- 
Regards,
Charlie P.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 31 Mar 2014 09:07:23 +0000

Some comments below marked CMD.

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Charles E. Perkins
Sent: 31 March 2014 09:08
To: Stan Ratliff (sratliff); Christopher Dearlove
Cc: [email-masked]
Subject: Re: [manet] comments on draft-dearlove-manet-olsrv2-multitopology-02

----------------------! WARNING ! ---------------------- This message originates from outside our organisation, either from an external partner or from the internet.
Consider carefully whether you should click on any links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters for instructions on reporting suspicious email messages.
--------------------------------------------------------

Hello folks,

I finally got around to reading some of the draft.  I did notice a couple of typos (can supply on request), but have a couple of other issues.  Maybe they would be answered if I finished the draft, but that has to wait at least a few more days...

CMD: Each link may or may not have a specific type of metric assigned, and therefor that link may or may not be part of the corresponding topology. It is thus straightforward to implement the example you describe.

The metrics are all (as in OLSRv2) assigned to links, path metrics are the sum of link metrics.

   Using this notation, then, the domain of f is "paths" and the
   range is some set of allowable values.  Let's say that the domain
   of f is D(f) and the range is R(f).  Then, as for any function,
   we have f(D(f)) "is a subset" of R(f). 

Actually, that's not the mathematical notation I would use. Range is an overloaded term, some use it for R(f), some use it for f(D(f)). My lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is the image, range was banished.

   Here, D(f) is {paths},

Range is an overloaded word, and this isn't using it in that way. Though it's not a great usage even if we ignore the functional usage. I take your point, we should reconsider this terminology.

No, you've inserted the metric in your quote. This is saying that the type of the codomain of the map is always one of those three things. Generic type, not metric type. The domain is an ordered set of metric types. Those three things are things assigned to a topology (indexed by metric type).

CMD: No, I wouldn't make that definition, there's no reason to be that limited. What's critical is that routers will make a consistent judgement when forwarding a packet, which metric type should be used to forward that packet. What's important is that routers have a consistent approach to each metric type. (Critical means will do unpleasant things, like maybe looping, if not so. Important means will behave poorly, and may find bad routes, or no routes, if not so.) If it's agreed that (say) metric type X means fast reliable delivery, that X corresponds to DHCP type Y, and that packets should not be labelled Y without a very good reason, then we don't need to specify exactly what applications might create packets of that type.

--
Regards,
Charlie P.

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

********************************************************************
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: Abdussalam Baryun <[email-masked]>
Date: Mon, 31 Mar 2014 11:27:07 +0100

Hi Chris,

I need to understand more that why I request more explain. Thanks,

On Mon, Mar 31, 2014 at 10:07 AM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> Subject: Re: [manet] comments on
> draft-dearlove-manet-olsrv2-multitopology-02
>

> Hello folks,
>
> I finally got around to reading some of the draft.  I did notice a couple
> of typos (can supply on request), but have a couple of other issues.  Maybe
> they would be answered if I finished the draft, but that has to wait at
> least a few more days...
>
> CMD: Each link may or may not have a specific type of metric assigned, and
> therefor that link may or may not be part of the corresponding topology. It
> is thus straightforward to implement the example you describe.
>
You said before that each packet has the same topology within the MANET,
but now you mention in the OLSRv2 MANET a router MAY assign metric-types
to its links. IMO, that means the topology is dynamic with metric per
router, and that may not insure each packet has one topology.

> The metrics are all (as in OLSRv2) assigned to links, path metrics are the

Do you mean OLSRv2 path metric is the sum of links' metrics? I think you
mean some types of path costs, not all path costs.

IMHO, in the multi-toplogy situation we have one routing metric for each
topology, your text seem to say the OLSRv2 metrics are assigned only to
links (not to paths within the topology).

Best Regards

AB

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 31 Mar 2014 10:02:22 -0700

Hello Chris,

> CMD: Each link may or may not have a specific type of metric assigned, and therefor that link may or may not be part of the corresponding topology. It is thus straightforward to implement the examp…

How would you describe the metric type for the two examples
as shown above?

> The metrics are all (as in OLSRv2) assigned to links, path metrics are the sum of link metrics.

This is natural; one can consider a "link" to be a path with only one
path component...

> Actually, that's not the mathematical notation I would use. Range is an overloaded term, some use it for R(f), some use it for f(D(f)). My lecturers avoided that problem, R(f) is the codomain, and…

I reckon the word is not banished worldwide...  and, as you point out,
the word "codomain" is commonly defined differently than "range".

> Range is an overloaded word, and this isn't using it in that way. Though it's not a great usage even if we ignore the functional usage. I take your point, we should reconsider this terminology.

Thanks -- I think that would be very helpful to avoid confusion. Usually,
even for words with overloaded meaning, either the meanings are not
contradictory, or the context can help disambiguate.  Usually, but not
always in colloquial English.  I think it's rare or even nonexistent when
using mathematical notation to have contradictory meanings for the same
word...

> No, you've inserted the metric in your quote. This is saying that the type of the codomain of the map is always one of those three things. Generic type, not metric type.

I guess "generic type" means "data type".  "boolean" and the others can
indeed be considered data types.  Since this effort is going to be closely
associated with managing metric types, maybe the draft has to be careful
about always using either "data type" or "metric type".  By the way, why
did you say "three things" instead of "four things"?

>   The domain is an ordered set of metric types.

Is it *really* an ordered set??  What is the ordering?  I would have
thought the only important thing here is that the correspondence
is a function.

>   Those three things are things assigned to a topology (indexed by metric type).

I think you mean something different, because the same topology
can very definitely be delineated by two different metrics.  Thus, you
would have to define some sort of multi-valued correspondence.
Yes, this can be done, but it is considerably more complicated.

> CMD: No, I wouldn't make that definition, there's no reason to be that limited. What's critical is that routers will make a consistent judgement when forwarding a packet, which metric type should b…

Sure.  It's almost tautological to limit the definition by your condition.
However, one has to wonder why the condition would be imposed.
When I start wondering that, the answer I get is that one wants to do
this because some application needs to be presented with a strictly
delimited set of routing choices, as defined by the metric (for example,
the "Cap-GT-10Mbps" metric).

-- 
Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 31 Mar 2014 10:05:15 -0700

Hello again Chris,

Correcting my mistake below...

On 3/31/2014 10:02 AM, Charles E. Perkins wrote:
>
>>
>> Actually, that's not the mathematical notation I would use. Range is 
>> an overloaded term, some use it for R(f), some use it for f(D(f)). My 
>> lecturers avoided that problem, R(f) is the codomain, and f(D(f)) is 
>> the image, range was banished.
>

I should have said "image" is commonly defined differently than "range".

-- 
Regards,
Charlie P.

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 31 Mar 2014 18:48:54 +0100

> How would you describe the metric type for the two examples

I'd pick two metric types from those available to be allocated administratively (which is missing from the IANA considerations section, but mentioned somewhere else) and define them that way in that network. (As something that specialised, it's not going to have a universal definition.)

> This is natural; one can consider a "link" to be a path with only one

That's putting the cart and the horse the wrong way round. This is a link state protocol. Metric are defined for links. Metrics for routes are defined as the sum of the link metrics, they have no separate existence from that. See RFC 7181 (as it will be in a few days).

> the word "codomain" is commonly defined differently than "range".

Of course it's not banished worldwide. But I wouldn't use it anything precise, because of the ambiguity., and the availability of image and codomain to be precise. (And actually, there's a third option I could point to, where image and codomain are, of necessity, the same.) But it's all irrelevant. I agree the usage of range as it current is, is confusing because range is often used as a "right hand" thing, whether image or codomain is irrelevant.

> using mathematical notation to have contradictory meanings for the same

Definitely not nonexistent.

Range is one. If you want another, trapezium and trapezoid switch meanings when you cross the Atlantic.

But I'm not going to get further stuck into that discussion. It's irrelevant to this draft - and this list.

> did you say "three things" instead of "four things"?

Simple error (to the three/four). Consistently using the qualification you suggest for type is, I think (but co-authors can have opinions) a useful one. (And there are other types too, related to 5444, but I think those are already all qualified.)

> thought the only important thing here is that the correspondence

Is it ordered? Actually in this context, or a map, it doesn't need an order. But it does need an order when included in a message in TLVs. Personally I'd therefore implement it ordered so as to not have to sort those that needed to be ordered to include in TLVs. And then might as well do the same for all. But in an abstract model, it doesn't always (possibly never) need ordering. But I would need to read with care relating to parameter usage.

> Yes, this can be done, but it is considerably more complicated.

No, I mean what I said. This model of multi-topology has a one to one correspondence between metric type and topology. So the topologies are conveniently indexed by metric type. (Yes, many to one is considerably more complicated, especially with backward compatibility.)

> the "Cap-GT-10Mbps" metric).

We need this to avoid any possibility of looping. That really is the reason. We had this discussion a while back on the list. And I wouldn't want to couple the network layer to applications.