Subject: [manet] draft-ramrekha-manet-cml-00.txt

From: "Ramrekha, Arvind" <[email-masked]>
Date: Tue, 2 Mar 2010 12:09:25 +0000

Dear all,

We would like to thank you for your comments on the CML draft and would welcome extra comments and suggestions concerning this draft.

In addition, we would like to reiterate our intention to upgrade CML to integrate the OLSRv2 and DYMO protocols being currently discussed in the mailing list. The main concept in the draft is to have an Adaptive Module which will adapt routing mechanisms according to network constraints and traffic requirements.  

Concerning the point that our work is not chartered we want to emphasise that the MANET WG is most closely related to our work. Therefore we would preferably like the protocol to be considered by the WG but are also keen to integrate parts of the protocol to DYMO and/or OLSRv2. In addition, the European Commission would like international fora on the research being carried out in the FP and the IETF could greatly contribute towards this.

I would also like to please know whether there is any ns2 implementation of OLSRv2 or whether there is any implementation of latest drafts of either OLSRv2 or DYMO. 

Please do send us further suggestions and comments.    

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

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

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 2 Mar 2010 14:11:01 +0100

Dear Tipu Arvind Ramrekha,

I have read your draft, and I generally appreciate thinking about new
approaches that solve the scalability problems in MANETs. I have a few
comments to the draft:

1) As Chris mentioned correctly, we are not chartered right now for
this kind of activity. So I think that the draft should be kept as an
individual draft for now. We should concentrate on finishing the
chartered items of the WG. That said, there is nothing wrong with
thinking about extensions within this WG. There are other drafts with
a similar idea; Chris mentioned a few, I would also like to name HOLSR
(http://tools.ietf.org/html/draft-lacharite-manet-holsr-02).

2) The draft focuses on emergency scenarios. At least in its current
form, I don't see why there is any difference in assumptions to, e.g.
OLSRv2, which also accomodates a number of
different scenarios and could be used for emergency scenarios as well.
It encompasses a variety of features which allow to save energy and to
scale (fish-eye, dynamic message intervals).

3) I second Chris that I have doubts about your assumption: small
network -> OLSR and large network -> AODV. So even if you consider
additional values (e.g. density, mobility) for setting your threshold,
the general idea still remains the same, that at one point of time,
either OLSR or AODV is used. Do you have any proof that you increase
performance with respect to only using AODV or only using OLSR (with
otherwise same settings)? It would also be good to compare your
approach to other solutions, such as ZRP, CBRP, HOLSR, OLSR(v2) w.
fish-eye,...

4) You already announced to update the draft to using OLSRv2 and DYMO
instead of OLSR and AODV. This is certainly required before
considering this draft.

5) Assuming I have a threshold of 1000 routers in my network. What
happens if the MANET does not fluctuate around the threshold, but
rather stays always below X or always above X? Then you would use
permanently either OLSR or AODV. If my network grows to 2000 routers,
I would never again use OLSR. Of course, you could dynamically adapt
the threshold, but then it would be like saying: "before, 1000 routers
was too much for OLSR, now that I increased the threshold to 2000,
OLSR is suddenly fine with up to 2000 routers."

Ulrich

On Tue, Mar 2, 2010 at 1:09 PM, Ramrekha, Arvind
<[email-masked]> wrote:
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 2 Mar 2010 14:37:38 +0100

P.S. There are a number of OLSRv2 implementations out, but
unfortunately, not all of them are open source. Here a few I know
about (there are probably more... just a few I remember)

  1) JOLSRv2 -- This is my own implementation in Java, which can be
run in Ns2. However, it is not yet open source. We are trying to make
it public, but as our university is associated to the Ministry of
Defense in France, it is somehow difficult.
  2) nOLSRv2 -- an implementation by Niigata University. It is open
source, but I am not sure that they have updated to the latest
versions of the drafts, and I don't know whether they have an Ns2
version
  3) OLSRv2 by CRC in Canada (Yannick Lacharité)
  4) (to appear) NRL OLSRv2
  5) Hitachi OLSRv2 (closed source)
  6) (to appear) Funkfeuer OLSRv2
  7) BAE Systems OLSRv2 (closed source)

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Tue, 2 Mar 2010 13:56:03 +0000

Thanks Ulrich.

Arvind.
________________________________________
From: Ulrich Herberg [[email-masked]]
Sent: 02 March 2010 13:37
To: Ramrekha, Arvind
Cc: [email-masked]; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Tue, 2 Mar 2010 15:42:18 +0000

Dear Ulrich,

I think this is a fair point if you consider the draft strictly as an emergency specific routing protocol. However we do mention in our applicability section of the draft that the protocol can encompass general MANETs and thus the draft is covered by the charter under:
"If significant commonality between RMRP and PMRP protocol modules is observed, the WG may decide to go with a converged approach."

I believe multimedia benefits from the characteristics of CML (low delay/jitter), note Multimedia is now the main consumer of bandwidth on the internet, and we have no reason not to believe the same would happen on MANETs even if there is an internet gateway. In my opinion not considering this would be very short sighted.

We are currently finalizing some publicatons with mathematical models and simulation based results which demonstrate these. I would like to emphasize that we only consider the size of the network as the factor for switching between OLSR and AODV. We are also working on another version of CML which will adapt to the mobility of nodes. 

The idea here is to have a single routing protocol which is able to function in these changing environments and at the same provide a more efficient alternative than the exiting RFCs. We will provide proofs on these soon. Our publications will also include comparisons to ZRP. We will soon extend these comparisons as suggested to CBRP and HOLSR. 

However, we feel it will not be appropriate to compare an OLSR based protocol like current CML to OLSRv2. We will however upgrade CML to CMLv2 and do the comparisons. 

This draft focuses mostly on the Monitoring and Adaptive mechanisms that we would like to discuss. Of course we will updgrade to OLSRv2 and DYMO which have added functionalities.

Dynamic threshold allows the protocol to be adapted for certain characteristics, you can 'tune' the protocol for your needs, for example in a situation where you'd like to transmit voice over the network you'd need a network with very low delay and throughput is not as important, however in a networking with sharing of large files you'd want the opposite, the threshold and the switching mechanism can pick the best protocol for each scenario. Therefore, it is not saying "1000 routers is too much then but is OK now for OLSR" but it is more a matter of usage i.e. what are traffic requirements and whats the most efficient way of routing to satisfy such requirements.

We appreciate your comments and would invite more suggestions. We are particularly interested in finding the right way in which we could integrate our protocol or parts of our protocol to the WG efforts. This could be a part of OLSRv2, DYMO or Hybrid OLSRv2-DYMO.  
 
Regards

Arvind.

Sent: 02 March 2010 13:11

Ulrich

---

From: Henning Rogge <[email-masked]>
Date: Tue, 2 Mar 2010 16:50:16 +0100

Am Dienstag 02 März 2010 16:42:18 schrieb Ramrekha, Arvind:
> I believe multimedia benefits from the characteristics of CML (low
> delay/jitter), note Multimedia is now the main consumer of bandwidth on
> the internet, and we have no reason not to believe the same would happen
> on MANETs even if there is an internet gateway. In my opinion not
> considering this would be very short sighted.
What part of CML will give us this "low jitter/delay" part ? It's just 
(depending on the scenario) the best or worst of OLSR and AODV.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Tue, 2 Mar 2010 15:58:44 +0000

We should be able to sense these scenarios before we can decide which of the mechanisms would be best/worst. CML provides such cognition by monitoring the traffic requirements and network state. The decision to change AODV/OLSR will be made according to these information.

Arvind Ramrekha. 

________________________________________
From: Henning Rogge [[email-masked]]
Sent: 02 March 2010 15:50
To: [email-masked]
Cc: Ramrekha, Arvind; Ulrich Herberg; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 08:08:26 +0100

On Tue March 2 2010 16:58:44 Ramrekha, Arvind wrote:
> We should be able to sense these scenarios before we can decide which of
> the mechanisms would be best/worst. CML provides such cognition by
> monitoring the traffic requirements and network state. The decision to
> change AODV/OLSR will be made according to these information.
Maybe you should concentrate on documenting how to detect which routing 
behaviour is better. Switching between two different routing protocols is 
trivial, just use policy routing and two different routing daemons. No need to 
put everything into one protocol. This way the AODV part could even become the 
"backup" for the OLSR routes. If no OLSR route is available, just use the AODV 
routing.

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: Wed, 3 Mar 2010 10:06:25 -0000

> This way the AODV part could even become the 

That unfortunately is rather dangerous. If parts of the
network persistently use AODV and other persistently use
OLSR (consider for example that they are differently
configured) then one can get long-term loops.

I think (based on some unpublished work) one can do better
than that, but that's a whole new area.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 11:11:30 +0100

On Wed March 3 2010 11:06:25 Dearlove, Christopher (UK) wrote:
> > "backup" for the OLSR routes. If no OLSR route is available, just use
> 
> the AODV
> 
> > routing.
> 
I was thinking about using different IP ranges for both routing domains, so you 
don't mix them.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 3 Mar 2010 10:12:26 -0000

> Concerning the point that our work is not chartered
> we want to emphasise that the MANET WG is most closely
> related to our work.

Unfortunately that's not the issue. The MANET WG is the
most closely related to the work of hundreds, probably
thousands, of people. The question (well, the first
question, there are more) is the other way round - is
what you are offering (or that of the other people I
note) what the MANET WG wants/needs now.

> In addition, the European Commission would like international
> fora on the research being carried out in the FP and the IETF
> could greatly contribute towards this.

Again that isn't an issue that cuts much ice in the IETF,
which isn't an EU body.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 3 Mar 2010 10:21:13 -0000

> I was thinking about using different IP ranges for both
> routing domains, so you don't mix them.

I think this is an example of why there are many different
possibilities in the area of OLSRv2/DYMO (or other options)
interworking/convergence. Solutions such as the one you note
can be considered now, with little or no changes to the
protocols. More complicated solutions include whatever
CML were to be evolved into, the thoughts I have, and other
thoughts I know a number of the MANET WG participants have
at least considered, and maybe done more.

This would make a possible (I put it no more strongly than
that) avenue for work in the MANET WG after the currently
chartered work, but not right now. Right now personal drafts,
and whatever discussion goes with them, are the order of the
day - whether here or elsewhere is not my call.

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 10:46:23 +0000

Dear Henning Rogge,

>>>Maybe you should concentrate on documenting how to detect which routing behaviour is better. Switching between two different routing protocols is trivial, just use policy routing and two different routing daemons. No need to put everything into one protocol. This way the AODV part could even become the "backup" for the OLSR routes. If no OLSR route is available, just use the AODV routing.

We have emphasized on the parts of the protocol that are specific for CML:

Oscillation phase (augmented OLSR and AODV i.e. some added mechanisms to detect the )
Adaptive Module (Monitor and Adapt Functions)

But we will take your comment into account and focus more on the parts of the protocols that focuses on the how to detection of which routing behaviour is better for a particular condition based on the research outcomes. We will try to do this in our future drafts. Thank you.    

Kind regards

Arvind.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 03 March 2010 07:08
To: [email-masked]
Cc: Ramrekha, Arvind; Henning Rogge; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

On Tue March 2 2010 16:58:44 Ramrekha, Arvind wrote:
> We should be able to sense these scenarios before we can decide which 
> of the mechanisms would be best/worst. CML provides such cognition by 
Maybe you should concentrate on documenting how to detect which routing behaviour is better. Switching between two different routing protocols is trivial, just use policy routing and two different routing daemons. No need to put everything into one protocol. This way the AODV part could even become the "backup" for the OLSR routes. If no OLSR route is available, just use the AODV routing.

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: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 10:51:56 +0000

Dear Christopher Dearlove,

We agree that if an instance of segregated routing domains exists within the same group of nodes, there could be loops etc.

However, we specify in our draft that a Change Phase (CP) Packet MUST be used to alert other nodes of a change in routing. In this way, the network is synchronized within 2*Network_Traversal_Time of such a change in routing phase.

Regards,

Arvind. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
Sent: 03 March 2010 10:06
To: Henning Rogge; [email-masked]
Cc: Millar, Grant P; [email-masked]; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

the AODV

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 3 Mar 2010 11:04:56 -0000

Mine was a reply to Henning's concept, not yours.

-- 
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: Ramrekha, Arvind [mailto:[email-masked]] 
Sent: 03 March 2010 10:52
To: Dearlove, Christopher (UK); Henning Rogge; [email-masked]
Cc: Millar, Grant P; [email-masked]; Politis, Christos;
Panaousis, Emmanouil
Subject: RE: [manet] draft-ramrekha-manet-cml-00.txt

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

We agree that if an instance of segregated routing domains exists within
the same group of nodes, there could be loops etc.

However, we specify in our draft that a Change Phase (CP) Packet MUST be
used to alert other nodes of a change in routing. In this way, the
network is synchronized within 2*Network_Traversal_Time of such a change
in routing phase.

Regards,

Arvind. 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dearlove, Christopher (UK)
Sent: 03 March 2010 10:06
To: Henning Rogge; [email-masked]
Cc: Millar, Grant P; [email-masked]; Politis, Christos;
Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

the AODV

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 11:07:53 +0000

>>>I was thinking about using different IP ranges for both routing domains, so you don't mix them.

In our view, the current version of CML functions such that the whole network is synchronized. However, if we decide to sustain two different protocols within the same MANET for future versions, we could adopt such a solution. 

Another solution in such a scenario would be for the daemon to decide the routing algorithm to be used depending on the decision made by the node.    

Arvind Ramrekha.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: 03 March 2010 10:12
To: Dearlove, Christopher (UK)
Cc: Millar, Grant P; [email-masked]; [email-masked]; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

On Wed March 3 2010 11:06:25 Dearlove, Christopher (UK) wrote:
> > This way the AODV part could even become the "backup" for the OLSR 
> > routes. If no OLSR route is available, just use
> 
> the AODV
> 
> > routing.
> 
> That unfortunately is rather dangerous. If parts of the network 
> persistently use AODV and other persistently use OLSR (consider for 
> example that they are differently
> I think (based on some unpublished work) one can do better than that, 
> but that's a whole new area.
I was thinking about using different IP ranges for both routing domains, so you don't mix them.

Henning Rogge

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

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 11:19:38 +0000

We are trying to offer some ideas we believe is helpful towards the process of standardizing MANET routing protocol considering increased dynamics due to node activity as well as considering the traffic requirements we want to use it for. 

Regards

Arvind.

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 11:29:42 +0000

>>synchronizing the network nodes is very complicated. it should not be a building block in MANET
routing protocols. it introduced overhead and consumes battery IMO.

Maybe synchronization is not the right work in this case. We rather converge the network using a CP packet (mechanism similar to the TC message propagation). So it is rather a one way flood into the network (minimised with MPR if OLSR is running) to change routing mechanisms throughout the network. The time period for this one way flood should be a maximum of Network_Traversal_Time and not 2*Network_Traversal_Time as I wrongly mentioned earlier.

Regards

Arvind.

From: [email-masked] [mailto:[email-masked]]
Sent: 03 March 2010 11:05
To: Ramrekha, Arvind; [email-masked]; [email-masked]; [email-masked]
Cc: Millar, Grant P; [email-masked]; Politis, Christos; Panaousis, Emmanouil
Subject: RE: [manet] draft-ramrekha-manet-cml-00.txt

>However, we specify in our draft that a Change Phase (CP) Packet MUST be used to alert other nodes of a >change in routing. In this way, the network is synchronized within 2*Network_Traversal_Time of such a change >in routing phase.

synchronizing the network nodes is very complicated. it should not be a building block in MANET
routing protocols. it introduced overhead and consumes battery IMO.

Dan

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 3 Mar 2010 11:38:46 -0000

> We are trying to offer some ideas we believe is helpful
> towards the process of standardizing MANET routing protocol
> considering increased dynamics due to node activity as well
> as considering the traffic requirements we want to use it for. 

Unfortunately this work is neither sufficiently mature nor
sufficiently aligned with the WG charter to fit.

This isn't just me saying this, no one has supported it
becoming a WG item, and Joe Macker, the co-chair of this
group has said on this list

> There is no notion of considering this as WG tasking until
> we complete present charter items.

So there's no point trying to discuss this as wanting to
change the current work on DYMO and OLSRv2, that isn't going
to happen. If you want to take part in an interesting discussion
of this area (proactive/reactive interworking/convergence) then
you need to do so on the basis that it's personal drafts now and
possible future work items (which would start from what the
requirements are, and include other people's quite different
approaches to them, not just this). Continuing to suggest this
should modify current plans is just wasting everyone's time.

(Regarding the draft I don't think it's the right approach,
and I have some technical concerns that I need more time - which
is, as ever, in short supply - to think through. But until the
above point is accepted I'm not going to discuss the subject.)

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 11:58:45 +0000

We would like to please request some experimentation setup parameters for OLSRv2 and DYMO: 

1. Type of Traffic used 
2. Range of Network size in nodes
3. Area (Density of nodes)
4. Underlying MAC protocols.
5. Any publicly available results.

That would help us be more in line with any experimentations we carry out on our side. 

Thanks

Arvind.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 13:03:14 +0100

> That would help us be more in line with any experimentations we carry out
What kind of simulation software do you plan to use ? (I hope it's not NS-2 
with tworayground radio propagation).

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 13:43:28 +0000

We are actually experimenting using both ns2 and implementations (including NS-2 with tworayground radio propagation).

Following suggestions from the list we would like to use other simulation softwares. Also please elaborate on "NS-2 with tworayground radio propagation" if possible. Because we do use other propagation models in ns-2 as well.

Thanks

Arvind.  

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 03 March 2010 12:03
To: [email-masked]
Cc: Ramrekha, Arvind; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

> That would help us be more in line with any experimentations we carry 
What kind of simulation software do you plan to use ? (I hope it's not NS-2 with tworayground radio propagation).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 16:13:40 +0100

On Wed March 3 2010 14:43:28 Ramrekha, Arvind wrote:
> We are actually experimenting using both ns2 and implementations (including
> NS-2 with tworayground radio propagation).
> 
> Following suggestions from the list we would like to use other simulation
> softwares. Also please elaborate on "NS-2 with tworayground radio
> propagation" if possible. Because we do use other propagation models in
> ns-2 as well.
Tworay-Ground (as in NS2) has the problem that it does not contain smallscale 
fading. This means that you have a complex radio propagation model, but in the 
end it could be called "perfect layer 1 connectivity up to X meters, no 
connectivity beyond it". That is a horrible abstraction of radio propagation 
and will create simulation results that are not comparable to real meshs.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 15:57:17 +0000

We have also experimented with other propagation models in our ns2 simulations but we only intend to use ns2 (unfortunately) as an indicative numerical evaluation of our results based on our research.  

We also use a real-time testbed for the experimentations which we consider as more precise for real life scenarios.

We are open to use any other suggested software package. Any suggestions on these will put us more in line with the work undertaken here for OLSRv2 and DYMO?

Regards, 
Arvind.

______________________________________
From: Henning Rogge [[email-masked]]
Sent: 03 March 2010 15:13
To: Ramrekha, Arvind
Cc: [email-masked]; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Henning Rogge

---

From: <[email-masked]>
Date: Wed, 3 Mar 2010 11:05:29 -0000

Dan

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 18:52:46 +0100

Am Mittwoch 03 März 2010 16:57:17 schrieb Ramrekha, Arvind:
> We have also experimented with other propagation models in our ns2
> simulations but we only intend to use ns2 (unfortunately) as an indicative
> numerical evaluation of our results based on our research.
Did you use one with smallscale fading (which makes the quality of a link a 
little bit non-deterministic) ?
 
> as more precise for real life scenarios.
There is nothing like real tests... real physics beats all simulations.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Wed, 3 Mar 2010 18:53:51 +0000

>Did you use one with smallscale fading (which makes the quality of a link a little bit non-deterministic) ?

Do you think simulation based study is useful for performance comparison between routing algorithms i.e. every routing is on the same platform.  
 
>There is nothing like real tests... real physics beats all simulations.
I agree.

Regards

Arvind.
-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 03 March 2010 17:53
To: [email-masked]
Cc: Ramrekha, Arvind; Henning Rogge; Millar, Grant P; Politis, Christos; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Am Mittwoch 03 März 2010 16:57:17 schrieb Ramrekha, Arvind:
> simulations but we only intend to use ns2 (unfortunately) as an 
> indicative numerical evaluation of our results based on our research.
Did you use one with smallscale fading (which makes the quality of a link a little bit non-deterministic) ?
 
> We also use a real-time testbed for the experimentations which we 
> consider as more precise for real life scenarios.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Wed, 3 Mar 2010 20:08:38 +0100

Am Mittwoch 03 März 2010 19:53:51 schrieb Ramrekha, Arvind:
> Do you think simulation based study is useful for performance comparison
> between routing algorithms i.e. every routing is on the same platform.
Depends on the simulation. If your abstraction of the simulation (for example 
the radio propagation or the maclayer-model) is too far away from reality you 
will be comparing two things that will never happen.

Henning Rogge

---

From: Joe Macker <[email-masked]>
Date: Wed, 3 Mar 2010 17:39:44 -0500

There are some 3rd party ricean fading models (CMU,etc) that I've used in the past. with ns2 not sure if the exist for the latest releases.  Still not perfect but closer to reality. 

This can better exercise urban time-varying effects, nieghbor link metrics, etc.  Of course field test data is always useful for cross validation, comparisonetc

---

From: Henning Rogge <[email-masked]>
Date: Thu, 4 Mar 2010 08:25:31 +0100

On Wed March 3 2010 23:39:44 Joe Macker wrote:
> There are some 3rd party ricean fading models (CMU,etc) that I've used in
> the past. with ns2 not sure if the exist for the latest releases.  Still
> not perfect but closer to reality.
> 
> This can better exercise urban time-varying effects, nieghbor link metrics,
> etc.  Of course field test data is always useful for cross validation,
> comparisonetc
My question stays the same: do these models contain smallscale fading ?

If you plot "successfull transmission probability" vs. "distance" (should be 
simple to get the data with NS2), what kind of graph do you get ?

The (old?) tworay-ground model of NS2 results in a binary function. 100% up to 
a certain distance X, then 0%. I don't think this is a realistic abstraction 
for mesh networks.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 4 Mar 2010 10:33:10 +0000

I understand the point being made here. The tworay fading model is indeed unrealistic. However, CML did not really depend on these features to improve the performance of the pure protocols. We will try to consider the Rayleigh effect which can even enforce performance improvement in our case. And since it is a "bad habit" to use the tworay ground we will switch permanently to a more realistic propagation model as suggested. We did utilise the "ricean propagation model by Ratish J. Punnoose" and will focus more on this for IETF efforts. 

We will get back with more on this soon. We would mostly request more details about traffic type used and mobility parameters if possible for future dymo and olsv2 experimentations?   

Arvind.
________________________________________
From: Henning Rogge [[email-masked]]
Sent: 04 March 2010 07:25
To: Joe Macker
Cc: Ramrekha, Arvind; Millar, Grant P; Politis, Christos; [email-masked]; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Henning Rogge

---

From: Marcello Caleffi <[email-masked]>
Date: Thu, 4 Mar 2010 11:47:56 +0100

Il giorno 04/mar/2010, alle ore 11.33, Ramrekha, Arvind ha scritto:

> I understand the point being made here. The tworay fading model is indeed unrealistic.

The two-ray ground model does not account neither for slow or fast fading. In other words, it is not a "fading model". It simply accounts for the attenuation with respect to the distance and the nodes elevation.

> However, CML did not really depend on these features to improve the performance of the pure protocols.

Can you state your statement? I have some doubts about it, bat maybe it is due to my lack of knowledge about CML.

> We will try to consider the Rayleigh effect which can even enforce performance improvement in our case. And since it is a "bad habit" to use the tworay ground we will switch permanently to a more realistic propagation model as suggested. We did utilise the "ricean propagation model by Ratish J. Punnoose" and will focus more on this for IETF efforts. 
> 

Marcello

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 4 Mar 2010 11:39:22 +0000

>>Can you state your statement? I have some doubts about it, bat maybe it is due to my lack of knowledge about CML.

CML considers switching from OLSR to AODV based on Delay performance of the network. The link and physical layer properties affect such a performance but this effect is emphasized by the quantity and timing of routing packets. CML tries to optimize such control routing packet exchanges depending on the context of the network. Of course this could be extended to contexts such as link qualities.      

Arvind.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 4 Mar 2010 13:10:14 +0100

On Thu March 4 2010 11:33:10 Ramrekha, Arvind wrote:
> I understand the point being made here. The tworay fading model is indeed
> unrealistic. However, CML did not really depend on these features to
> improve the performance of the pure protocols.
I don't think so.

When you are using OLSR in a simulation with tworay-ground you get nearly 
useless results. Your net will have the wrong dynamic, routes will have 
different path lengths than in the real world and your packet loss will be much 
too low.

There is a reason why lot's of research has been done for routing metrics in 
the last years, without a good routing metric wireless mesh networks do not 
work. Even trivial sized networks (less than 20 nodes ?) behave badly with 
hopcount.

But if you simulate this with tworay-ground it will work... perfectly.

I hope you see the problem.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 4 Mar 2010 13:00:03 +0000

>From what I understand this will affect the MPR selection process and the network flooding for OLSR. 

>>>>But if you simulate this with tworay-ground it will work... perfectly.
For future experimentations we will avoid the tworay ground model of ns2 but part of our experiments did not use them anyway.

Regards,
Arvind. 

________________________________________
From: Henning Rogge [[email-masked]]
Sent: 04 March 2010 12:10
To: Ramrekha, Arvind
Cc: Joe Macker; Millar, Grant P; Politis, Christos; [email-masked]; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

I don't think so.

Henning Rogge

---

From: "Stephan Bohacek" <[email-masked]>
Date: Thu, 4 Mar 2010 09:10:24 -0500

I use Qulanet, so I'm not sure how NS models propagation and packet
reception. But generally, the two-ray model does not result in an on/off
channel where either the communication is perfect or communication is not
possible at all. Rather, there is a wide range of distances where the loss
probability is not zero and not one. When interference is included, the
channel is nothing like an on/off channel. If NS does not behave this way,
it is because of the radio model, not the propagation model.

Regarding fast fading, one needs to consider the radio and the environment.
Many radios use a wide bandwidth. One important reason to use wide bandwidth
is to "smooth out" fast fading. The degree to which fast fading is smoothed
out depends on the delay spread (bigger delay spread results in more
smoothing). Our 802.11 measurements indicate that large-scale fading is more
significant than fast-fading even at moderate displacements of a few meters
(that is, if you move an antenna a few meters, the change in signal strength
is more impacted by large-scale fading than by fast-fading). Nonetheless,
fast fading does have some impact. 

Thanks,

Stephan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Henning Rogge
Sent: Wednesday, March 03, 2010 10:14 AM
To: Ramrekha, Arvind
Cc: Millar, Grant P; Politis,Christos; [email-masked];
[email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

> propagation" if possible. Because we do use other propagation models in
Tworay-Ground (as in NS2) has the problem that it does not contain
smallscale 
fading. This means that you have a complex radio propagation model, but in
the 
end it could be called "perfect layer 1 connectivity up to X meters, no 
connectivity beyond it". That is a horrible abstraction of radio propagation

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Thu, 4 Mar 2010 14:15:33 +0000

Does anyone know if there is much difference in Qulanet and ns-2 propagation models? 
Do you have any public results that can show that  "large-scale fading is more significant than fast-fading even at moderate displacements of a few meters of the effects".?

Arvind.
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephan Bohacek [[email-masked]]
Sent: 04 March 2010 14:10
To: [email-masked]
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Thanks,

Stephan

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

Henning Rogge

---

From: "Rogge Henning" <[email-masked]>
Date: Thu, 4 Mar 2010 15:30:13 +0100

Are you sure this is the effect of the "propagation" model or the "fading"
model of Qual-Net ?
According to this file, there seems to be two independant configuration
parameters for Qual-Net.
http://www.cs.binghamton.edu/~vinkolar/qualnet/qualnet-tut1.pdf

The NS2-Tworay-Ground radio model is a tworay-ground without fading.

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

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Stephan Bohacek
Gesendet: Donnerstag, 4. März 2010 15:10
An: [email-masked]
Betreff: Re: [manet] draft-ramrekha-manet-cml-00.txt

Thanks,

Stephan

---

From: Marcello Caleffi <[email-masked]>
Date: Thu, 4 Mar 2010 15:40:28 +0100

Actually, is the opposite. The two ray ground is defined as a deterministic model (see Par 2.3.2 in [1]). Qualnet is not the Holy Book :), just a tool.

> fast fading does have some impact.

Also in this case, shadow fading is defined as the fading effects that changes slow with the distance (see 2.3.3.2 in [1]). Also if I did not any measurement on 802.11, it is hard for me to believe so. Do you have any published results about it?

[1] Pahlavan, K. and Krishnamurthy, P. 2001 Principles of Wireless Networks: a Unified Approach. 1st. Prentice Hall PTR.

Marcello

---

From: David Young <[email-masked]>
Date: Thu, 4 Mar 2010 14:40:48 -0600

> work. Even trivial sized networks (less than 20 nodes ?) behave badly with 

Twenty nodes?!  Hopcount will behave badly with only three nodes. :-)

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933

---

From: Henning Rogge <[email-masked]>
Date: Fri, 5 Mar 2010 07:50:56 +0100

> network flooding for OLSR.
It will also influence things like delay and jitter because you will get a 
different path length for routes with tworay-ground than in the real world. And 
of course it will influence packet loss.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Fri, 5 Mar 2010 10:01:23 +0000

>>>It will also influence things like delay and jitter because you will get a different path length for routes with tworay-ground than in the real world. And of course it will influence packet loss.

Thanks, I will focus future experimentations using ricean propagation models. Also do you use any specific mobility models and traffic types?

Arvind.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 05 March 2010 06:51
To: Ramrekha, Arvind
Cc: Joe Macker; Millar, Grant P; Politis, Christos; [email-masked]; [email-masked]; Panaousis, Emmanouil
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

> the network flooding for OLSR.
It will also influence things like delay and jitter because you will get a different path length for routes with tworay-ground than in the real world. And of course it will influence packet loss.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Fri, 5 Mar 2010 14:08:26 +0100

On Fri March 5 2010 11:01:23 Ramrekha, Arvind wrote:
> Thanks, I will focus future experimentations using ricean propagation
> models. Also do you use any specific mobility models and traffic types?
We don't use simulations at olsr.org (which is ONE olsr implementation). Even 
emulations can be hard to get realistic I think.

In real networks (outside trivial meshs) it is impossible to ignore that 
hopcount metric routing makes no sense. But it can be easily overlooked in 
simulations.

Henning Rogge

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Fri, 5 Mar 2010 13:31:52 +0000

We are experimenting  with testbeds as well. We will try to avoid hop count metric use and try to be more inline with the metrics being discussed here. Also I would like to know if there are any preferred application used to generate traffic and any mobility considered for real life experimentations. Thanks.

Arvind.

Sent: 05 March 2010 13:08

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 5 Mar 2010 14:58:51 +0100

Henning,

Just a note of attention: you base your assumptions on a certain link
layer (probably 802.11 - for which I agree hop count may not be the
best metric). This working group treats MANETs on layer 3, that is,
without a particular link layer in mind. You can very well use OLSR
over Ethernet, where hop count might not be that bad (I do not judge
whether that is actually a good idea...).

Hop count is a metric which is very easy to implement, and it does not
have any assumptions on the underlying L2 -- that is certainly the
reason why it is widely used. That said, it is clear that for certain
link layers (e.g. Wifi) we need better metrics. Which is where Chris'
metrics draft - hopefully sometime soon integrated into the OLSRv2
draft - can help us. Since it is very general and allows to include
arbitrary metrics, we do not restrain ourselves too much by selecting
per default any metric (such as ETX), which may require information
from lower layers or other specific assumptions that do not hold for
all link layers. I strongly support that the mentioned draft should be
integrated into OLSRv2, maybe with a word of warning that using
hop-count may lead to bad performance in certain scenarios and link
layers.

Talking about simulations: I agree with you that using simulations for
routing protocols can never replace real testbeds - and therefore it
is great that we can profit from "real-life" experience from community
networks such as Funkfeuer. However, they can allow -- together with
mathematical models -- to understand general ideas of protocols, as
well as to conclude upper/lower bounds, or to detect errors in the
design of the protocol. So, even when using the two-ray ground model
may lead to interesting results, depending on what you analyze.

Summarizing, I just wanted to express that life is sometimes a bit
more complicated than saying "hop-count does not work",
"fading-models are better than two-ray ground", or "random waypoint is
a bad mobility model". The answer is often: "it depends" (on what one
wants to find out by simulations). :-)

Ulrich

---

From: "Ramrekha, Arvind" <[email-masked]>
Date: Fri, 5 Mar 2010 14:08:54 +0000

Actually Ulrich has nicely summarized what we intend to use simulations for as compared to the purpose of us having real life implementations as well. But I suppose it is good practice to use models as similar to real real life as possible. Thats why we will FOCUS our simulations based on the suggestions.

Arvind.
________________________________________
From: Ulrich Herberg [[email-masked]]
Sent: 05 March 2010 13:58
To: Henning Rogge
Cc: Ramrekha, Arvind; Millar, Grant P; [email-masked]; [email-masked]; Panaousis, Emmanouil; Politis, Christos
Subject: Re: [manet] draft-ramrekha-manet-cml-00.txt

Henning,

Ulrich

---

From: Teco Boot <[email-masked]>
Date: Fri, 5 Mar 2010 17:14:21 +0100

Op 5 mrt 2010, om 14:58 heeft Ulrich Herberg het volgende geschreven:

> without a particular link layer in mind.

I don't get this. The worst path first syndrome caused by minimum hop 
count is not strictly related to 802.11. 

> You can very well use OLSR

OLSR in its current specification cannot be used on certain Ethernet 
topologies (and other l2 multi-hop technologies as well).
And there is the pseudo-broadcast issue.

> reason why it is widely used.

And bad results are widely available !!

> That said, it is clear that for certain
> all link layers.

ETX doesn't depend on lower layer information.
I've tested with data rate probing also, with pretty good results.
But only with low mobility (fast deployed networks).

> I strongly support that the mentioned draft should be

I say: recommend usage of metrics (a SHOULD).

> wants to find out by simulations). :-)

Yes. But our WG is not chartered for running simulations. We are chartered
for standardize IP routing protocols for MANETs, for real deployments.

Regards, Teco

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 5 Mar 2010 17:30:27 +0100

Teco,

On Fri, Mar 5, 2010 at 5:14 PM, Teco Boot <[email-masked]> wrote:
> [..]

I did not say that it is strictly related to 802.11. I just wanted to
remind that we are not _exclusively_ dealing with 802.11, but support
any kind of L2.

> topologies (and other l2 multi-hop technologies as well).

Can you explain that?

> And there is the pseudo-broadcast issue.

Which issue is that?

> And bad results are widely available !!

I agree with you. Many implementors only used hop-count as a metric in
OLSR, which may have led to wrong conclusions about the performance of
OLSR. That's why I strongly suggest to include the metrics draft into
OLSRv2.

> ETX doesn't depend on lower layer information.

True, what I meant was that we should not select a "default" metric
which has specific assumptions that do not always hold (or that depend
on other layers). Hop count does not make any such assumptions and is
very easy to implement. Of course, it will lead to bad performance in
many scenarios. So, most implementors should consider using a better
metrics, depending on their deployment.

> But only with low mobility (fast deployed networks).

Interesting! Are these results publicly available?

> I say: recommend usage of metrics (a SHOULD).

Yes, I agree. I am not so sure, however, that the OLSRv2 draft should
specify which metric to use per default.

> for standardize IP routing protocols for MANETs, for real deployments.

No doubt here :-)

Ulrich

---

From: Teco Boot <[email-masked]>
Date: Fri, 5 Mar 2010 18:46:36 +0100

>> topologies (and other l2 multi-hop technologies as well).

It is in the mail archive.
http://www.ietf.org/mail-archive/web/manet/current/msg11389.html

>> And there is the pseudo-broadcast issue.

http://www.ietf.org/mail-archive/web/manet/current/msg11389.html

> very easy to implement.

The problem is: hop count makes a wrong assumption.

> Of course, it will lead to bad performance in

No. Mostly because I need faster convergence. So I am more interested
in Rx feedback, e.g RSSI.

I tested Erik Tromp his olsrd plugin. I adjusted for better performance.
But the outcome was: this is not the best approach. But it worked in a MANET
with different radio systems, unaware of OLSR. The plugin is pure L3.
http://sourceforge.net/projects/olsr-lc/

> specify which metric to use per default.

Oh yes: the dimensionless is mandatory. Other metrics types are experimental.
Or I don't get your message.

Regards, Teco