Subject: [manet] Stephen Farrell's No Objection on draft-ietf-manet-olsrv2-dat-metric-10: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 03 Dec 2015 06:10:14 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-olsrv2-dat-metric-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-dat-metric/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- General: This seems mostly to be an abstract metric that could be
re-used e.g. in ROLL or HOMENET (if it's good:-) but with
OLSR-specific text and concepts mixed in here and there.  It'd have
been better were it possible to separate the abstract metric from
the OLSR-specifics to make the former easier to re-use later. It's
fine if determining if that would be useful is a part of the
experiment, but it might be good to mention it here.

- Section 6: In particular "fraction of the loss rate" isn't clear
to me, but maybe that's fine and it's known term of art to folks who
do metrics.

- Section 11: Wrt the MitM comments from other ADs - one possiblity
here might be to recommend that protocols making use of this metric
should be cognizant of, and include mitigtions for, MitM attacks of
this kind. (Just a suggestion, feel free to ignore if you prefer.) 

- Thanks for handling the secdir review [1] - I think that all the
issues there were resolved, but do say if some still need a bit
more chatting.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06185.html

---

From: [email-masked]
Date: Fri, 4 Dec 2015 03:33:00 +0100

Stephen,

I was actually one of the people recommending that the authors focus on OLSRv2. 

The reason for that being, simply, that we do not know how this metric behaves with other protocols (yet), whereas we have some idea of how it behaves with OLSRv2.  I also do not think that we know how it would fit into the other protocols in this WG, not to mention in other WGs. 

You are right, of course, if the experiment that this document enables allows figuring that out, it would be interesting.

Yet, I think that the primary goal (and, perhaps, the only real bar for progressing eventually to std.track) of this experiment should be “confirm if this is a metric worth recommending for OLSRv2” not “set out to boil the ocean and come up with the one metric to rule them all”… 

Thomas

> On 03 Dec 2015, at 15:10, Stephen Farrell <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 4 Dec 2015 07:39:45 +0000

Yes, OLSRv2 is the obvious use case. But separation of concerns: the abstract metric definition from the metric representation from the metric use, is always good. Though not having the draft in front of me, I'm not sure how much work that would be.

-- 
Christopher Dearlove
[email-masked] (iPhone)
[email-masked] (home)

> On 4 Dec 2015, at 02:33, [email-masked] wrote:
> 
> Stephen,
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 11:44:08 +0000

On 04/12/15 02:33, [email-masked] wrote:
> The reason for that being, simply, that we do not know how this
> metric behaves with other protocols (yet), whereas we have some idea
> of how it behaves with OLSRv2.  I also do not think that we know how
> it would fit into the other protocols in this WG, not to mention in
> other WGs.
> 
> You are right, of course, if the experiment that this document
> enables allows figuring that out, it would be interesting.
> 
> Yet, I think that the primary goal (and, perhaps, the only real bar
> for progressing eventually to std.track) of this experiment should be
> “confirm if this is a metric worth recommending for OLSRv2” not “set
> out to boil the ocean and come up with the one metric to rule them
> all”…

Understood, and my comment is entirely non-blocking.

However, wondering if the metric might work for ROLL and HOMENET
is hardly ocean-boiling, nor I think is considering re-use in
other pieces of similar ongoing IETF work.

I hope someone does think about this and we don't end up with a
battle of metrics nonsensically based on which protocol I'm using
on the same lower layers in the same conditions.

Cheers,
S.

>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>> 
>> 
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>> 
>> 
>> OLSR-specific text and concepts mixed in here and there.  It'd
>> have been better were it possible to separate the abstract metric
>> from the OLSR-specifics to make the former easier to re-use later.
>> It's fine if determining if that would be useful is a part of the 
>> to me, but maybe that's fine and it's known term of art to folks
>> who do metrics.
>> 
>> - Section 11: Wrt the MitM comments from other ADs - one
>> possiblity here might be to recommend that protocols making use of
>> this metric should be cognizant of, and include mitigtions for,
>> MitM attacks of this kind. (Just a suggestion, feel free to ignore
>> if you prefer.)
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06185.html
>> 
>> 
>> _______________________________________________ manet mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/manet
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 4 Dec 2015 13:03:06 +0100

> on the same lower layers in the same conditions.

Could this take the form of an appendix... one that discuss the
"input" of the DAT metric and how it could be adapted to other
protocols?

Henning Rogge

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 4 Dec 2015 12:08:42 +0000

> "input" of the DAT metric and how it could be adapted to other

You could do that. But that'd be more than I was asking about
really.

Mostly, what I think might be good is to say something like:
"the outcome of this experiment will include consideration of
whether and, if so, how, this metric could be re-used in other
relevant IETF protocols."

S.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 04 Dec 2015 16:42:33 +0100

> The reason for that being, simply, that we do not know how this metric
> behaves with other protocols (yet),

Uh-huh.

Unlike ETX, ETT and friends, this metric is unidirectional -- it only
considers packet loss in one direction.  Since OLSRv2 already has
a mechanism for pruning unidirectional links, DAT in OLSRv2 will only be
applied to bidirectional links, and therefore yield reasonable results.
This would not be the case in, say, Babel, where the protocol relies on
the metric to detect and prune unidirectional links.

(Of course, there's nothing preventing one from adding an OLSRv2-style
mechanism to Babel, but that doesn't contradict my point, which is that
DAT *as it is defined now* would probably not work well with Babel *as it
is defined now*.)

So I think we're in full agreement -- DAT should not be recommended for
protocols other than OLSRv2 until we have more data.

(I mentioned in Berlin that the point about OLSRv2 using bidirectional
links only should be made explicitly in the document, I don't know if this
comment was taken into account.)

-- Juliusz

---

From: Christopher Dearlove <[email-masked]>
Date: Fri, 4 Dec 2015 16:45:31 +0000

If getting into the details, we want them correct. NHDP records unidirectional and bidirectional links. OLSRv2 extends NHDP by assigning metrics to those links, these metrics being unidirectional. While a link is unidirectional (HEARD) it will have a metric in that direction only. Once a link becomes bidirectional it will have a metric in each direction, but these are unidirectional, hence may differ. OLSRv2 (the rest of it) then only uses these bidirectional links, using the appropriate metrics.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 7 Dec 2015 12:13:15 +0100

> relevant IETF protocols."

I will add this to a draft 11 version.

Henning Rogge