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.

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 

Re: Default metric in OLSRv2

>
>
> What do you think ?
>
ACK!!

---
there's no place like 127.0.0.1

(üäö)

Re: Default metric in OLSRv2

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

Re: Default metric in OLSRv2

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.

-- 
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: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf
Of Dearlove, Christopher (UK)
Sent: 14 October 2009 09:32
To: Henning Rogge; manet <at> ietf.org
Subject: Re: [manet] Default metric in OLSRv2

                    *** WARNING ***

  This message has originated outside your organisation,

Re: Default metric in OLSRv2

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

Re: Default metric in OLSRv2

Am Mittwoch 14 Oktober 2009 10:32:26 schrieb Dearlove, Christopher (UK):
> 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.
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

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

Re: Default metric in OLSRv2

> 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

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.

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

Re: Default metric in OLSRv2

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

Default metric in OLSRv2

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

Re: Default metric in OLSRv2

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 manet <at> ietf.org 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
>> 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
>
> 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.
>
> ********************************************************************
> 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.
> ********************************************************************
>
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www.ietf.org/mailman/listinfo/manet