Subject: [manet] Default metric in OLSRv2

From: Henning Rogge <[email-masked]>
Date: Tue, 13 Oct 2009 17:41:29 +0200

Hello,

I know this mail comes a little bit early (metrics have not been merged into 
OLSRv2 draft), but I would like to like to argue for more than "include 
generic metric support in OLSRv2".

Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a 
conference about military communications. There were a couple of presentations 
which used OLSR as a mesh net protocol and they can be summarized as: "OLSR 
does not work well". When I tried to get some more facts about this I quickly 
recognized that all of them used hopcount metrics "because it's the default 
described in the RFC".

I think this was a mistake in the OLSRv1 RFC, it described a protocol that did 
not work very well in the real world because of hopcount metrics. No amount of 
great research for new metric or improved features have changed this later, 
because most people USING OLSR for their research will use the stuff described 
in the default RFC. We should not do the same mistake in the OLSRv2 RFC.

My suggestion is:
include a simple version of ETX as an example metric into the OLSRv2 RFC.

Why ETX ? Why not ETT/SNR/MIC/.... ?

ETX is not the best metric out there, it's a very basic one. But it's VERY 
easy to describe and implement, it's independant from the layer 1/2 below OLSR 
and it allows to build much better real world networks than hopcount. I know 
no other metric that can provide these three advantages.

We should add a few sentences into the chapter that this will be just the 
"lowest common metric" which should work with all OLSRv2 agents and that there 
are much better and more specialized metrics described in other documents and 
research papers. But if we do not put a real metric into the RFC we will have 
people saying "OLSRv2 does not work well" in years, just because they do their 
comparision based on the RFC implementation (hopcount).

If there is a consensus on this I can easily write description of a simple 
Hello-Message based ETX implementation with a single tuning parameter for the 
draft.

What do you think ?

Henning Rogge

---

From: "L. Aaron Kaplan" <[email-masked]>
Date: Tue, 13 Oct 2009 17:59:25 +0200

> What do you think ?
ACK!!

---
there's no place like 127.0.0.1

(üäö)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Oct 2009 09:32:26 +0100

I do not believe that a specific metric such as ETX should
be in the base OLSRv2 draft. As you say, the first question
would be "why ETX?". But not that the default will be a metric
whose meaning is implementation specific, not hop count (which
would be the default default so to speak if no one includes
any metric information). 

But that said, I would be delighted to see an Internet Draft
(which could be adopted and taken all the way to RFC in parallel
if that is the WG consensus) which described ETX, and maybe one
or two other, metrics and how to adopt them to the OLSRv2 metrics
TLV. This work could even start now referencing
draft-dearlove-olsrv2-metrics, to be updated to reference OLSRv2
when folded in to that. This would be valuable support for the
metric concept.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Rogge
Sent: 13 October 2009 16:41
To: [email-masked]
Subject: [manet] Default metric in OLSRv2

Hello,

I know this mail comes a little bit early (metrics have not been merged
into 
OLSRv2 draft), but I would like to like to argue for more than "include 
generic metric support in OLSRv2".

Two weeks ago (just before the OLSR Interop 2009 in Vienna) I visited a 
conference about military communications. There were a couple of
presentations 
which used OLSR as a mesh net protocol and they can be summarized as:
"OLSR 
does not work well". When I tried to get some more facts about this I
quickly 
recognized that all of them used hopcount metrics "because it's the
default 
described in the RFC".

I think this was a mistake in the OLSRv1 RFC, it described a protocol
that did 
not work very well in the real world because of hopcount metrics. No
amount of 
great research for new metric or improved features have changed this
later, 
because most people USING OLSR for their research will use the stuff
described 
in the default RFC. We should not do the same mistake in the OLSRv2 RFC.

My suggestion is:
include a simple version of ETX as an example metric into the OLSRv2
RFC.

ETX is not the best metric out there, it's a very basic one. But it's
VERY 
easy to describe and implement, it's independant from the layer 1/2
below OLSR 
and it allows to build much better real world networks than hopcount. I
know 
no other metric that can provide these three advantages.

We should add a few sentences into the chapter that this will be just
the 
"lowest common metric" which should work with all OLSRv2 agents and that
there 
are much better and more specialized metrics described in other
documents and 
research papers. But if we do not put a real metric into the RFC we will
have 
people saying "OLSRv2 does not work well" in years, just because they do
their 
comparision based on the RFC implementation (hopcount).

If there is a consensus on this I can easily write description of a
simple 
Hello-Message based ETX implementation with a single tuning parameter
for the 
draft.

What do you think ?

Henning Rogge

********************************************************************
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: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Oct 2009 09:35:55 +0100

In my third line below not should be note.

I also omitted to say that an initial draft on specific
metrics could provide more background (such as "why ETX"
and references to what's been done) than would be
appropriate in the main OLSRv2 specification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dearlove, Christopher (UK)
Sent: 14 October 2009 09:32
To: Henning Rogge; [email-masked]
Subject: Re: [manet] Default metric in OLSRv2

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

-----Original Message-----

Hello,

My suggestion is:

What do you think ?

Henning Rogge

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 14 Oct 2009 11:18:14 +0200

Hi Chris,
I guess that what Henning was saying is: it would be nice to have a simple
example of metric other than hop-count in the core doc. I also think it is a
good idea. It is also necessary to have a companion doc that will be more
exhaustive about metrics.

But I agree with Henning: it would be unfortunate that people implementing
the core spec may get the wrong impression about performance just because
the hop-count metric is used because no-one gives them the hint "see, you
can try other metrics too". As far as I'm concerned ETX is not a bad choice
for such an example.

I'm OK with other metrics too, as long as they are indeed simple to
implement and all-terrain (independant of lower layers).

Cheers,

Emmanuel

---

From: Henning Rogge <[email-masked]>
Date: Wed, 14 Oct 2009 11:43:08 +0200

> when folded in to that. This would be valuable support for the
I don't think this will work well for OLSRv2. Most people using OLSRv2 for 
research (instead of doing research on OLSRv2) will continue to use the "basic 
RFC implementation" of OLSR... if the basic RFC does only contain hopcount 
they will use hopcount "to have comparable results to other experiments". 
Which will give them "still does not work well".

I think we really need an appendix in the core document (similar to the 
appendix with an example MPR algorithm) that contains a simple metric 
algorithm. Without this "RFC conform OLSRv2" will still be nearly unusable.

We could use any kind of metric algorithm for this appendix, but ETX is the 
only one (I'm aware of) that is
a) independant of layer 1/2
b) easy to implement
c) creates working mesh networks

Hopcount does not provice c).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Oct 2009 10:48:04 +0100

> RFC implementation" of OLSR... if the basic RFC does only contain
hopcount

That is not the proposal. See what's written in the metrics draft.
(I agree what you indicate would not be acceptable. But that's why
that isn't it.)

The proposal is that the default is an additive metric of unspecified
"real world" meaning. But it's still a metric, and not just hopcount.
It's just not a specific ETC/delay/whatever metric. At least not
specified as such. In a given deployment if you agree in advance that
this is ETX, fine. But if you definitely want ETX then get an allocation
of one of the reserved metric code points specifically for that purpose
and use that.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Oct 2009 10:53:26 +0100

Can people please read the draft. Use of just hop count is NOT what
is in the proposal. You only get hop count if you don't even use the
metric TLV (so you get a default value, and all values default is - for
any metric - equivalent to hop count, just not one per hop).
 
And adding more to the base draft is not the way to go. (In fact in an
ideal world I'd go in exactly the opposite direction and break the base
draft into about three modular pieces.) A specific discussion of the
particular merits of specific metrics, and reservation of a code point
(group of TLV type extensions) is highly suited as a separate document.

 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Emmanuel Baccelli
Sent: 14 October 2009 10:18
To: [email-masked]
Subject: Re: [manet] Default metric in OLSRv2

                    *** WARNING ***

Hi Chris, 

I guess that what Henning was saying is: it would be nice to have a
simple example of metric other than hop-count in the core doc. I also
think it is a good idea. It is also necessary to have a companion doc
that will be more exhaustive about metrics. 

But I agree with Henning: it would be unfortunate that people
implementing the core spec may get the wrong impression about
performance just because the hop-count metric is used because no-one
gives them the hint "see, you can try other metrics too". As far as I'm
concerned ETX is not a bad choice for such an example. 

Cheers, 

Emmanuel

On Wed, Oct 14, 2009 at 10:35 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:

	
	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf

	                   *** WARNING ***

	
	or two other, metrics and how to adopt them to the OLSRv2
metrics

	
	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
Behalf
	Of Henning Rogge
	Sent: 13 October 2009 16:41
	To: [email-masked]
	Subject: [manet] Default metric in OLSRv2
	
	Hello,
	
	I know this mail comes a little bit early (metrics have not been
merged
	into
	OLSRv2 draft), but I would like to like to argue for more than
"include
	generic metric support in OLSRv2".
	
	Two weeks ago (just before the OLSR Interop 2009 in Vienna) I
visited a
	conference about military communications. There were a couple of
	presentations
	which used OLSR as a mesh net protocol and they can be
summarized as:
	"OLSR
	does not work well". When I tried to get some more facts about
this I
	quickly
	recognized that all of them used hopcount metrics "because it's
the
	default
	described in the RFC".
	
	I think this was a mistake in the OLSRv1 RFC, it described a
protocol
	that did
	not work very well in the real world because of hopcount
metrics. No
	amount of
	great research for new metric or improved features have changed
this
	later,
	because most people USING OLSR for their research will use the
stuff
	described
	in the default RFC. We should not do the same mistake in the
OLSRv2 RFC.
	
	My suggestion is:
	include a simple version of ETX as an example metric into the
OLSRv2
	RFC.

	ETX is not the best metric out there, it's a very basic one. But
it's
	VERY
	easy to describe and implement, it's independant from the layer
1/2
	below OLSR
	and it allows to build much better real world networks than
hopcount. I
	know
	no other metric that can provide these three advantages.
	
	We should add a few sentences into the chapter that this will be
just
	the
	"lowest common metric" which should work with all OLSRv2 agents
and that
	there
	are much better and more specialized metrics described in other
	documents and
	research papers. But if we do not put a real metric into the RFC
we will
	have
	people saying "OLSRv2 does not work well" in years, just because
they do
	their
	comparision based on the RFC implementation (hopcount).
	
	If there is a consensus on this I can easily write description
of a
	simple
	Hello-Message based ETX implementation with a single tuning
parameter
	for the
	draft.
	
	What do you think ?
	
	Henning Rogge

********************************************************************
	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: Thomas Heide Clausen <[email-masked]>
Date: Wed, 14 Oct 2009 12:24:40 +0200

All,

Can I make a couple of rush observations and a suggestion here,  
without taking side in this discussion just yet?

Observations:

	o	We agree that additive metrics should be in OLSRv2.

			=> 	They will be, we've got consensus on that,
				the metrics I-D contains that and it will be
				(I believe that I can safely engage all the authors)
				folded into the OLSRv2 specification as the WG
				has decided.

	o	ETX is a valuable example of a metric. There are existence
		proofs (plural) hereof from operational networks. It's hard
		to argue against that. It's also hard to argue that ETX is the
		be-all-end-all metric (but I think that nobody has suggested
		that either).

	o	Regardless of if ETX is to be included in the OLSRv2 spec
		or published as an independent spec (and I see and recognize
		arguments for and against both of these options), there's no
		current (IETF) specification of ETX. Consequently:

			=>	It's difficult for the WG to pronounce itself on the
				issue

			=>	There's no ETX-text to propose folding in to any
				specification, or to advance as a supplementary
				document (i.e. for the WG to adopt and to advance
				for publication).

Suggestion:

	o	Someone with experience in ETX and OLSR(v2) produce
		an individual I-D (short is good, shorter is better), and post
		to [email-masked] for further discussion.

Informally, as I know that Henning and Aaron have significant  
operational experience with ETX in OLSR(v2) networks, I'd think it  
interesting and a good idea if you were to produce such a document.  
I'd be happy [as OLSRv2 co-author] to help out, as will Emmanuel (he  
just confirmed this, as he's next to me) -- and I am sure that so will  
others.

I am sure that once a document exists, it will be a lot easier to  
understand what it is that we're discussing, what the right path for  
the content is etc.

Thoughts?

Thomas

On Oct 14, 2009, at 11:48 AM, Dearlove, Christopher (UK) wrote:

>> I don't think this will work well for OLSRv2. Most people using  
>> OLSRv2
> for

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 14 Oct 2009 11:33:21 +0100

I agree with almost all of Thomas's message (I might have one
small nitpick, but it's not important right now) and that
definitely includes the conclusion, that an ETX draft would 
be valuable - and actually not just in an OLSRv2 context.

-----Original Message-----
From: Thomas Heide Clausen [mailto:[email-masked]] 
Sent: 14 October 2009 11:25
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [manet] Default metric in OLSRv2

                    *** WARNING ***

All,

Observations:

			=> 	They will be, we've got consensus on
that,
				the metrics I-D contains that and it
will be
				(I believe that I can safely engage all
the authors)
				folded into the OLSRv2 specification as
the WG
				has decided.

	o	ETX is a valuable example of a metric. There are
existence
		proofs (plural) hereof from operational networks. It's
hard
		to argue against that. It's also hard to argue that ETX
is the
		be-all-end-all metric (but I think that nobody has
suggested
		that either).

	o	Regardless of if ETX is to be included in the OLSRv2
spec
		or published as an independent spec (and I see and
recognize
		arguments for and against both of these options),
there's no
		current (IETF) specification of ETX. Consequently:

			=>	It's difficult for the WG to pronounce
itself on the
				issue

			=>	There's no ETX-text to propose folding
in to any
				specification, or to advance as a
supplementary
				document (i.e. for the WG to adopt and
to advance
				for publication).

Suggestion:

	o	Someone with experience in ETX and OLSR(v2) produce
		an individual I-D (short is good, shorter is better),
and post
		to [email-masked] for further discussion.

Thoughts?

Thomas

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 14 Oct 2009 13:26:23 +0200

I also agree with Thomas' mail that it would be very helpful to have a draft
that describes the ETX metric, before continuing the discussion whether or
not to include it in the OLSRv2 draft. Henning and Aaron seem to be the
ideal candidates for writing such a draft, since they have running code (of
OLSRv1) that includes ETX metrics, and since they have the operational
experience of a big OLSR network.

Henning, Aaron, if you guys agree to write such a draft, I am also offering
to help out.

Ulrich

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 14 Oct 2009 13:31:22 +0200

I agree with Thomas: we need text to agree on ;) Let's do it!Emmanuel

On Wed, Oct 14, 2009 at 12:24 PM, Thomas Heide Clausen <
[email-masked]> wrote:

> All,
>
> Can I make a couple of rush observations and a suggestion here, without
> taking side in this discussion just yet?
>
> Observations:
>
> Informally, as I know that Henning and Aaron have significant operational
> experience with ETX in OLSR(v2) networks, I'd think it interesting and a
> good idea if you were to produce such a document. I'd be happy [as OLSRv2
> co-author] to help out, as will Emmanuel (he just confirmed this, as he's
> next to me) -- and I am sure that so will others.
>
> understand what it is that we're discussing, what the right path for the
> content is etc.
>
> Thoughts?
>
> Thomas
>
>
>
>  I don't think this will work well for OLSRv2. Most people using OLSRv2
>>>
>> for
>>
>>> research (instead of doing research on OLSRv2) will continue to use
>>>
>> the "basic
>>
>>> RFC implementation" of OLSR... if the basic RFC does only contain
>>>
>> hopcount
>>

---

From: sratliff <[email-masked]>
Date: Wed, 14 Oct 2009 13:44:35 -0400

RFC4938 makes an attempt to document a set of protocol independent metrics
for inclusion into route cost metrics. Perhaps this would be of interest to
the MANET WG?

Regards,
Stan

On 10/14/09 5:18 AM, "Emmanuel Baccelli" <[email-masked]> wrote:

> But I agree with Henning: it would be unfortunate that people implementing the
> core spec may get the wrong impression about performance just because the
> hop-count metric is used because no-one gives them the hint "see, you can try
> other metrics too". As far as I'm concerned ETX is not a bad choice for such
> an example. 
> 
> I'm OK with other metrics too, as long as they are indeed simple to implement
> and all-terrain (independant of lower layers).
> 
> Cheers, 
> 
> Emmanuel
> 
>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 14 Oct 2009 23:30:42 +0200

I support a strong recommendation for using link metrics in a MANET.

I think ETX is the poor men solution, which I would not recommend
for real networks.
But yes, ETX is not dependent of sub-IP layer information.
I've no objection against adding it in an appendix.

Reading dearlove-olsrv2-metrics-04, it is recommended that in a 
well-designed network, all routers will use the same physical
metric type. I agree on this, but I highly prefer an OLSR specification
that uses dimensionless metrics, in TC and Hello. This enables using
different physical metric types, without incompatibility. 
I'm not sure if this is fully supported in dearlove-olsrv2-metrics-04.
Using for example ETX and sub-IP layer information such as RFC4938 in
the same network and a need of transfer of data from receiver to sender
(e.g. RSSI, hello loss ratio etc.) could cause problems. Let's try to
avoid such problems.
My suggestion: When router A is the originator of a TC, it is 
responsible for the advertized metric for outbound, from A to whatever
neighbor. A's neighbors should send a helpful, dimensionless metric to A.
In addition, the neighbors may send metrics to A with dimensions, 
but MUST NOT rely on these metrics being used.

A reason for neighbors of A not sending a helpful, dimensionless metric 
to A is the awareness of A having the information already (e.g. the sub-IP
layer transfers such information already) or too much overhead.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 14 Oct 2009 23:49:04 +0200

Teco,

I believe that if you would read draft-dearlove-olsrv2-metrics, you  
would find that it provides exactly dimensionless metrics.

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Oct 2009 10:21:21 +0100

> that uses dimensionless metrics, in TC and Hello.

That is precisely what those metrics are.

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 16 Oct 2009 12:03:58 +0200

Hello, Henning,

I would add two points to the discussion which is interesting and important.

First point: there are many ways to have a MANET/OLSR not working  
well: bugs, badly tuned parameters. The main source of trouble is in  
general how neighbor sensing asserts the quality of a link in order to  
accept it or reject it, and I agree that using a metric will greatly  
help.

Anyhow RFC 3626 was not excluding the use of link quality in neighbor  
sensing, and was suggesting some. The hop count should not be problem  
as long as the links that are on the path are good links. In other  
words I would see the use of path quality as a minor improvement over  
the use link quality in neighbor sensing. Anyhow this would help  
traffic engineering.

Second point: adding a default link quality in OLSRv2 may be as  
complicated as inserting general metric in OLSv2, eg in MPR selection,  
so we might be careful if we hurry too much.

Anyhow I am looking forward a draft that describes the ETX metric that  
has got very good experimental records and personnaly I like the  
dimensionless metrics (we designed and experimented some with IEEE  
802.11/ OLSR cross layering).

Best regards

Henning Rogge <[email-masked]> a ?it :

> protocol that did
> they do their

-- 
Philippe Jacquet
Hipercom project team leader
INRIA
tel: +33 1 39 63 52 63
fax: +33 1 39 63 55 66

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 16 Oct 2009 12:23:47 +0200

> the use link quality in neighbor sensing. Anyhow this would help
I don't agree.

In practice it's very difficult to decide if a link is "good" or "bad" as a 
binary decission. Maybe the bad link is really important for another node, 
maybe it is not.

Link sensing and hysteresis, even with a local metric, is no replacement for a 
good additive routing metric used for the dijkstra algorithm in global 
routing.

> so we might be careful if we hurry too much.
If we put only hop count metric into the main document that's what most 
research projects will be using as a comparision. And you will hear things 
like "yes, AODV has lot's of delay for route creation, but OLSR has 30% packet 
loss".

It's more a matter of perception. People will use "Core RFC OLSR without 
extensions" and will get bad results from it.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Oct 2009 11:34:06 +0100

> routing.

Agreed. It is worth noting however that at least in some systems
(802.11) link sensing (hysteresis - when the word is properly used
- is just a detail there) makes the difference between a system
that doesn't work (due to the differences in 802.11 broadcast and
multicast) and one that works. Link metrics make the difference
between a system that works (for at least some uses) and one that
may work better.

> research projects will be using as a comparision.

Will you please read the metrics draft, and my postings here, which have
said, again and again, that this is NOT the proposal.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 16 Oct 2009 13:05:03 +0200

Am Fri October 16 2009 12:34:06 schrieb Dearlove, Christopher (UK):
> > Link sensing and hysteresis, even with a local metric, is no
>
> replacement for a
>
It might even make sense to use the calculated routing metric value for link 
sensing too (deciding if you include the link into your routing set).

(activating a new link if it's get better than ETX 8 and drop it completely if 
it goes beyond ETX 16 for example)

> > If we put only hop count metric into the main document that's what
> > most research projects will be using as a comparision.
>
The default value in your metric draft will still create a hopcount metric. 
And there is no other example for a working link metric inside the current 
metric draft.

So if we include the metric draft into the OLSRv2 draft, the default 
implementation will still be hopcount and there will be no other metric inside 
the OLSRv2 draft. We all know that the purpose of the draft is to say the 
people "use a good link metric"... but I fear there will be still a lot of 
researchers around that will use "default rfc olsrv2".

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Oct 2009 12:16:04 +0100

> The default value in your metric draft will still create a hopcount
metric.

Yes, that's the default value. But that is not using a hop count metric.

> And there is no other example for a working link metric inside the
current 

That's a separation of responsibility. While particular metrics
make motivation, it's putting too much into OLSRv2 to specify the
metric and how it is to be created. All of that is ideal for another
draft, which can discuss motivation, definition, IANA codepoints
(from the TLV defined) etc. I am hoping you will, with the various
people who have offered support, take up that task.

We may well reference, from the motivation part of the document,
something external (NOT the draft we're taling about below, that
creates a circular, possibly down, reference that is not appropriate)
to note the desirability of metrics. (The existing draft rather
glosses over that as preaching to the converted.) But this wants
to be about metrics in general, not (however suitable it may be
as a first choice) ETX or anything else.

> implementation will still be hopcount

NO. An implementation will not be compliant unless it implements
metrics, how to handle metrics in incoming messages. If it chooses
never to use that code it has implemented itself, there's really not
much one can do about that. But a pure hopcount implementation will
not be compliant.

Note that the default metric meaning will be up to local configuration.
But it will be there, and must be implemented.

> I fear there will be still a lot of 

They won't be doing that. If they don't implement metrics, they
won't have implemented the RFC.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 16 Oct 2009 13:31:50 +0200

All,

>won't have implemented the RFC.

It seems we all agree on recommending usage of link metrics.
This is great.

We can have endless discussions on what researchers will do.
But IETF has little influence here.
I think we shall focus on implementations for real users.
We define practical and interoperable protocols.

I'm looking forward to the updated OLSRv2 draft, which includes metrics.

Regards, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 16 Oct 2009 13:38:30 +0200

Hi,

On Fri, Oct 16, 2009 at 1:31 PM, Teco Boot <[email-masked]> wrote:

> [...]

I agree with Teco. Before continuing this discussion, I think it would be
very helpful to write an ETX metrics draft, then to integrate the metrics
draft into OLSRv2, and only *then* consider whether to explicitly mention a
metric other than hop-count in the OLSRv2 draft (e.g. in the appendix, as
suggested), or whether it's enough to set up the code points for different
metrics.

Ulrich

---

From: Philippe Jacquet <[email-masked]>
Date: Fri, 16 Oct 2009 14:00:49 +0200

> binary decission. Maybe the bad link is really important for another node,

Dear Henning,

we are in agreement, protocol solely based on link admissions control  
have basically two defaults:

1. either the link admission conditions are too loose and the network  
accepts links that are too instable for sustained data traffics
2. or the conditions are too tight and the network excludes too many  
links and  makes the graph disconnected.

What is difficult is to get experimental situations where you have  
both cases. I don't say it is impossible, but it is likely marginal,  
anyhow worthy enough to include path metrics in OLSR. Anyhow an  
additive path metric won't give the garantee that all links in the  
path are good enough, one may have one very bad link, hidden by the  
quality of the other links that are good enough to make the overall  
path optimal by Dijskstra.

There are no perfect specifications but one cannot say that all buggy  
situations necessarily come from the absence of good specifications.  
Some may come from a too strict application of the default values of  
the tuning parameters parameters proposed in the RFC.

I remember an experiment that concludes that OLSR between high speed  
cars was great to reduce overhead but led to too faulty links. I  
remember of another similar experiment that use much faster hellos  
between high speed cars, that lead to still very good overhead  
reduction and made link failure detection very good (good enough at  
least to open succesful TCP/IP connections between cars moving in  
opposite direction at 100 km/h). Notice that path metric won't help  
when bad or delayed estimate of link qualities are advertized.

A last point: one must be careful in defining default metrics if it  
requires some link layer notification that are not easy to implement.

I am looking forward the draft about ETX, it will be useful in  
improving the practice of use of metrics in OLSR.

Best regards,
Philippe

---

From: Henning Rogge <[email-masked]>
Date: Fri, 16 Oct 2009 14:51:54 +0200

Am Fri October 16 2009 14:00:49 schrieb Philippe Jacquet:
> > In practice it's very difficult to decide if a link is "good" or "bad" as
> > a binary decission. Maybe the bad link is really important for another
> > node, maybe it is not.
>
> Dear Henning,
>
I still disagree.

The problem with hopcount and local "filtering" of links is that hopcount 
still optimize to use the "worst" of your good links. Which might still not be 
a good idea.

> improving the practice of use of metrics in OLSR.
A good link hysteresis/filtering can enhance a path metric based OLSR network, 
thats true. But I think path metric is at least as important as link 
hysteresis.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Oct 2009 14:00:40 +0100

> thats true. But I think path metric is at least as important as link 

I think debating which is most important is not worthwhile.
Both pass the test of being useful enough to include, so
which is more useful doesn't really matter.