Subject: [manet] ETT metrics draft

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 15 Jul 2013 10:14:16 +0000

I have just managed to find time for a quick look over version -02 of the ETT metric draft. A few comments (I omit editorial comments, such as consistency of use of capitalisation of Link Tuple for a later draft).

Section 1

Would be useful context to note that adding metrics to OLSRv1 produced a proprietary extension to RFC 3626.

The Introduction should provide a bit more OLSrv2 context.

Section 3

Refers to [RFC3626] implementation. This is extended as noted above, which I think is important to applicability.

The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue that the control messages are sent broadcast, the data will be sent unicast. There's the well-known "grey zone" problem here that is usually solved with link quality (when using OLSRv1 with hop counts). It may well be that in practice things work, but there is an issue here that I think needs discussion.

Section 5

The use of packet sequence numbers relies on an erratum to RFC 5444. Do we assume everyone reads errata, or should this be commented on?

There's a metric normalisation issue for OLSRv2 (this divided by that - scaled?).

Section 6

ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used something similar in link quality calculations) then it should be only slightly larger than 1.0, which is worth saying.

Section 7

Here reading through I made a note thatr INTERVAL_TIME TLVs are optional. This is discussed later. But I think a section earlier on this may be appropriate. That section could also discuss entity relationships I'll get to below.

Section 9

At the WG's requirement, we have been careful to divide up different entities with different responsibilities, and controlled ways in which they may interoperate. This has required some care at times. I don't think this draft has put the same care in.

There are three entities: The RFC 5444 packet multiplexer (and demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put in a packet sequence number. OLSRv2 requests the 5444 multiplexer to add a packet sequence number. Likewise how OLSRv2 interacts with HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled. 

But this is more complicated than that. Because we are considering haps in packet sequence numbers, that means all packets need to be considered. That could include packets containing neither HELLO messages nor TC messages, which normally neither NHDP nor OLSRv2 will see. (They get reported their messages, and can access related packet information.) This is therefore in part a function interacting directly with the 5444 multiplexer, which is new, and we (WG, if this is adopted) should be clear on how to handle that - or someone (in the IESG if not sooner) will ask many difficult questions. Related to that is whether this extends NHDP, but is used by an extension to OLSRv2, or extends just OLSRv2, and is solely defined in that context.

Section 9.2

When it says "packets without packet sequence number MUST NOT be processed, that's not quite right  in terms of the 5444/NHDP/OLSRv2 model, as discussed above. Also not clear from this wording that you just mean for purpose of metric calculation.

Section 9.2/9.3 (or other for resolution)

Need a bit more clarity on what to do if you don't get helpful input (missing PSN or INTERVAL_T IMETLV). You still need a metric if the Link Tuple is on an OLSRv2 interface, obviously maximum, but that's only said in the processing, not in the can't process part.

Section 11

Looking at the L_in_metric calculation, is that calculation going to produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time right now to check that). Even if it does, needs comment about rounding/truncating to a representable value (note that L_in_metric must be representable, it's in the OLSRv2 constraints this is bound by).

Section 12

These are possibly suitable values for Wi-Fi. That may be fine for Funkfeuer, but if this is adapted as a WG document we need to be more general that that., and to separate what's specific to that and what isn't. We need to be able to understand that if, for example, I want to use this on a system that varies between say 1 kbit/s and 256 kbit/s, what other parameters change?

Section 14

Suggest referencing the NHDP/OLSRv2 integrity draft.

-- 
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

********************************************************************
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: Justin Dean <[email-masked]>
Date: Tue, 16 Jul 2013 12:56:10 -0400

I've also had a little bit of time to look over the draft. My comments at
this point are more general than Chris' were. I found the draft overly
confusing. The was an ok summary of what the metric is supposed to do, but
the it jumps right into details. Without a good idea of how things are
supposed to work the variable descriptions just add to the confusion.  I
don't think it needs to be this complicated, in fact I find it worrisome
that I wasn't able to more easily figure out how I would start implementing
it. I'll provide more detailed feedback and possible text when I can find
some cycles.

Justin
On Jul 15, 2013 6:15 AM, "Dearlove, Christopher (UK)" <
[email-masked]> wrote:

> I have just managed to find time for a quick look over version -02 of the
> ETT metric draft. A few comments (I omit editorial comments, such as
> consistency of use of capitalisation of Link Tuple for a later draft).
>
> Section 1
>
> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the issue
> that the control messages are sent broadcast, the data will be sent
> unicast. There's the well-known "grey zone" problem here that is usually
> solved with link quality (when using OLSRv1 with hop counts). It may well
> be that in practice things work, but there is an issue here that I think
> needs discussion.
>
> Section 5
>
> The use of packet sequence numbers relies on an erratum to RFC 5444. Do we
> assume everyone reads errata, or should this be commented on?
>
> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have used
> something similar in link quality calculations) then it should be only
> slightly larger than 1.0, which is worth saying.
>
> Section 7
>
> Here reading through I made a note thatr INTERVAL_TIME TLVs are optional.
> This is discussed later. But I think a section earlier on this may be
> appropriate. That section could also discuss entity relationships I'll get
> to below.
>
> Section 9
>
> At the WG's requirement, we have been careful to divide up different
> entities with different responsibilities, and controlled ways in which they
> may interoperate. This has required some care at times. I don't think this
> draft has put the same care in.
>
> There are three entities: The RFC 5444 packet multiplexer (and
> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put in a
> packet sequence number. OLSRv2 requests the 5444 multiplexer to add a
> packet sequence number. Likewise how OLSRv2 interacts with HELLO messages
> needs care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled.
>
> But this is more complicated than that. Because we are considering haps in
> packet sequence numbers, that means all packets need to be considered. That
> could include packets containing neither HELLO messages nor TC messages,
> which normally neither NHDP nor OLSRv2 will see. (They get reported their
> messages, and can access related packet information.) This is therefore in
> part a function interacting directly with the 5444 multiplexer, which is
> new, and we (WG, if this is adopted) should be clear on how to handle that
> - or someone (in the IESG if not sooner) will ask many difficult questions.
> Related to that is whether this extends NHDP, but is used by an extension
> to OLSRv2, or extends just OLSRv2, and is solely defined in that context.
>
> Section 9.2
>
> When it says "packets without packet sequence number MUST NOT be
> processed, that's not quite right  in terms of the 5444/NHDP/OLSRv2 model,
> as discussed above. Also not clear from this wording that you just mean for
> purpose of metric calculation.
>
> Need a bit more clarity on what to do if you don't get helpful input
> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the Link
> Tuple is on an OLSRv2 interface, obviously maximum, but that's only said in
> the processing, not in the can't process part.
>
> Section 11
>
> Looking at the L_in_metric calculation, is that calculation going to
> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time right
> now to check that). Even if it does, needs comment about
> rounding/truncating to a representable value (note that L_in_metric must be
> representable, it's in the OLSRv2 constraints this is bound by).
>
> Section 12
>
> These are possibly suitable values for Wi-Fi. That may be fine for
> Funkfeuer, but if this is adapted as a WG document we need to be more
> general that that., and to separate what's specific to that and what isn't.
> We need to be able to understand that if, for example, I want to use this
> on a system that varies between say 1 kbit/s and 256 kbit/s, what other
> parameters change?
>
> Section 14
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 16 Jul 2013 14:29:51 -0700

Hi,

I have also reviewed the draft. Since it's an early draft, just some
high-level comments:
  - I like the idea of specifying the ETT metrics and I hope you will
issue a new revision.

  - The introduction is a bit confusing. It talks about the Funkfeuer
networks, and then suddenly jumps into details about ETT metric. I
would suggest to focus the document on the metric itself, and
mentioning the Funkfeuer networks only in the appendix. I also wonder
why the intended status is informational? Shouldn't it be Experimental
or Standards Track, since a protocol extension is specified?
  - section 3 (Applicability); again, I would defocus on the Funkfeuer
networks, just mention in general the use cases where the metric is
useful. You should focus more on OLSRv2 itself, IMO.
  - same section: "ETX metric that was used in the earlier [RFC3626]
implementation". Note that RFC3626 only uses hop-count, so technically
the olsr.org implementation was not RFC3626 compliant
  - section 7: Since the link tuples are extended, does that mean that
draft-ietf-manet-olsrv2 is "updated" (in the IETF sense)? If so, the
draft does not say that in the header, nor mention that in the
introduction and abstract. I assume that an informational document
could also not do that.
 - "L_ETT_last_pkt_seqno  is the last received packet sequence number
received from this link." Shouldn't there some section somewhere to
describe requirements, such as access to lower layers (e.g., packet
sequence numbers)?
 - section 9 mixes a bit the different layers (RFC5444 and RFC6130). I
wonder if that could not be more separated.
 - some lower case "must" in section 9; should that be 2119 or not?
 - section 13: Shouldn't that be a new link metric type allocation?
How is the metric used in the OLSRv2 network?
 - why is OLSRv2 only an informative reference? Can there be normative
references in an Informational document?

- I agree with Chris' and Justin's reviews.

Best regards
Ulrich

On Tue, Jul 16, 2013 at 9:56 AM, Justin Dean <[email-masked]> wrote:
> On Jul 15, 2013 6:15 AM, "Dearlove, Christopher (UK)"
> <[email-masked]> wrote:
>>
>> that the control messages are sent broadcast, the data will be sent unicast.
>> There's the well-known "grey zone" problem here that is usually solved with
>> link quality (when using OLSRv1 with hop counts). It may well be that in
>> practice things work, but there is an issue here that I think needs
>> discussion.
>>
>> Section 5
>>
>> packet sequence number. OLSRv2 requests the 5444 multiplexer to add a packet
>> sequence number. Likewise how OLSRv2 interacts with HELLO messages needs
>> care, see OLSRv2 draft for how LINK_METRIC and MPR TLVs are handled.
>>
>> new, and we (WG, if this is adopted) should be clear on how to handle that -
>> or someone (in the IESG if not sooner) will ask many difficult questions.
>> Related to that is whether this extends NHDP, but is used by an extension to
>> OLSRv2, or extends just OLSRv2, and is solely defined in that context.
>>
>> Section 9.2
>>
>> now to check that). Even if it does, needs comment about rounding/truncating
>> to a representable value (note that L_in_metric must be representable, it's
>> in the OLSRv2 constraints this is bound by).
>>
>> Section 12
>>
>> We need to be able to understand that if, for example, I want to use this on
>> a system that varies between say 1 kbit/s and 256 kbit/s, what other
>> parameters change?
>>
>> Section 14
>>

---

From: Henning Rogge <[email-masked]>
Date: Mon, 22 Jul 2013 11:07:03 +0200

Hi,

I finally had the time to work through the set of reviews from last week.

My comments are inline below.

Comments inline

On 07/15/2013 12:14 PM, Dearlove, Christopher (UK) wrote:
> I have just managed to find time for a quick look over version -02 of
> the ETT metric draft. A few comments (I omit editorial comments, such
> as consistency of use of capitalisation of Link Tuple for a later
> draft).
>
> Section 1
>
> Would be useful context to note that adding metrics to OLSRv1
> produced a proprietary extension to RFC 3626.
>
> Refers to [RFC3626] implementation. This is extended as noted above,
> which I think is important to applicability.

I think we will have to work more on Section 1/3, maybe pushing the 
whole "OLSr.org history" part to a section of its own so we can focus 
more on OLSRv2 section 1/3?

> The use of control message loss rate on Wi-Fi (IEEE 802.11) has the
> issue that the control messages are sent broadcast, the data will be
> sent unicast. There's the well-known "grey zone" problem here that is
> usually solved with link quality (when using OLSRv1 with hop counts).
> It may well be that in practice things work, but there is an issue
> here that I think needs discussion.

Normally the IP packet loss of the broadcast messages seems to be higher 
than the IP packet loss of unicasts because of the retransmissions.

OLSR.org had a "link quality" implementation (as defined in RFC 3626) 
even before the ETX code, but the link quality didn't helped to 
stabilize the network.

> Section 5
>
> The use of packet sequence numbers relies on an erratum to RFC 5444.
> Do we assume everyone reads errata, or should this be commented on?

That was the reason why I explicitly stated what kind of packet sequence 
number this draft needs. Maybe we could mention that this requirement 
was also added in the errata.

> There's a metric normalisation issue for OLSRv2 (this divided by that

The "scaling" of this ETT metric has been chosen to be useful with WIFI 
(802.11) speed.

> Section 6
>
> ETT_HELLO_TIMEOUT_FACTOR - If this is what I think this is (I have
> used something similar in link quality calculations) then it should
> be only slightly larger than 1.0, which is worth saying.

But not too small, otherwise a message aggregation timer might become a 
problem.

> Section 7
>
> Here reading through I made a note thatr INTERVAL_TIME TLVs are
> optional. This is discussed later. But I think a section earlier on
> this may be appropriate. That section could also discuss entity
> relationships I'll get to below.

The order of "things to consider" is a bit off...

> entities with different responsibilities, and controlled ways in
> which they may interoperate. This has required some care at times. I
> don't think this draft has put the same care in.
>
> demultiplexer), NHDP and OLSRv2. So for example OLSRv2 does not put
> in a packet sequence number. OLSRv2 requests the 5444 multiplexer to
> add a packet sequence number. Likewise how OLSRv2 interacts with
> HELLO messages needs care, see OLSRv2 draft for how LINK_METRIC and
> MPR TLVs are handled.

(I have implemented this similarly in my OLSRv2 code)

> But this is more complicated than that. Because we are considering
> haps in packet sequence numbers, that means all packets need to be
> considered.

Yes.

 > That could include packets containing neither HELLO
> messages nor TC messages, which normally neither NHDP nor OLSRv2 will
> see. (They get reported their messages, and can access related packet
> information.) This is therefore in part a function interacting
> directly with the 5444 multiplexer,

Yes.

 > which is new, and we (WG, if this
> is adopted) should be clear on how to handle that - or someone (in
> the IESG if not sooner) will ask many difficult questions.

I think we should handle this in a similar way than any extension that 
adds/reads packet level TLVs.

 > Related to
> that is whether this extends NHDP, but is used by an extension to

Thats a bit tricky... metrics are defined in OLSRv2 but are an extension 
for NHDP... and metrics can be useful in NHDP even without using OLSRv2.

> processed, that's not quite right  in terms of the 5444/NHDP/OLSRv2
> model, as discussed above. Also not clear from this wording that you
> just mean for purpose of metric calculation.

"MUST NOT be process for metric calculation as described below" ?

> (missing PSN or INTERVAL_T IMETLV). You still need a metric if the
> Link Tuple is on an OLSRv2 interface, obviously maximum, but that's
> only said in the processing, not in the can't process part.

Easiest way would be to ignore the whole Hello timer. The problem is 
that the metric would not increase if contact to the neighbor is 
suddenly lost.

> produce a value in the range 1 to MAXIMUM_METRIC? (I don't have time
> right now to check that).

At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 
Mbit/s, ETX 16).

 > Even if it does, needs comment about
> rounding/truncating to a representable value (note that L_in_metric
> must be representable, it's in the OLSRv2 constraints this is bound
> by).

I do this already in code, but maybe its worth adding to the draft that 
the metric should be set to the nearest metric value that can be 
represented in the compressed format defined in OLSRv2.

> general that that., and to separate what's specific to that and what
> isn't. We need to be able to understand that if, for example, I want
> to use this on a system that varies between say 1 kbit/s and 256
> kbit/s, what other parameters change?

If we change the parameters to extend the metric range to MINIMUM_METRIC 
to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit/s.

> Suggest referencing the NHDP/OLSRv2 integrity draft.

I will do so.

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: Henning Rogge <[email-masked]>
Date: Mon, 22 Jul 2013 11:08:57 +0200

On 07/16/2013 06:56 PM, Justin Dean wrote:
> I've also had a little bit of time to look over the draft. My comments
> at this point are more general than Chris' were. I found the draft
> overly confusing. The was an ok summary of what the metric is supposed
> to do, but the it jumps right into details.

Do you think we need a chapter that describes the ETT metric in more 
abstract terms as a step between the introduction and the metric 
calculation description?

 > Without a good idea of how
> things are supposed to work the variable descriptions just add to the
> confusion.  I don't think it needs to be this complicated, in fact I
> find it worrisome that I wasn't able to more easily figure out how I
> would start implementing it. I'll provide more detailed feedback and
> possible text when I can find some cycles.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 22 Jul 2013 11:14:52 +0200

>    - I like the idea of specifying the ETT metrics and I hope you will

We definitely will. Expect a new revision in the week after the IETF 
meeting.

> mentioning the Funkfeuer networks only in the appendix.

Maybe a "history" appendix that explains where the ETX part of the 
metric comes from?

 > I also wonder

Good question, I am not sure about this but I am open for advise.

Yes.

> introduction and abstract.

I wrote the link tuple extension as a way to have "link specific" data 
stored for the metric. Do you think it would be better to put this into 
a database described in this draft?

 > I assume that an informational document
> could also not do that.

I don't consider packet sequence numbers as a different layer. Its a 
different interface to the rfc5444 (de)multiplexer, but its still in the 
same layer.

We use IP addresses from the IP header in NHDP/OLSRv2 without worrying 
about "lower layer access" too.

> wonder if that could not be more separated.

Hmm.

>   - some lower case "must" in section 9; should that be 2119 or not?

Will have to look at this.

> How is the metric used in the OLSRv2 network?

Not sure if we want to allocate metric TLV extensions for specific 
metric types.

> references in an Informational document?

I thought only RFCs can be a normative reference, but my knowledge about 
rfc types and references types in them is a bit limited.

Henning Rogge

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 22 Jul 2013 13:29:04 +0100

Our experience with link quality differs. It's not the loss rate, it's that maximum broadcast range is greater than unicast range (lower data rate). So need to exclude links whose SNR suggests too long or poor. And this improved performance (provided sufficiently dense network).

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

On 22 Jul 2013, at 10:07, Henning Rogge <[email-masked]> wrote:

> I think we will have to work more on Section 1/3, maybe pushing the whole "OLSr.org history" part to a section of its own so we can focus more on OLSRv2 section 1/3?
> 
> Normally the IP packet loss of the broadcast messages seems to be higher than the IP packet loss of unicasts because of the retransmissions.
> 
> OLSR.org had a "link quality" implementation (as defined in RFC 3626) even before the ETX code, but the link quality didn't helped to stabilize the network.
> 
>> Section 5
>> 
> That was the reason why I explicitly stated what kind of packet sequence number this draft needs. Maybe we could mention that this requirement was also added in the errata.
> 
> The "scaling" of this ETT metric has been chosen to be useful with WIFI (802.11) speed.
> 
>> Section 6
>> 
> But not too small, otherwise a message aggregation timer might become a problem.
> 
>> Section 7
>> 
> I think we should handle this in a similar way than any extension that adds/reads packet level TLVs.
> 
> > Related to
> Thats a bit tricky... metrics are defined in OLSRv2 but are an extension for NHDP... and metrics can be useful in NHDP even without using OLSRv2.
> 
>> Section 9.2
>> 
> Easiest way would be to ignore the whole Hello timer. The problem is that the metric would not increase if contact to the neighbor is suddenly lost.
> 
>> Section 11
>> 
> At the moment the range I use is 2^4 (256+ MBit/s, ETX 1.0) to 2^16 (1 Mbit/s, ETX 16).
> 
> I do this already in code, but maybe its worth adding to the draft that the metric should be set to the nearest metric value that can be represented in the compressed format defined in OLSRv2.
> 
>> Section 12
>> 
> If we change the parameters to extend the metric range to MINIMUM_METRIC to MAXIMUM_METRIC, we could transport a linkspeed from 16 bit/s to 4 Gbit/s.
> 
>> Section 14
>>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 22 Jul 2013 07:58:39 -0700

Henning,

thanks for your reply. See below:

> We definitely will. Expect a new revision in the week after the IETF

Good!

> Maybe a "history" appendix that explains where the ETX part of the metric
> comes from?

Yes, that would be a good idea IMO.

> Good question, I am not sure about this but I am open for advise.

Let's discuss that during the IETF.

> stored for the metric. Do you think it would be better to put this into a
> database described in this draft?

After a second thought, I actually think it's fine not to "update" the
OLSRv2 spec, since this is an optional extension, and so the
information sets in OLSRv2 remain unchanged for implementations not
using the ETT extension.

> We use IP addresses from the IP header in NHDP/OLSRv2 without worrying about
> "lower layer access" too.

I agree that there is some ambiguity. I think such a (short)
requirements section could be helpful for implementers to make sure
that they can get appropriate information from other layers. But if
you think this is self-evident, I am fine if you leave it as is.

> Not sure if we want to allocate metric TLV extensions for specific metric
> types.

I thought that this is the purpose of the registry. Let's discuss that
during the IETF.

> I thought only RFCs can be a normative reference, but my knowledge about rfc
> types and references types in them is a bit limited.

Yes, but OLSRv2 needs to be a normative reference for the ETT draft.
In case this draft is completed before OLSRv2 becomes an RFC (which I
hope not!), then it will be hold in the RFC editor queue until OLSRv2
gets the RFC number.
Here is some info about the reference types:
http://www.ietf.org/iesg/statement/normative-informative.html

Best regards
Ulrich

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 22 Jul 2013 15:34:05 +0000

FWIW, I agree with Chris. The difference in the range for broadcast/multicast vs. unicast is important, as well as the disparity in the data rates for those traffic types. 

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Mon, 22 Jul 2013 17:43:46 +0200

I did a little bit searching how the Community Mesh networks handle
this. One common option used is to increase the multicast rate to 5.5
or 6 MBit/s.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan