Subject: [manet] Comments to DLEP discussion at IETF 86

From: Henning Rogge <[email-masked]>
Date: Mon, 18 Mar 2013 12:59:50 +0100

Hi,

just listened to the discussion about DLEP, so here is my comment on it.

Asymmetric metrics
------------------

I agree with Teco that asymmetric "maximum data rate" is useful. There 
are both radios and modems with asymmetric capabilities.

But I think we do NOT need asymmetric for "resources".

The reason for this split is that I see a difference between "node 
metrics" and "link metrics".

I think the Resource TLV talks more about resources of a node, not about 
the connection between two nodes. So it has no "direction". But most 
TLVs could have "incoming" and "outgoing", even things like "radio 
channel frequency".

Experimental metric
-------------------

I think we should keep a 'large enough' experimental metric space (not 
only 2-4), but I also think we should add more "standardized" metric TLVs.

Maybe we could have a look at the metric section of my ID and discuss 
which one we could/should include into the DLEP RFC

Leaving everything beyond the most basic metrics to "vendor specific" 
encoding will make interoperability much harder.

About "vendor specific" TLVs... I am not sure how much I like this, 
because it can use up the 256 TLV types quickly.

DLEP-draft vs. rfc5444-dlep-draft
---------------------------------

I think we should not reopen this discussion. We have talked about the 
"rfc5444 vs. custom format" and "session vs. timer-based" approach for 
quite some time, but I think we should focus on more important things.

The most important thing is that we arrive at a DLEP specification that 
is strict and specific enough that we can assume that two independent 
implementations (one radio, one router) will be able to interoperate 
without any coordination between the implementors.

Based on our discussions (about the ack-mechanism for example) I would 
say we made progress in this area, but we have to keep an eye on this.

The second are we have to take care of is what list of metrics (optional 
or not) we include into the DLEP RFC. At the moment we have a quite 
"minimalistic" list of metrics, which means that vendors have to make up 
(incompatible) encodings for the same metric over and over.

I also had a discussion with Stan and a few others about metric related 
(and controversial) topics, I will try to summarize them in a different 
mail.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Mon, 18 Mar 2013 09:55:46 -0400

Thanks for the comments Henning,

Regarding the Asymmetric metrics discussion, I agree that binning the
metrics into "node metrics" and "link metrics" is a good idea. And for
node metrics, have it be only 1 metric and for link metrics, make them
bi-directional. I think it'd be pretty important for us to clearly define
the metrics and leave no ambiguity if that's the case. For example, the
"Resources" metric is a bit ambiguous. The example in Section 7.10 is
"Battery power", but I've seen people use "Resources" to indicate
something like link load (or rather, link resources being used) which
could be bi-directional. If it's battery power, then call it out and put
it under the "node metrics". If something else, call it out.

I do understand the author's intent to make some metrics "dimensionless"
and flexible, but the problem is metrics like RLQ and Resources are listed
in draft 03 as "MUST be reported". It then gets to be a big problem when
one radio manufacturer uses it for one thing, and another radio
manufacturer uses it for another thing. If its a radio-specific metric and
we want to make it "dimensionless" for radio manufacturers to do something
specific to their radio, then it probably should go under "OPTIONAL".

-Bow-Nan 

--
Bow-Nan Cheng, Ph.D.
MIT Lincoln Laboratory
Airborne Networks Group
244 Wood St Lexington MA 02420
781-981-4997

On 3/18/13 7:59 AM, "Henning Rogge" <[email-masked]>
wrote:

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