Subject: [manet] Fwd: New Version Notification for draft-rogge-baccelli-olsrv2-ett-metric-04.txt

From: Henning Rogge <[email-masked]>
Date: Fri, 14 Feb 2014 14:27:57 +0100

A new version of I-D, draft-rogge-baccelli-olsrv2-ett-metric-04.txt
has been successfully submitted by Henning Rogge and posted to the
IETF repository.

Name:		draft-rogge-baccelli-olsrv2-ett-metric
Revision:	04
Title:		Packet Sequence Number based directional airtime metric for OLSRv2
Document date:	2014-02-14
Group:		Individual Submission
Pages:		16
URL:
http://www.ietf.org/internet-drafts/draft-rogge-baccelli-olsrv2-ett-metric-04.txt
Status:
https://datatracker.ietf.org/doc/draft-rogge-baccelli-olsrv2-ett-metric/
Htmlized:
http://tools.ietf.org/html/draft-rogge-baccelli-olsrv2-ett-metric-04
Diff:
http://www.ietf.org/rfcdiff?url2=draft-rogge-baccelli-olsrv2-ett-metric-04

Abstract:
   This document specifies an directional airtime link metric for usage
   in OLSRv2.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
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: Thomas Clausen <[email-masked]>
Date: Mon, 17 Feb 2014 13:45:14 +0100

Thank you for that, Henning....I worried if this important work was withering since the previous I-D had expired - I am glad that it hadn't, and that you request a slot to present in London. In case the WG chairs need signs of support in order to grant that slot, then here's a sign from me that it's important.

I've quickly read through the I-D over the weekend, and while a detailed review will follow (brace yourself ;) - no seriously, I found just a few nits)  I was wondering about one big-picture item: I know that you have quite some operational experience with OLSR networks, and that in those you are not using hop-count metrics ;) Is this the precise metric that you are using? Or, to put it in another way, is there any operational experience with this metric? Appendix A kinda-sorta leads me to believe that this I-D documents a slight deviation from what you've actually been using in your deployments, but that may be an incorrect interpretation.

Another big-picture question that I have is the status of this document, I am not sure if "Informational" is quite right; it might be "Experimental", also, or something else? What makes me wonder about this is that it kinda-sorta imposes behavior (thou shalt have a packet sequence number....) on an implementation that reaches beyond just "internal processing". I note that this is not a problem with this I-D as such, this is just an artefact of IETF processes....

Now, a naïve question from a WG participant to the WG chairs and the authors of this I-D: I guess that we all agree that hop-count is not really an appropriate metric for most MANETs, so why is this document not a working group document yet?

Best,

Thomas

On 14 Feb 2014, at 14:27, Henning Rogge <[email-masked]> wrote:

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 13:22:41 +0000

I need to read the latest draft. One comment I'll make to put it on the record is that multitopology recommends increasing the pool of administratively defined metric types from 1 to something larger (I'd like to see at least 8) and it would be silly for those to be other than a continuous block (from 0). So when we come to make a request for specific metric types, we need to ensure that isn't broken. 

-- 
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 Thomas Clausen
Sent: 17 February 2014 12:45
To: Henning Rogge; [email-masked]; Ulrich Herberg
Cc: [email-masked]
Subject: Re: [manet] New Version Notification for draft-rogge-baccelli-olsrv2-ett-metric-04.txt

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

Best,

Thomas

On 14 Feb 2014, at 14:27, Henning Rogge <[email-masked]> wrote:

> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> --
> Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, 
> Germany

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Mon, 17 Feb 2014 16:21:10 +0100

> Thank you for that, Henning....I worried if this important work was withering since the previous I-D had expired - I am glad that it hadn't, and that you request a slot to present in London. In cas…

I am looking forward to London.

> I've quickly read through the I-D over the weekend, and while a detailed review will follow (brace yourself ;) - no seriously, I found just a few nits)

Looking forward to more feedback.

> I was wondering about one big-picture item: I know that you have quite some operational experience with OLSR networks, and that in those you are not using hop-count metrics ;) Is this the precise metric that you are using?

No.

OLSR.org RFC 3626 extension uses ETX and cannot change it without
breaking the compatibility to old nodes.

> Or, to put it in another way, is there any operational experience with this metric?

I have implemented it for my OLSRv2 code and we have used it in our
testbed, but unfortunately thats a quite limited test.

The implementation uses slightly different limits for ETX and
upper/lower datarate, but I have yet to hear a WG opinion what these
values should be.

> Appendix A kinda-sorta leads me to believe that this I-D documents a slight deviation from what you've actually been using in your deployments, but that may be an incorrect interpretation.

Unfortunately I am yet to hear about a community mesh network that
tried to deploy OLSRv2.

> Another big-picture question that I have is the status of this document, I am not sure if "Informational" is quite right; it might be "Experimental", also, or something else? What makes me wonder a…

As I said during the IETF in Berlin I am not sure what "status" this
document should be... most likely "experimental".

"informal" was the easiest solution for the private draft until the WG
decides what to do with this document.

> Now, a naïve question from a WG participant to the WG chairs and the authors of this I-D: I guess that we all agree that hop-count is not really an appropriate metric for most MANETs, so why is thi…

I think we can/should talk about this in London.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 17 Feb 2014 16:22:57 +0100

> I need to read the latest draft. One comment I'll make to put it on the record is that multitopology recommends increasing the pool of administratively defined metric types from 1 to something larg…

This metric does not have any kind of requirements for the other side
of a link, so it doesn't really need any fixed metric extension
codepoint.

I can totally see this metrics being used in one of the metric code
points used  for multi-topology routing.

Most times you will just run it as metric "0" in a non-MT mesh.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 17 Feb 2014 15:50:50 +0000

At experimental, sure (or use private/experimental space). If it gets beyond experimental, then an allocation (with caveats noted) would probably be called for.

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 17 February 2014 15:23
To: Dearlove, Christopher (UK)
Cc: [email-masked]; [email-masked]; Thomas Clausen
Subject: Re: [manet] New Version Notification for draft-rogge-baccelli-olsrv2-ett-metric-04.txt

> I need to read the latest draft. One comment I'll make to put it on the record is that multitopology recommends increasing the pool of administratively defined metric types from 1 to something larg…

This metric does not have any kind of requirements for the other side of a link, so it doesn't really need any fixed metric extension codepoint.

I can totally see this metrics being used in one of the metric code points used  for multi-topology routing.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 18 Feb 2014 10:20:57 -0800

Henning,

thank you for updating the draft. I am in favor of adopting it by the WG.
Experimental is likely the best status for it. The draft certainly needs
some editorial work, but I like the way it is structured, as well as the
general idea. Whether to allocate of a code point needs to be discussed.

Best regards
Ulrich

On Mon, Feb 17, 2014 at 4:45 AM, Thomas Clausen <[email-masked]>wrote:

> [...]
>
> Now, a naïve question from a WG participant to the WG chairs and the
> authors of this I-D: I guess that we all agree that hop-count is not really
> an appropriate metric for most MANETs, so why is this document not a
> working group document yet?
>
>

---

From: Jiazi YI <[email-masked]>
Date: Tue, 18 Feb 2014 23:03:32 +0100

I think this draft is interesting and looking forward to more
discussions/work on it.

One general question:

In the draft, the term "mesh network" is used. No "ad hoc" or MANET is
mentioned.
Although there are various definitions of "mesh network", it's generally
regarded as (physically) static network. Does it mean that this metric is
more used for such kind of community mesh network, not for "Mobile" ad hoc
network? (Of course, this brings what's "mobile" for MANET - I mean moving
routers here). Or it is just we don't have experience on this point yet?

best

Jiazi

On Mon, Feb 17, 2014 at 4:21 PM, Henning Rogge <[email-masked]> wrote:

> > Thank you for that, Henning....I worried if this important work was
> withering since the previous I-D had expired - I am glad that it hadn't,
> and that you request a slot to present in London. In case the WG chairs
> need signs of support in order to grant that slot, then here's a sign from
> me that it's important.
>
> > I've quickly read through the I-D over the weekend, and while a detailed
> review will follow (brace yourself ;) - no seriously, I found just a few
> nits)
>
> > I was wondering about one big-picture item: I know that you have quite
> some operational experience with OLSR networks, and that in those you are
> not using hop-count metrics ;) Is this the precise metric that you are
> using?
>
> No.
>
> > Appendix A kinda-sorta leads me to believe that this I-D documents a
> slight deviation from what you've actually been using in your deployments,
> but that may be an incorrect interpretation.
>
> > Another big-picture question that I have is the status of this document,
> I am not sure if "Informational" is quite right; it might be
> "Experimental", also, or something else? What makes me wonder about this is
> that it kinda-sorta imposes behavior (thou shalt have a packet sequence
> number....) on an implementation that reaches beyond just "internal
> processing". I note that this is not a problem with this I-D as such, this
> is just an artefact of IETF processes....
>

---

From: Henning Rogge <[email-masked]>
Date: Wed, 19 Feb 2014 08:11:59 +0100

> In the draft, the term "mesh network" is used. No "ad hoc" or MANET is

I personally use "mesh network" and "ad hoc" network with the same
meaning, I can easily change them in the next draft version.

> regarded as (physically) static network. Does it mean that this metric
> is more used for such kind of community mesh network, not for "Mobile"
> ad hoc network? (Of course, this brings what's "mobile" for MANET - I
> mean moving routers here). Or it is just we don't have experience on
> this point yet?

I think this depends on what kind of source you use to determine the
packet loss on the link. If you use the "averaged control traffic loss"
method, the metric will need time to converge so you might be forced to
decrease the Hello intervals (and maybe TC intervals) to make the metric
useful for mobile networks.

The Olsr.org ETX metric (which uses the same mechanism to determine
directional link loss) has been mostly used static network. But I
personally know of at least half a dozen experiments where it also have
been used in small but mobile networks, just not on the scale as the
community mesh networks.

I have yet to test the metric described in the draft in a mobile network.

Henning Rogge

---

From: Teco Boot <[email-masked]>
Date: Wed, 19 Feb 2014 08:02:20 +0100

Op 18 feb. 2014, om 23:03 heeft Jiazi YI <[email-masked]> het volgende geschreven:

> I think this draft is interesting and looking forward to more discussions/work on it. 
> 
> One general question:
> 
> In the draft, the term "mesh network" is used. No "ad hoc" or MANET is mentioned. 
> Although there are various definitions of "mesh network", it's generally regarded as (physically) static network. Does it mean that this metric is more used for such kind of community mesh network, not for "Mobile" ad hoc network? (Of course, this brings what's "mobile" for MANET - I mean moving routers here). Or it is just we don't have experience on this point yet?

Good question. 
Henning and I had discussions on using RSSI, or not (faster convergence, less accurate).

I’m not sure it is mentioned in the draft already that data rate selection depends on unicast (user) traffic. That is why probing is needed. And attention for links that are not part of the SPF topology.

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 19 Feb 2014 13:28:48 +0100

On Wed, Feb 19, 2014 at 8:02 AM, Teco Boot <[email-masked]> wrote:
> I'm not sure it is mentioned in the draft already that data rate selection depends on unicast (user) traffic. That is why probing is needed. And attention for links that are not part of the SPF topology.

At least the Linux "Minstrel" rate selection depends on unicast
traffic. In fact my implementation also contains a probing part, that
sends unicasts over links that had none since the last probing.

Henning Rogge

---

From: Jiazi YI <[email-masked]>
Date: Wed, 19 Feb 2014 14:37:23 +0100

Hi,

> meaning, I can easily change them in the next draft version.

Thanks. It's better to keep the terminology consistent. Because in some
context, mesh network is slightly different from manet.

> I have yet to test the metric described in the draft in a mobile network.

As the draft would be in experimental track, it's totally OK.
I think we can put some text in the applicability statement. It's also
appropriate (in my opinion, encouraged) to describe those experimental
points, so people implementing the draft can pay attention to those
aspects, and provide feedback.

best

Jiazi

---

From: Henning Rogge <[email-masked]>
Date: Wed, 19 Feb 2014 14:38:57 +0100

On Wed, Feb 19, 2014 at 2:37 PM, Jiazi YI <[email-masked]> wrote:
> points, so people implementing the draft can pay attention to those aspects,
> and provide feedback.

I will keep that in mind for the next revision.

Henning Rogge