Subject: [manet] IETF mailing List - draft-ramrekha-manet-chameleon-00.txt (manet routing)

From: "Tipu A. Ramrekha" <[email-masked]>
Date: Wed, 24 Feb 2010 23:10:28 +0100 (GMT+01:00)

Dear all,

We have submitted a personal I-D :

Filename: draft-ramrekha-manet-chameleon-00.txt 
Link:  http://www.ietf.org/id/draft-ramrekha-manet-cml-00.txt

We feel that it should be considered as a MANET WG I-D. We have discussed this matter with the working group chairs and they are happy to ignite a discussion about our protocol in this WG.

The ChaMeLeon (CML) routing protocol is a hybrid and adaptive solution which combines functionalities of both AODV and OLSR RFCs. Therefore, we think this protocol could be treated as an extension to the aforementioned RFCs or as a stand-alone solution.

The CML routing protocol will be used for Ad Hoc Extreme Emergency Communications as part of the project PEACE (www.ict-peace.eu) which is funded by the European 7th Framework Programme (FP7). 

Kind regards

Arvind.

Tipu Arvind Ramrekha
PhD Research Student
Wireless & Multimedia Networking (WMN) Research Group
Faculty of Computing, Information Systems & Mathematics
Kingston University London
Mobile Information and Network Technologies (MINT) Laboratory
Room SB 128
Sopwith Building
Penrhyn Road
Kingston upon Thames
KT1 2EE
Tel: +44 (0)20 84177025
www.kingston.ac.uk/cism

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 25 Feb 2010 11:25:51 -0000

Subject to that the existing work in the WG must always
take priority, discussions on future directions are always
of interest - though we must also be careful to avoid the
WG returning to the "bad old days". I presume that any
comments from the WG chairs are aligned with this, I'm
pretty sure they won't have supported making this a WG ID
at this time.

I do not support this work becoming a WG ID for several
reasons
- It's not chartered.
- It's based on the first generation MANET WG RFCs (AODV
  and OLSR) not the current work (DYMO and OLSRv2).
- It's not the only approach to a hybrid protocol, and
  a WG ID should represent a consensus on any such
  approach.

However, based on a quick reading, I would note

- The assumption is that the whole network should be
  reactive or proactive. I don't agree with this. It
  is the reason for the whole oscilliatory problem.
  The unit should be smaller than the whole network,
  possibly down to individual nodes, and the two forms
  of behaviour need to coexist. In fact even with the
  approach suggested, either they need to coexist for
  a short while, or there will be outages due to
  transitioning. The latter is unacceptable, so if
  you can achieve the former, why make it only
  transitional?

- The concept of "proactive below N nodes, reactive
  above" is, I believe, flawed, even given a later
  comment that ties the threshold to an operational
  area size - because node density is critical also.
  But also important are traffic patterns, mobility, and
  how the proactive and reactive protocols are used. Let
  me, for example, note that OLSRv2 has mechanisms for
  periodic message backoff and "fisheye" style message
  flooding. Even if things were as simple as going
  reactive in large networks, use, or not, of these
  would affect the threshold.

- Also note that I'm obviously an author of a proactive
  protocol, and I've pointed out why how far you can
  push a proactive protocol is an issue. But the
  "reactive only in large networks" is something I
  would expect someone supporting reactive protocols
  to disagree with, and rightly. There are other reasons
  for preferring one or the other, also relating to
  issues of traffic patterns, and preferred user
  behaviour with regard to transmissions - for security
  reasons as well as power consumption reasons. (There
  are also different security reasons to prefer proactive
  protocols.) Note that this is consistent with wanting
  to make decisions at a lower level than the network as
  a whole.

- If we were to open the whole subject up, there are
  alternative approaches to hybrid networks, for example
  (anything but an exhaustive list) ZRP (proactive local,
  reactive remote), what's being done in IEEE 802.11s,
  and possibilities of a more close integration of DYMO
  and OLSRv2 (helped by the use of RFC 5444). I would note
  that in the latter case there are some non-obvious
  pitfalls to avoid.

However to finish on a positive note, I know there are
many WG members with an interest in protocol convergence,
hybridization, etc. and it's an interesting topic to
consider, and the sooner we can get to where it could be
a WG item (whether it does or not) the happier I'd be.

-- 
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 Tipu A. Ramrekha
Sent: 24 February 2010 22:10
To: [email-masked]
Cc: g; c; e
Subject: [manet] IETF mailing List -
draft-ramrekha-manet-chameleon-00.txt (manet routing)

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

Dear all,

We feel that it should be considered as a MANET WG I-D. We have
discussed this matter with the working group chairs and they are happy
to ignite a discussion about our protocol in this WG.

The ChaMeLeon (CML) routing protocol is a hybrid and adaptive solution
which combines functionalities of both AODV and OLSR RFCs. Therefore, we
think this protocol could be treated as an extension to the
aforementioned RFCs or as a stand-alone solution.

The CML routing protocol will be used for Ad Hoc Extreme Emergency
Communications as part of the project PEACE (www.ict-peace.eu) which is
funded by the European 7th Framework Programme (FP7). 

Kind regards

Arvind.

Tipu Arvind Ramrekha
PhD Research Student

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

********************************************************************
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: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 25 Feb 2010 17:21:47 +0000

Dear all

Thank you for taking some time to read our draft and providing us with some very interesting feedback. Please do consider our thoughts below:

>>>I presume that any

The chairs were happy for us to discuss the contents of this draft in the mailing list and were open to use the whole or part of the proposed ideas if interesting as a contribution towards the WG.
Again, the draft should not be regarded as a new start but it proposes a solution based on the latest protocol RFCs available on the WG.

>>>.....discussions on future directions are always
of interest - though we must also be careful to avoid the
WG returning to the "bad old days".

I Agree

reasons

>>- It's not chartered.

It has been regularly discussed within the ICT PEACE consortium. We also have simulation results that confirm better performances that will be published very soon.

We believe that ChaMeLeon  (CML) routing protocol has the right basis to be regarded as a realistic solution for extreme emergency communications and if modified for General purpose MANETs.
The current protocols in the WG do not realistically consider constraints imposed when deploying MANET routing protocols in real life. An emergency MANET would be exposed to constraints such as obstacles, varying network size, different levels of mobility etc. None of the proposed protocol explicitly proposes a solution for these.

Current implementations of OLSR protocol  based on the RFCs which has been tested in our labs do not operate appropriately when exposed to these situational constraints.

We are very closely monitoring the development of DYMO and OLSRv2 and have even carried out simulations based on DYMO-UM. However, the current state of these documents are I-Ds and we could not build our protocol based on I-Ds because of their informal status.

It is important to note however that we are more than happy to adapt our ideas to these two I-Ds (DYMO and OLSRv2) if required by the WG. We want to be constructive towards the aim of the WG which needs to

"standardize IP routing
protocol functionality suitable for wireless routing application within
both static and dynamic topologies with increased dynamics due to node
motion or other factors."

Here we would like to emphasize on the fact that we need to also focus on node mobility levels (changing) and other factors (related to real life deployment such as battery life and user QoS requirements). The Adaptive Module proposed will surely help towards that objective.

We will please request all to discuss this matter on the mailing list.
We also want to request the WG chairs to Discuss this draft at the IETF 77 meeting where I would like to formally present this draft for discussion.

We strongly believe that it contains elements that are necessary to reach the aim set by the WG that we are missing currently in the current tracks.

>> The assumption is that the whole network should be

Due to battery limitations and delays imposed by excessive exchange of routing messages. That is the main objective of the CML protocol. We aim at providing a protocol that behaves according to the context of the situation so that we can use it in real life Emergency scenarios. In the emergency scenarios, the requirements/constraints are that we have limited battery and require to provide a proper level of QoS for multimedia communication. These can be achieved by using the most efficient routing behavior for a particular MANET state. If we use both this could create even more overhead than previous pure approaches.

I agree. But this only a first draft and as mentioned in the draft we are working on other metrics such as mobility and traffic that would affect such a threshold. The whole concept of an Adaptive module is to adapt to the requirements of the user subject to the constraints of the network. To provide optimal routing services for all requirements and constraints is NP-Complete and thus there is a requirement to have a flexible structure which would allow the user to decide the priorities of the protocol. For us the users are Emergency workers in Disaster sites and scalability is a main concern. So we address this in the first place in the Adaptive module. However we are currently working towards extending this adaptivity.

It is not really that reactive protocols can only be used for larger networks. Instead its more towards an performance optimization point of view. Here we would agree that if we had several traffic connections each after the route timeout of reactive protocols, this would create unnecessary traffic in smaller networks as compared to proactive approaches. However, when we tend to larger networks, the ratio of routing overheads in such scenarios tend to favour the use of reactive protcol because they will provide fresher routes and will not have periodic control message exchanges. Thus saving energy and increasing QoS.

The ZRP protocol is very similar to CML but still it uses both approaches at a given time to first use OLSR to detect 2 hop neighbors and then again use AODV on top. It does not offer the same level of control routing packet minimization as CML. (As you rightly mentioned this optimisation is subject to the amount of traffic we send and the intervals at which we send them. In emergency situations we require regularly and lasting connections for unicast multimedia communications)

Thank you for the positive note. I hope we are both happy at the time this decision is made.

We are more interested towards a hybrid approach because of the options the different approaches provide in terms of providing an acceptable  QoS routing level for user requirements. But at the same time adapt to a very dynamic MANET environment to preserve limited resources so that it could be realistically deployed for our case Extreme Emergencies but also other everyday situations.

Thank you very much for considering our draft and to giving us your feedback. We would please request more comments/suggestions and discussions.

We would also like to request the chairs of the WG to book a slot in the IETF77 agenda to discuss matters related to this draft. If possible, I would also be very keen to make a presentation based on this draft at the meeting.

Kind Regards,

************************************************
Tipu Arvind Ramrekha
PhD Research Student

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Dearlove, Christopher (UK) [[email-masked]]
Sent: 25 February 2010 11:25
To: Tipu A. Ramrekha; [email-masked]
Cc: Millar, Grant P; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] IETF mailing List -        draft-ramrekha-manet-chameleon-00.txt (manet routing)

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

                    *** WARNING ***

Dear all,

Kind regards

Arvind.

Tipu Arvind Ramrekha
PhD Research Student

This email has been scanned for all viruses by the MessageLabs Email
Security System.

This email has been scanned for all viruses by the MessageLabs Email
Security System.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 25 Feb 2010 18:37:17 +0100

Am Donnerstag 25 Februar 2010 18:21:47 schrieb Ramrekha, Arvind:
> Dear all
> 
> Current implementations of OLSR protocol  based on the RFCs which has been
> tested in our labs do not operate appropriately when exposed to these
> situational constraints.
Running OLSR with a hopcount metric is nearly worthless. You have to use at 
least some routing metrics to get usable results, either for an advanced link 
hysteresis or for the topology routing itself.
 
> It is not really that reactive protocols can only be used for larger
> networks. Instead its more towards an performance optimization point of
> view. Here we would agree that if we had several traffic connections each
> after the route timeout of reactive protocols, this would create
> unnecessary traffic in smaller networks as compared to proactive
> approaches. However, when we tend to larger networks, the ratio of routing
> overheads in such scenarios tend to favour the use of reactive protcol
> because they will provide fresher routes and will not have periodic
> control message exchanges. Thus saving energy and increasing QoS.
We have run OLSR based messages (with an ETX metric) of 1000 nodes on embedded 
hardware and WLAN connections (and unfortunately without much optimizations).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 25 Feb 2010 17:43:47 -0000

reasons

> It has been regularly discussed within the ICT PEACE consortium.
> We also have simulation results that confirm better performances
> that will be published very soon.

> We believe that ChaMeLeon  (CML) routing protocol has the right
> basis to be regarded as a realistic solution for extreme emergency
> communications and if modified for General purpose MANETs.
> The current protocols in the WG do not realistically consider
> constraints imposed when deploying MANET routing protocols in
> real life. An emergency MANET would be exposed to constraints
> such as obstacles, varying network size, different levels of
> mobility etc. None of the proposed protocol explicitly proposes
> a solution for these.
>
> Current implementations of OLSR protocol  based on the RFCs which
> has been tested in our labs do not operate appropriately when
> exposed to these situational constraints.

None of which answers the point that it's not chartered.

(As for the points made, first we have exposed OLSR to some of
these issues, and in the field, not just in labs, so I can
disagree there. Second, even if that were so, it's not OLSR
that matters, its OLSRv2, which has some additional features.)

> We are very closely monitoring the development of DYMO and
> OLSRv2 and have even carried out simulations based on DYMO-UM.
> However, the current state of these documents are I-Ds and we
> could not build our protocol based on I-Ds because of their
> informal status.

That may be appropriate to your work, but I'm addressing the
issue of chartering the work, for which it is highly relevant.

> It is important to note however that we are more than happy
> to adapt our ideas to these two I-Ds (DYMO and OLSRv2) if
> required by the WG. We want to be constructive towards the
> aim of the WG which needs to
>
> "standardize IP routing
> Here we would like to emphasize on the fact that we need to also focus
> on node mobility levels (changing) and other factors (related to real
> life deployment such as battery life and user QoS requirements). The
> Adaptive Module proposed will surely help towards that objective.

No, the current objectives are being met by DYMO and OLSRv2. Trying to
start again is exactly the bad old days I mentioned, or worse.

>> a WG ID should represent a consensus on any such approach.

> We also want to request the WG chairs to Discuss this draft at the
IETF 77
> meeting where I would like to formally present this draft for
discussion.

If you mean, you want to raise it as an informational presentation,
that's one thing. But "formally" suggests you are looking to adopt
as a WG item, as you previously noted, and that is neither timely
nor appropriate.

> We strongly believe that it contains elements that are necessary
> to reach the aim set by the WG that we are missing currently in
> the current tracks.

And there I completely disagree.

I'm just going to anstract a couple more comments here.

> But this only a first draft

You want us to replace work that's been in development for
multiple years, for an untried first draft? That's not going
to happen. If you think it's even a possibility, you need to
understand more about the IETF process.

> the time this decision is made.

The relevant decisions were made several years ago.

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 25 Feb 2010 17:44:44 +0000

I agree that we can run OLSR in large networks in the same way we can run AODV in small networks. However, we are more concerned about the battery usage and QoS routing performances of such a strategy for real life usage such as extreme emergencies.

Thanks,
Arvind.

________________________________________
From: Henning Rogge [[email-masked]]
Sent: 25 February 2010 17:37
To: [email-masked]
Cc: Ramrekha, Arvind; Dearlove, Christopher (UK); Tipu A. Ramrekha; Millar, Grant P; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] IETF mailing List  -       draft-ramrekha-manet-chameleon-00.txt (manet routing)

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 25 Feb 2010 18:58:47 +0100

Am Donnerstag 25 Februar 2010 18:44:44 schrieb Ramrekha, Arvind:
> I agree that we can run OLSR in large networks in the same way we can run
> AODV in small networks. However, we are more concerned about the battery
> usage and QoS routing performances of such a strategy for real life usage
> such as extreme emergencies.
Do you have a working implementation I could download to look at the 
sourcecode ?

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 25 Feb 2010 20:26:05 +0000

Dear Henning Rogge,

If we are talking about the CML implementation we do have an implementation but it is not open source yet. We need the approval of the EC who owns the IPRs. This would be possible after summer.
However, we are going to have a live demo in Lisbon at the ICST Mobimedia conference (http://www.mobimedia.org/) and a Project Demo in Algarve Portugal in December. Please let us know if you are interested and we could email further details.

If we are talking about the OLSR implementation that we have used for our tests, this can be found at:
http://www.olsr.org/

Please let us know if you have other queries. 

---------------------------------------------------------
Tipu Arvind Ramrekha
PhD Research Student

________________________________________
From: Henning Rogge [[email-masked]]
Sent: 25 February 2010 17:58
To: Ramrekha, Arvind
Cc: [email-masked]; Dearlove, Christopher (UK); Tipu A. Ramrekha; Millar, Grant P; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] IETF mailing List  - draft-ramrekha-manet-chameleon-00.txt (manet routing)

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Thu, 25 Feb 2010 21:35:52 +0100

Am Donnerstag 25 Februar 2010 21:26:05 schrieb Ramrekha, Arvind:
> Dear Henning Rogge,
> 
> If we are talking about the CML implementation we do have an implementation
> but it is not open source yet. We need the approval of the EC who owns the
> IPRs. This would be possible after summer. However, we are going to have a
> live demo in Lisbon at the ICST Mobimedia conference
> (http://www.mobimedia.org/) and a Project Demo in Algarve Portugal in
> December. Please let us know if you are interested and we could email
> further details.
Both too far away, sorry. If you have the source under an OS licence (GPL or 
BSD) just tell me.

> If we are talking about the OLSR implementation that we have used for our
> tests, this can be found at: http://www.olsr.org/
I'm one of the core programmers of OLSR.org.
If you used it in hopcount mode I'm not surprised it didn't worked well. Your 
CML protocol will not work well without a good metric too.

(using hop count metric could be called "worst link first" for wireless 
networks)

I have read your draft and I have to say it's based on an OLSR version years 
old.
If you stay with this message format you will be in a similar hell than most 
other OLSR implementations trying to include a metric. The old binary message 
format of OLSR(v1) is not flexible and cannot be extended without breaking 
compatiblity.
Using MIDs is a mayor pain, it introduce lot's of timing dependencies and 
complicated merge problems when the wrong message got lost.

I'm not even sure this switching between AODV and OLSR will be an advantage. 
It creates a lot more complexity without much gain.

Henning Rogge

---

From: Joe Macker <[email-masked]>
Date: Thu, 25 Feb 2010 16:18:06 -0500

Yes, our rough direction is to recommend requests personal IDs and let the WG comment/review in any new areas being proposed.
There is no notion of considering this as WG tasking until we complete present charter items.  Integration of possible subaspects and extension ideas also require further distillation with some WG consensus. I think the present WG feedback is working to assess those prospects.

Arvind regarding presentation slots,etc. The chairs priorities are to concentrate mainly on presently chartered efforts and we have minimal meeting time so this is a factor. Once we collect the previously active charter items for discussion in Anaheim we will know better. Ian and I will track this as we get the agenda together by mid March,etc.  I want to emphasize this list is the core method to get broader exposure and discussion going with the needed bandwidth to discuss complex issues. I appreciated already with the amount of up front discussion and WG review as this is voluntary. The bandwidth during a 5-10 minute meeting slot is very limited vs. more detailed exchanges that can occur here.

Thanks to all parties involved.
-Joe

On Feb 25, 2010, at 12:21 PM, Ramrekha, Arvind wrote:

> Dear all
> 
> Thank you for taking some time to read our draft and providing us with some very interesting feedback. 

.....previous threads minimized.

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 25 Feb 2010 21:29:55 +0000

We agree that it is not chartered. But we would like to clarify some points:

1. The protocol we propose considers the requirements of emergency MANETs (eMANETs). The closest charter we have in IETF is the MANET WG which aims at standardizing an IP routing protocol for MANETs. However, we believe that a generic routing protocol will not be adequate for the purpose of eMANETs. So we propose ours to be considered for that case.   

2. We appreciate the well publicised advantages of OLSR and OLSRv2 should improve OLSR functionalities. OLSR is one of the, if the not the best, protocol for general purpose MANETs. 
However, if we are going to use these general MANETs in real life scenarios such as extreme scenarios, it will not be efficient because it does not consider the variable user QoS requirements and environmental constraints that are prevalent in such situations. We would like to therefore present CML as a routing solution for such MANETs.

3. We agree with the tracks defined by the WG. We also appreciate that the WG is moving towards fulfilling these specific approaches. However, we also believe that we can miss some important opportunities if we do not consider those offered by hybrid/adaptive approaches in parallel.

We want to contribute towards the MANET WG. We have thus made some findings which we believe could serve the work being carried out in the group. We based our work on recognized documents to build the protocol but now we are ready to update it to the chartering work which is an extension of the documents on which we based our previous work.

We are sorry but we do not agree on this is being starting again. We are building on top of AODV and OLSR and depending on the overall views of the mailing list members, we would like to upgrade it to OLSRv2 and DYMO usages for the benefit of work for this charter. We do not oppose the current tracks but we need to consider the broader applications of MANET as well. We have a definite candidate application in extreme emergency services that we need to cater for in parallel. We cannot have a static solution for such dynamic situations.

We want to make a presentation to present this draft which contains elements to make MANET routing more cognitive for certain highly dynamic environments. 

We do not intend to replace any work in the WG. We intend to contribute to it. We are building using the blocks provided after years of development. OLSRv2 and DYMO  could be these building blocks. We want to please have people in the WG consider constructively some of our propositions. Our intention is one of constructiveness and contribution. 

>>The relevant decisions were made several years ago.

We are just trying to propose new ideas based on current work in the WG and trying to provide findings from our own work in the view of contributing towards a MANET routing protocol that could use the reactive/proactive elected by the charter with extensions to suit it to emergency and other such applications.   

Kind regards,

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 25 Feb 2010 21:40:04 +0000

BSD) just tell me.

We are unfortunately bounded by the EC rules but we will duely inform the list about such a release.

>>If you used it in hopcount mode I'm not surprised it didn't worked well. Your
CML protocol will not work well without a good metric too. (using hop count metric could be called "worst link first" for wireless
networks)

We understand your point here and agree that hop count metric => worst link first. But we want to compare protocols with a like for like "setting".  

We are open for "upgrading" towards OLSRv2 and DYMO considering RFCs that has been published for packet formats and TTL considerations.

We will be publishing some mathematical and simulation based findings soon to highlight the benefits.

Kind regards,

Arvind Ramrekha.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 08:40:28 +0100

>(using hop count metric could be called "worst link first" for wireless

I introduced "Worst Path First Syndrome". It better reflects the 
_path_ selection. It is also a wink at "Shortest Path First", 
the Dijkstra algorithm.
http://tools.ietf.org/html/draft-boot-manet-nemo-analysis-01

I am worried on incompatible implementations on link metrics.
For example, DYMO uses 8 or 16-bit Distance (1 to 65535), 
dearlove-olsrv2-metrics suggests 8-bit exponential encoding
(16 to 1015808). When border router selection is added (like BRDP)
another metric encoding scheme is introduced.

My conclusion: link metrics is essential. And we should try hard
to define an uniform link / path metric. If we fail, It could be  
difficult to integrate OLSR and DYMO.

Regards, Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 09:07:31 +0100

> http://tools.ietf.org/html/draft-boot-manet-nemo-analysis-01
"Worst path first" sound good.
 
> difficult to integrate OLSR and DYMO.
I hope we will discuss the metric encoding and the default value here before 
we merge the metric draft into the OLSRv2 document.

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: Thomas Heide Clausen <[email-masked]>
Date: Fri, 26 Feb 2010 09:30:47 +0100

> "Worst path first" sound good.

On a related topic, Teco, have you considered the "worst path first  
syndrome" for those algorithms which use geographic information rather  
than topology-based information for relay selection / next-hop  
selection? My intuition (but, it remains an intuition only as I have  
not studied that in detail) is, that it would apply in an exacerbated  
fashion?

> we merge the metric draft into the OLSRv2 document.

Hum, I am not sure I agree 100% here. As I see it, the metric I-D  
"just" speaks of dimensionless values, and the exact encoding is  
really just a nit that can easily be discussed also later? IOW, yes,  
we should certainly take time to discuss, but I am not persuaded that  
it is something which should be allowed to delay progress on this topic?

Cheers,

Thomas

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 09:36:55 +0100

> it is something which should be allowed to delay progress on this topic?
The point I would like to talk about is the default value. The default value 
specifies the metric value for hopcount metric, at the moment it's just in the 
middle of the metric range. This is a bad idea, because there are not many 
reasons to have worse links than those choosen without a metric but lot's of 
reason to have better links. I would suggest moving the default value closer 
to the maximum, maybe to DEFAULT_METRIC/16. This allows for a better 
integration of hopcount metric with normal ones.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 26 Feb 2010 09:42:28 +0100

> integration of hopcount metric with normal ones.

Ok, I think I am inclined to defer to you on this matter, as your  
direct operational experience exceeds mine.

In other words, I do not have any strong feelings on this particular  
matter.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 10:35:31 +0100

Hi Thomas,

>not studied that in detail) is, that it would apply in an exacerbated

We considered using use geographic information for routing decisions.
After some thoughts how it should work, we decided it was of low
practical use, as in real world scenario's the RF propagation is 
highly influenced by "out-of-control" conditions, especially for land
based operation. Measuring signal quality like RSSI is much more useful.

Said that, using speed and direction could be useful, as "same speed 
& direction" would indicate: stable link.

The WPF syndrome is a name for the effect of hopcount based path selection,
where the outcome of SPF calculation selects those links that are at the 
utmost position in the grey zone. ETX helps / helps a lot, but is the 
"poor man solution". It shouldn't be difficult to use something better
like RSSI.
I prefer a 100% transparent protocol for for example lost message feedback
(ETX) and RSSI feedback. It is comparing apples, oranges and pears. Could 
be price, weight or other common metrics. Or a combination of those, 
used dimensionless.
As far as I understand, draft-funkfeuer-manet-olsrv2-etx-00 doesn't 
provide the transparency. Both ends on the link must implement the
R_etx TLV, otherwise ETX wouldn't work. Why not using dimensionless
like dearlove-olsrv2-metrics?

>it is something which should be allowed to delay progress on this topic?

Do you suggest DYMOv2 and OLSRv3? Or keep one of those at the current 
state? (which IMHO cannot be OLSRv2-LM)?
If it is really just a nit, I suggest: fix it today! :-)

Regards, Teco

PS.
DYMO and BRDP is distance-vector, where the path costs are incremented 
hop by hop. The obvious method is a linear metric. Link state protocols
do not have such restriction, signaling metric and calculating path costs
are separate mechanisms. Just a nit?

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 10:43:02 +0100

> like dearlove-olsrv2-metrics?

Wow ! First comment about our draft from last year... ^^

To calculate symmetric ETX you need the loss rate in both directions. You 
cannot calculate this would transmitting your own measured loss rate (the 
incoming loss rate) to the other side. There might be other metrics which 
don't need this.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 10:51:20 +0100

>In other words, I do not have any strong feelings on this particular

My results (depended on implementation!):
When a link comes up, and there is no metric for that link yet, the default
metric value would be used. With a low value default, it effects current 
flows over links with non-default, higher value metrics.
At the outer positions in the grey zone, flapping links occur, especially 
when the links are highly loaded with traffic. We should prevent this
problem.

I think the default metric is for implementations that don't support link 
metrics, and still be somewhat compatible.
Implementations that support link metrics should use high value metrics when

no measured metric information is available. Current ETX implementations
works like that.

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 11:00:31 +0100

>incoming loss rate) to the other side. There might be other metrics

I don't like the symmetric ETX calculation:
- Links are not symmetric.
- Bird-eye view: measuring for example RSSI and missed packets is 
  similar, and dimensionless feedback can be done.

I know it is difficult to change current ETX implementations.
But we can prevent the ETX lock-in in OLSRv2.

Regards, Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 11:04:46 +0100

>   similar, and dimensionless feedback can be done.
Doing it different would mean we could not compare it with the metric we have 
been running in the Freifunk/Funkfeuer mesh networks.

> I know it is difficult to change current ETX implementations.
I don't think so... but it would be a different metric. The draft is designed 
to be based on the Freifunk ETX-FF implementation, so we have operational 
experience for this metric.

> But we can prevent the ETX lock-in in OLSRv2.
This makes no sense.

The draft is just ONE example for a metric which works in the real world and 
has been running on multiple large networks used by people to get internet 
access.

It's not the only metric and I think anyone would be happy to see a few more 
metric drafts with tested real world metrics.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 10:23:23 -0000

I've been meaning, and still am meaning, to read the ETX draft
properly (I skimmed through an earlier version) but even this
message is stolen from trying to get a report out, so it is
unlikely to be before next week.

The fundamental design points in the OLSRv2 metrics draft are
- Dimensionless additive metrics - tractable to e.g. ensure no
  looping and that MPRs work.
- Using TLVs, obviously.
- A labelling system for those TLVs that leaves OLSRv2 not
  having to know what the meaning is, but allows something outside
  it to know, and ensures only compatible metrics are used (and
  has future extension possibilities for multi-topology routing).
- One-way (receiver selected) - this simplifies matters greatly.
  I agree with Teco here.
- A compressed floating point representation. I think this is
  a reasonable compromise between requirements. The number of
  mantissa/exponent bits (total eight) is not set in stone.

The choice of a default value is not a critical issue. However
it's worth considering what that default value is. It's the value
that can be sent over the air without costing an octet. It allows
hop count routing without bandwidth cost - but any value would do
this if not trying to mix with something else (dodgy).

Note that it is not (necessarily) the same as the value a node
first assigns as a metric to a link when first discovered. That's
an implementation issue. One could decide that making the default
value equal to an expected value of that is a good idea if that
value is sent often. But that value is not fixed, hence "expected"
in the last sentence. (When we roll this into OLSRv2 this point
needs to be stressed a bit more perhaps.)

As such I could see various options for a default value
- Minimum. Some networks with limited link information might run
  with most links minimum, a few set worse than that.
- Maximum. This might be the default for an unknown link, or one
  that using the link quality mechanism is poor, and thus be a
  commonly used value.
- In the middle of the range. Allows users to use half the range
  and treat as minimum or maximum, or use mosr of the range and
  leave it in the middle. As it's a floating point value, in the
  middle is naturally logarithmic, which is what is in the draft.

But as Thomas says, it's a minor detail, and can be discussed
either before or after rolling into OLSRv2 (which I hope we can
get to Real Soon Now - especially if NHDP's progress is good).
Changing it may be as little as changing one number on the draft
(well, probably two, coded and uncoded, and maybe a comment on
it).

With regard to ETX, again apologising for not reading the current
draft, the key question is can you define it, encode it, and use it
in this way (one-way, this encoding, additive). If the answer is
yes, the rest will follow.

-----Original Message-----
From: Teco Boot [mailto:[email-masked]] 
Sent: 26 February 2010 10:01
To: 'Henning Rogge'
Cc: 'Thomas Heide Clausen'; 'Millar, Grant P'; Dearlove, Christopher
(UK); [email-masked]; 'Tipu A. Ramrekha'; 'Panaousis, Emmanouil';
'Politis, Christos'
Subject: RE: [manet] IETF mailing List -
draft-ramrekha-manet-chameleon-00.txt (manet routing)

                    *** WARNING ***

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 11:27:41 +0100

Hi Henning,

Maybe you misunderstand my message.
I suggest freedom of metric types in a single network, for example
Freifunk. And provide some kind of interoperability between those
implementations. That is why we IETF work on standards. 

Remember I support using ETX as "default link metric measurement 
mechanism", but only when it is based on dimensionless metrics.

I don't mind having additional metric TLVs with dimensions, like RSSI,
SNR, SQ, ETX-NLQ, current-rate, max-rate etc. This requires support on
both ends of the link. Could perform better, at higher overhead and 
useful in special cases. This would be optional.

Regards, Teco

>-----Oorspronkelijk bericht-----
>Van: Henning Rogge [mailto:[email-masked]]
>Verzonden: vrijdag 26 februari 2010 11:05
>Aan: Teco Boot
>CC: 'Thomas Heide Clausen'; 'Millar, Grant P'; 'Dearlove, Christopher
>(UK)'; [email-masked]; 'Tipu A. Ramrekha'; 'Panaousis, Emmanouil';
>'Politis, Christos'
>Onderwerp: Re: [manet] IETF mailing List - draft-ramrekha-manet-
>chameleon-00.txt (manet routing)
>

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 11:36:45 +0100

> needs to be stressed a bit more perhaps.)
I agree to this, we can talk about the default when we push it into the OLSRv2 
draft. There is also the 
 
> yes, the rest will follow.
The etx-metric draft is based on your metric draft, so it use your encoding 
(it does not even specify the encoding itself) and creates an additive 
dimensionless value.

Because the metric I described is symmetric, the etx-metric draft use one 
additional TLV of it's own to communicate a linkquality-value between the two 
sides of the link. Both sides then generate one dimensionless metric value as 
your draft specifies.
 
Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 11:39:52 +0100

> implementations. That is why we IETF work on standards.
I hope we will get to this for the Freifunk implementation as soon as we move 
to OLSRv2. With the metric type we can even check if two nodes use the same 
metric or using even multiple metrics for multiple routing tables.

> mechanism", but only when it is based on dimensionless metrics.
Even the current Freifunk implementation use a dimensionless cost value for 
it's dijkstra algorithm. We are just stuck with a legacy encoding for it.
 
> useful in special cases. This would be optional.
Would be useful the generate multiple routing tables (each with a different 
type of metric) or combine them into a single dimensionless value for a 
combined metric.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 10:46:42 -0000

> sides of the link. Both sides then generate one dimensionless metric
value as 

This of course is part of the extensibility of OLSRv2, and
is fine, but note that:

- OLSRv2 won't understand this extra TLV - which I assume is in
  HELLO messages only - but that's fine. This however means that:

- You aren't just defining a metric, you are defining a protocol,
  an extension to OLSRv2. That means you need to write a draft
  as a protocol draft, not just as a metric definition and
  reservation.

I need to read what exactly is happening in order to work out
if comments I might make are sensible or not.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 26 Feb 2010 11:51:22 +0100

> if comments I might make are sensible or not.

Chris, I think you do want to read the etx document. It does a little  
more than just a registry assignment, as you correctly observe is  
required for making this particular mechanism work.

The upside is, that you are putting your finger on a couple of the  
issues which are needed, and which the etx I-D actually does do. This  
gives hope as to that I-D being on the right track - although, I am  
sure, there are things to improve (I have promised the authors a  
review, which I am getting to shortly).

Sincerely,

Thomas

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 10:55:25 -0000

> type of metric) or combine them into a single dimensionless value for
a 

The former (separate routing tables) is an obvious
extension to OLSRv2, and a major motivation for the
different types of metric coding. However we decided
not to put this into the basic OLSRv2 specification,
as we have to draw a line somewhere, but the basic
specification will be robust against it.

(Suppose we have metric types A and B, and three
groups of nodes. Group I is basic OLSRv2 and specified
to use metric A. Group II is basic OLSRv2 and specified
to use metric B. Group III is multi-topology OLSRv2 and
specified to use metrics A and B. Packets that - e.g.
by suitable DSCP value - are to use metric A should be
able to route through the group I/III nodes, and packets
using metric B should be able to route through the group
II/III nodes, in both cases using the right metric
between two group III nodes. The key is that group I
nodes, for example, will ignore addresses in messages
that don't have metric A values attached, or signalled
as default netric A values with a message TLV.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 10:57:07 -0000

> Chris, I think you do want to read the etx document

I know I do, and when I get the time ...

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 12:36:18 +0100

>   HELLO messages only - but that's fine. This however means that:
Yes, it's a HELLO only message TLV.

>   as a protocol draft, not just as a metric definition and
It might be a good idea to define an additional TLV inside the metric draft for 
"private data" necessary in the Hellos to calculate the metric. It could just 
use the same extension than the metric itself to identify which metrics 
private data it is. Communication between both sides of the link to calculate 
the metric could be necessary for more than this metric.
 
> if comments I might make are sensible or not.
Okay.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 11:45:35 -0000

> "private data" necessary in the Hellos to calculate the metric.

What metric draft? If you are referring to the one that will be
rolled into OLSRv2 then I strongly disagree. This is "mission
creep", adding something into a draft that it doesn't need, and
trying to get it right for a draft that will need it.

Better would be for the first draft that does need it (ETX) to
consider creating a general TLV, rather than an EXT specific TLV.
That still leaves the problem of getting it right in that draft.
But, worst case, ETX gets it wrong and another metric draft needs
to invent its own new thing. That's a pity, but not a deal-breaker.
But if it's wrong in the base OLSRv2 specification, that matters.
That isn't however an argument against ETX trying, there's a
difference between ETX needing it, and trying to get it general,
and OLSv2 not needing it and trying to invent it.

Of course that applies to everything in OLSRv2, get it wrong and
you're stuck with it. But we can minimise that by only including
what we need, not things we might need but don't need now. (Of
course it can be difficult sometimes to tell one from the other.)

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 12:56:24 +0100

On Fri February 26 2010 12:45:35 Dearlove, Christopher (UK) wrote:
> > It might be a good idea to define an additional TLV inside the metric
> 
> draft for
> 
That would work too. 

> and OLSv2 not needing it and trying to invent it.
Okay, I see your argument.

> course it can be difficult sometimes to tell one from the other.)
Doing this "private metric data" hello message TLV in a more generic way would 
be good in my oppinion, because other metric implementations might need a 
private TLV too. But we can put the registry into the ETX draft.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 15:30:27 +0100

Changed subject to link metric drafts.

On: draft-funkfeuer-manet-olsrv2-etx-00:
Why can't we just encode LQ in hello L_in_metric?

Link costs are A_metric in TC. And HELLO N_out_metric
and N_in_metric. I hope ETX doesn't change that.

On: draft-dearlove-olsrv2-metrics-04:
I still think the sending_router is the node responsible for
the link metric, not the receiving_router. The sending_router
advertise with A_metric in TC messages.
I know the receiving_router has more actual info on link quality.
But the receiving_router has not all information (e.g. willingness,
battery status and more important: retransmit statistics). Also
the sending_router could (should !!!) implement the dampening and 
hysteresis.
I don't like the idea someone else specifies what I should do.
You know that by now :-)

I suggest the sending_router is free to advertise whatever A_metric
for its links to neighbors. Same is send with sending_router HELLO 
N_out_metric. Receiving_router repeats this info with flooded TC and
/ or HELLO N_in_metric. 

Maybe the sending_router has a better multi-hop path to the neighbor,
and doesn't include the neighbor at all in its TC, because it is 
unused and therefore useless.

On both drafts:
Having ETX _only_ for L_in_metric, it can be used in parallel with
for example RSSI and data rate. L_in_metric would be a combination of
all available information. The computation is local and doesn't need 
to be standardized. Non-normative guidelines are fine.

Regards, Teco.

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 17:25:14 +0100

> and N_in_metric. I hope ETX doesn't change that.
Teco, the draft has the name "funkfeuer" in it because it's a draft about the 
metric we are using in the Freifunk/Funkfeuer networks. If I would do as you 
suggest you would transfer the ETX metric into two directional metric parts 
with different behaviour, so it would not be the FunkFeuer-metric anymore and 
we could not say we have experience about running it.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 26 Feb 2010 16:27:01 -0000

> advertise with A_metric in TC messages.

That just makes it responsible for advertising it, not for
generating it. Whoever advertises it, it's needed in messages
and as far as I can see, there's no bandwidth gain in the
sending router generating it.

> I know the receiving_router has more actual info on link quality.

Which is, as I see it, the critical detail.

> battery status and more important: retransmit statistics).

It has the willingness - which may very well be the battery status.
(There is a question outstanding incidentally about granuality of
willingness.)

Both ends of the link have some information about retransmissions,
and the receiver has FEC information and signal strength information,
which are important.

> Also

I'm not understanding this point.

> I don't like the idea someone else specifies what I should do.

OLSR is a cooperative protocol. Lots of stuff in it causes node A
to force node B to do stuff (the importance of MPR selectors means
that I require you to relay in particular). I don't see that as
something new.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 19:10:08 +0100

OK, I think it is good to have the current ETX implementation
described in an Internet Draft. But we are discussing a to be 
implemented OLSRv2 topic, and we can learn from what we have 
right now.
My two remarks are lessons learned, in my case also from
running olsr.org ETX code in a test environment:
a) ETX metric is symmetric, which is bad
b) Current implementation is blocking for enhancements, 
   for example use available better link metrics, e.g. RSSI.

Regards, Teco

>Van: Henning Rogge [mailto:[email-masked]]
>Verzonden: vrijdag 26 februari 2010 17:25
>Aan: [email-masked]
>CC: Teco Boot
>Onderwerp: Re: [manet] Link metric drafts
>

---

From: Marcello Caleffi <[email-masked]>
Date: Fri, 26 Feb 2010 19:17:02 +0100

>   for example use available better link metrics, e.g. RSSI.

or for example looking for better delivery ratios estimators for ETX, instead of adopting simple moving average or expexponentially weighted moving average

Marcello Caleffi

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Fri, 26 Feb 2010 18:22:35 +0000

Using the delivery ratio metric could be a better idea.

Arvind Ramrekha.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Marcello Caleffi [[email-masked]]
Sent: 26 February 2010 18:17
To: Teco Boot
Cc: [email-masked]
Subject: Re: [manet] Link metric drafts

Marcello Caleffi

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 26 Feb 2010 19:31:53 +0100

>(There is a question outstanding incidentally about granuality of

Maybe another flavor of willingness.
Maybe carrier utilization (which can be different at transmitter and 
receiver).
There could be more.

>and the receiver has FEC information and signal strength information,

Yes. For sure we need the feedback.
But typically, transmitter has more information on retransmissions.
More important, transmitter decides data rate, modulation, Tx power etc.

Some radios exchange link status with RTS/CTS. Then, both end has the Rx
information. It makes metric dependent on unicast traffic. But it helps
fast transfer of receiver measured metrics. I'm not sure on developments
in 802.11 for this.

>> the sending_router could (should !!!) implement the dampening and

My experience with link metrics without dampening and hysteresis aren't 
that good. Could be dependent in implementation, timers, scenario's etc.

Having such mechanisms at multiple places (radio driver, MANET protocol, 
multiple devices) makes things complex. I suggest sending all available
information to a single, well defined point. Here, the metric calculation
takes place, including dampening and hysteresis. Then, the signaling
protocol(s) to distribute the outcome.

>that I require you to relay in particular). I don't see that as

Not new at all. In routing protocols, nodes must forward routing messages.
And forward packets. But a router with metric support can decide to
increase a link metric, which would result in fewer packets to forward.
(I guess you respond with rat race scenario).

More important: let's face this one:

Assume S sends to D.

            3
S----->A---------B--------->D 
        \       /
       1 \     / 5
          \   /
            C

B decides C-->B metric reduces from 5 to 1
But C didn't hear this (hidden terminal & collision)

            3
S----->A---------B--------->D 
        \       /
       1 \     / 1
          \   /C still has 5
            C 

Now A sends via C, but C sends back to A.

For sure, sending_router advertised metrics doesn't prevent all loops.
But this one: I think so.

My intuition says: if a point of redirection, as result of topology 
change, is upstream, then there is a (high) risk of a routing loop.
Topology changes, started by a receiving node, would result in a 
less stable network. Hard to prove. Or deny. Volunteers? Get 
simulation results?

Regards,
Teco

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 22:05:18 +0100

> Using the delivery ratio metric could be a better idea.
I don't see your point...

lost packages + delivered packages = total number of packages

If you measure two of three, you get the last one "for free".

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 26 Feb 2010 22:08:08 +0100

> that good. Could be dependent in implementation, timers, scenario's etc.
Dampening/hysteresis could be written independant of the routing metric, just 
on the dimensionless values.
 
> protocol(s) to distribute the outcome.
I completely agree to this, dampening/hysteresis should be done before the 
linkcost value is flooded into the network.

Henning Rogge