Subject: Re: [manet] LOADng Data Collection Cycle

From: Jiazi Yi <[email-masked]>
Date: Tue, 2 Apr 2013 22:56:16 +0200

Hi, 

I'm not sure what's your definition of "topology discovery" and "data collection cycle". 
The control plan of LOADng is about "find the desired routes on demand". The data plan/forwarding has no significant difference with other routing protocols - it's simply hop-by-hop IP forwarding. The only difference is that if there is no available route, LOADng needs to trigger a route discovery (normal routing protocol do "best effort"). 

best

Jiazi

On Mar 31, 2013, at 4:37 PM, Ahmed A. Elawamry <[email-masked]> wrote:

> Hello All,
> 
> I'm new to the MANET working group but i am following the mailing list
> regarding the LOADng protocol. As mentioned at the LOADng drafts that it is
> a reactive routing protocol extracted from the AODV; Thus, it has two cycles
> (topology discovery and data collection cycle). Most of the discussions and
> results are about the topology discovery cycle but i didn't found the
> corresponding results at the data collection cycle as you know that the most
> iterative operation is the data collection cycle not topology discovery. Are
> there any justification about that?!
> 
> Thanks,
> Ahmed A. Elawamry
> 
> 
> 
> --
> View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492.html
> Sent from the IETF - manet mailing list archive at Nabble.com.
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: AHMED AWAMRY <[email-masked]>
Date: Wed, 3 Apr 2013 13:42:34 -0700 (PDT)

Hi,

Thank you for your answer. I mean by topology discovery that finding routes to the required destination (constructing routing table). As you know, this phase is implemented on demand and in case of RERR. I want to mention that the data collection cycle is repeated a lot of times (for example if there will be a session between two nodes) so, it's good to mention the results and the test cases regarding the data collection cycle because it will be very effective measurement  for the routing protocol behavior.

 Thanks,
Ahmed A. Elawamry,

From: Jiazi Yi <[email-masked]>
To: Ahmed A. Elawamry <[email-masked]> 
Cc: [email-masked] 
Sent: Tuesday, April 2, 2013 10:56 PM
Subject: Re: [manet] LOADng Data Collection Cycle
 
Hi, 

best

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Thu, 4 Apr 2013 11:49:49 +0200

Hi, 

I would be careful when talking about "session" in the network layer. I think you are more talking about data transmission between two nodes(routers)?

In fact, there have been several publications about the performance of LOADng and its extensions. More publications are in the pipeline. 
Please check:

LOADng: Towards AODV Version 2
IEEE VTC 2012 Fall, IEEE 76th Vehicular Technology Conference
Thomas Clausen, Jiazi Yi, Axel Colin de Verdiere
http://www-mobile.ecs.soton.ac.uk/home/conference/VTC12-Fall/DATA/PID1141082.PDF

Smart Route Request for On-demand Route Discovery in Constrained Environments
IEEE ICWITS 2012, IEEE International Conference on Wireless Information Technology and Systems
Jiazi Yi, Thomas Clausen, Antonin Bas
http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb00ae8ff62c37d68175.pdf

Efficient Data Acquisition in Sensor Networks:Introducing (the) LOADng Collection Tree Protocol
IEEE WiCom 2012, The 8th IEEE International Conference on Wireless
Communications, Networking and Mobile Computing.
Jiazi Yi, Thomas Clausen, Axel Colin de Verdiere
http://hipercom.thomasclausen.net/resteam/data/publications/1b5774b6394c71a44d49330f9d2e4ee5.pdf

Expanding Ring Search for Route Discovery in LOADng Routing Protocol
The 1st International Workshop on Smart Technologies for Energy, Information and Communication
Antonin Bas, Jiazi Yi, Thomas Clausen
http://hipercom.thomasclausen.net/resteam/data/publications/0c54e160b9e3aba9e7c383f64c1fda03.pdf

There is also a draft about interop test of LOADng:

Experience with the LOADng routing protocol for LLNs
T. Clausen, A. Camacho, J. Yi, A. Colin de Verdiere, Y. Igarashi, SATOH. H. Y. Morii
http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report

best

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Thu, 4 Apr 2013 12:14:53 +0200

Hi Ahmed, 

There is one important thing that I have to mention: some of those publications introduce different options/extensions of LOADng, but most of them are not part of LOADng draft (yet). 

This is generally because of the fundamental difference between scientific publications and IETF Internet Draft (especially standard track draft):

   o The scientific publications is to investigate new approaches, and explore *possible* ideas that can be introduced to an Internet Draft. 
   o The IETF Internet Draft is to document clear, simple, and well-understood technical approaches that can be implemented in the real world. 

Therefore, for LOADng, while we are keeping exploring new ideas and options, those options won't exist in the IETF draft until we are sure that they can serve the real world (based on more operational experiences and tests in different scenarios). 

best

Jiazi

---

From: AHMED AWAMRY <[email-masked]>
Date: Thu, 4 Apr 2013 05:01:15 -0700 (PDT)

Hi Jiazi,

Thank you for illustrating the difference between the IETF draft and the scientific publications. Also, regarding the publications sent. I have some questions about the results listed at the sent publications.

1. What is the propagation delay set on evaluating the End-To-End delay? as i know that the propagation delay affects largely the end-to-end delay result. This is because , when you changed the propagation delay of the channel (wireless or wired) you will gain different results.

2. Regarding the overhead, I think  that there are two points of view related to the overhead:
                    A. Network Overhead (like the one mentioned at the papers)
                    B. Processing Overhead (like memory usage and required processing)
Did you estimate the factor *2.B*? if yes, what is its value?

   Thanks,

Ahmed A. Elawamry,

________________________________
 From: Jiazi Yi <[email-masked]>
To: AHMED AWAMRY <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Thursday, April 4, 2013 12:14 PM
Subject: Re: [manet] LOADng Data Collection Cycle
 
Hi Ahmed, 

best

Jiazi

---

From: Jiazi Yi <[email-masked]>
Date: Fri, 5 Apr 2013 11:23:52 +0200

Hi,

> 1. What is the propagation delay set on evaluating the End-To-End delay? as i know that the propagation delay affects largely the end-to-end delay result. This is because , when you changed the pro…

The propagation delay depends on the lower-layer protocol used. In our simulations for LOADng evaluation, it's 802.11b. 

> Did you estimate the factor *2.B*? if yes, what is its value?

The "processing overhead" for an on-demand protocol like LOADng is trivial, with O(n) complexity. 

best

Jiazi

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 5 Apr 2013 11:57:47 +0200

> The "processing overhead" for an on-demand protocol like LOADng is trivial,

I thought memory overhead was O(d+h), d:network diameter, h:neighbors,
but processing overhead depends on implementation, routing overhead
and memory overhead (how to determine that?). However, I disagree that
processing overhead is with O(n) for MANET-reactive protocol.

 If the LOADng is Light-manet-protocol then I assume it SHOULD have
less processing than non-Light-manet-protocol.

AB

---

From: Jiazi Yi <[email-masked]>
Date: Sat, 6 Apr 2013 16:29:27 +0200

Hi,

> processing overhead is with O(n) for MANET-reactive protocol.

I have no idea what's O(d+h) notation. 

> less processing than non-Light-manet-protocol.

I won't call other protocols "non-linght-manet-protocol", but there are some differences between LOADng and AODV, which is listed in introduction of LOADng draft. It illustrates how LOADng is simplified. 

best

Jiazi

---

From: AHMED AWAMRY <[email-masked]>
Date: Sun, 7 Apr 2013 02:09:41 -0700 (PDT)

Hi Jiazi,

Please find my below reply,

Sent: Friday, April 5, 2013 11:18 AM
 
Hi, 

So, you use nodes of 250m range, Mesh topology connected.We could
consider LOADng as Layer 3 protocol, is this right?  

 I mean by processing overhead,the overhead
introduced by the protocol to be implemented, (How many events executed to
perform the protocol?) Also, the memory usage used to implement or simulate the
protocol (I think the LOADng interoperability-report mentioned
6000-lines Java code, is it for implementation or test?). This will be
very efficient to select the suitable IC (MCU or DSP) to implement the protocol.
best

Jiazi

Regards,
Ahmed A. Elawamry,

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 9 Apr 2013 18:11:15 +0200

Hi, 

On Apr 7, 2013, at 11:09 AM, AHMED AWAMRY <[email-masked]> wrote:

> So, you use nodes of 250m range, Mesh topology connected.We could consider LOADng as Layer 3 protocol, is this right? 

LOADng can be used in both layer 2 and layer 3. In IETF, we care more about its application in layer 3.  
In our tests/simulations, it's in layer 3. 

> I mean by processing overhead,the overhead introduced by the protocol to be implemented, (How many events executed to perform the protocol?) Also, the memory usage used to implement or simulate the protocol (I think the LOADng interoperability-report mentioned 6000-lines Java code, is it for implementation or test?). This will be very efficient to select the suitable IC (MCU or DSP) to implement the protocol.

In fact, the 6000-line java code is with functions like network simulation, test, different extensions. For a "pure" LOADng implementation, it can be greatly reduced. 
For example, the implementations of Hitachi is with 1589 C code, or 1987 C++ code. 

For the moment, all the implementations that I'm aware of, are in software. Because the protocol is fairly simple, I think it would be enough to have software implementation, which also has the advantage of flexibility. 

best

Jiazi

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 9 Apr 2013 16:43:55 +0000

Why are we still discussing loadng on this mailing list as opposed to the WG Manet reactive routing protocol ?

JP Vasseur
Cisco Fellow

Sent from my iPhone

---

From: Henning Rogge <[email-masked]>
Date: Tue, 9 Apr 2013 18:46:24 +0200

Most likely because people are interested in it and its on topic.

We have to look over ALL parts of the aodv2-00 document in the next
months and decide what to keep, what to change and what to remove...
discussing the details of other reactive manet protocols will surely
help with this.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Jiazi Yi <[email-masked]>
Date: Tue, 9 Apr 2013 23:44:20 +0200

Hi, 

I think it's simply because:

	o LOADng is in active development cycle. There are a lot of engineers working on it. We have new results/implementation experience everyday. 

	o There are a lot of people interested in LOADng. 

	o it's about running code/implementation 
			-- hopefully it's still what IETF (or MANET WG) believes in. 

All the previous discussions are purely technical. I really don't want to start the political part. But if that happens, I would have tons of words to say. 

sincerely

Jiazi

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 10 Apr 2013 03:02:51 +0000

(Putting my co-chair hat firmly on)… 

I think that this discussion has been productive, and should continue. As someone mentioned on the list, the discussion may well lead to improvements in the AODVv2 specification. 

So, my recommendation would be to "Keep Calm, and Carry On".

Regards,
Stan

---

From: "Ahmed A. Elawamry" <[email-masked]>
Date: Sun, 14 Apr 2013 03:32:47 -0700 (PDT)

Hi Jiazi,

Are these memory requirements (1987 C++ lines) for LOADng or LOADng-CTP? as
i see from the publications, it provides better performance.

Also, Is the routing table for LOADng and LOADng-CTP are identical (have the
same fields)?

Regards,
Ahmed A. Elawamry 

-----
Best Regards,
Ahmed A. Elawamry

--
View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365223.html
Sent from the IETF - manet mailing list archive at Nabble.com.

---

From: Jiazi Yi <[email-masked]>
Date: Mon, 15 Apr 2013 17:20:50 +0200

Dear Ahmed, 

> i see from the publications, it provides better performance.

The Hitachi's C++ implementation is for LOADng. For the moment, only LIX's implementation is with LOADng-CTP. 
There is no doubt that LOADng with CTP extension provides better performance than basic LOADng in sensor-to-root (or MP2P) scenarios. 
In fact, the CTP extension for LOADng is fairly simple and straightforward. With my estimation, it needs probably 100~ lines of code. 

> Also, Is the routing table for LOADng and LOADng-CTP are identical (have the

Yes, the routing table is identical. The message used (RREQ/RREP) are the same. 
The collection tree extension is designed to be compatible with LOADng - even the router without collection tree extension could join the collection tree (but performance won't be the same, of course). 

best

Jiazi

---

From: "Ahmed A. Elawamry" <[email-masked]>
Date: Sat, 20 Apr 2013 23:52:34 -0700 (PDT)

Hi,

Please i have a question about end-to-end delay. Why the end-to-end delay of
AODV is lower than LOADng (at higher number of nodes) although LOADng has
lower overhead?.

Regards,
Ahmed A. Elawamry

-----
Best Regards,
Ahmed A. Elawamry

--
View this message in context: http://ietf.10.n7.nabble.com/LOADng-Data-Collection-Cycle-tp363492p365958.html
Sent from the IETF - manet mailing list archive at Nabble.com.

---

From: Jiazi Yi <[email-masked]>
Date: Mon, 22 Apr 2013 12:14:18 +0200

Hi, 

LOADng has slightly longer delay than AODV is because LOADng core specification eliminates intermediate route reply (iRREP). 

When intermediate route reply is used (by AODV),  an intermediate router could reply to a Route Request. For LOADng, only the destination router can reply the route request. By doing so, LOADng might need longer time for route discovery. 

LOADng core specification prohibits iRREP because:

	o iRREP needs more fields in the RREQ message, which increases message overhead. 
	o iRREP requires more processing in the router to avoid loops
	o There is possibility of loops when iRREP is used. 
	o iRREP provides attack vectors to the protocol, which makes the network hard to secure. 
	o In networks where reactive protocol is used (for example, sensor networks), delay is not critical issue, in most of the cases. 

A more detailed discussion about this issue is available at 

=============
	J. Yi, T. Clausen, A. Bas: Smart Route Request for on-demand route discovery in constrained environments, IEEE International Conference on Wireless Information Technology and Systems (ICWITS), 2012 

a pdf version: http://hipercom.thomasclausen.net/resteam/data/publications/154942d0d353eb00ae8ff62c37d68175.pdf

Please check section 3A - Intermediate Route Replies: to be, or not to be...
==============

In the meantime, while iRREP is eliminated in the core specification of LOADng, it can exist as an extension of LOADng. 

best

Jiazi