Subject: [manet] LOADng-06

From: Axel Colin de Verdière <[email-masked]>
Date: Mon, 22 Oct 2012 17:03:58 -0700

Dear all,

we have updated LOADng, to make it clear that it is in scope and charter for MANET. Unfortunately, it is only a minor revision of the technical content, since we have been in discussions with the DYMO authors and the WG leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely reply very soon to the list with an outcome of the discussion.

Best regards,

Axel Colin de Verdiere

---

From: Bo Berry <[email-masked]>
Date: Mon, 22 Oct 2012 21:39:54 -0400

Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities 
and the unique differences of Loadng relative to Dymo.  I'm aware 
of the discussions about lousy nets and manets, but less between 
the two protocols. 

I think this would help everyone on the WG understand the benefits.

Looking at the Tools page, the draft was first submitted October 24, 2011,
draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand Ad hoc 
Distance-vector Routing Protocol - Next Generation (LOADng)."  The
abstract included the statement "The protocol is derived 
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for 
use in LLNs." was removed.  This version also supported RFC 5444. 

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06,
for the most part changes "Low power and Lossy Networks (LLN)"
references to "Mobile Ad hoc NETworks (MANETs)." 

Thanks
-Bo

On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdière wrote:

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

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 22 Oct 2012 19:49:42 -0700

Hi Bo,

> I think this would help everyone on the WG understand the benefits.

I agree with that, and it is a fair question to ask. Let me try to list a
few differences, others may chime in with more.

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended status of
"Proposed Standard" (AODV is "Experimental"). The MANET charter lists that
the WG has to come up with a std. track reactive protocol. Essentially, in
a reactive protocol, routes are requested "on-demand" (i.e. when there is
data traffic and no route exists for the destination of the data packet).
Therefore, you will see similar message types in both protocols (Route
Requests, Route Replies, and Route Errors), and essentially the same basic
mechanism.
- Both are applicable to MANETs (see also below for your next question),
and both support RFC5444. LOADng is decoupling the mechanism from the
message format; RFC5444 is mapped to the mechanism, but other message
formats could easily be specified (e.g., with a more compressed message
format for extremely limited links in terms of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gather
broad industrial support from several large companies, several large-scale
deployments with several thousands of nodes, LOADng has an updated MIB
document, and documented interoperability test of at least four recent
implementations.
- Part of the reason, I believe, is that the writing style is very
different. LOADng has a more algorithmic way of writing. That's immediate
to see when you compare section 5.3 of DYMO with section 12 of LOADng. It
is, IMO, much harder to implement DYMO. The goal for LOADng was to make it
so straight forward to implement that an undergrad student could take the
spec, spend a few days implementing it and have a reasonable and
interoperable implementation. I have implemented LOADng in one day, based
on the specification.
- There are multiple optional features in DYMO that have deliberately not
been included in LOADng (expanding ring multicasts, intermediate RREPs,
precursor lists etc). The reason was the following: in an experimental
protocol (AODV) it is fine to have many options, in order to explore
whether they are useful. We have that experience now with AODV. For some of
the options, such as iRREP, it has not been shown over the last decade that
they are of general use. In some cases, they may be beneficial, but not in
general. Also, they make it very hard to provide end-to-end security.
LOADng kept the mantra of a small, slim, and efficient protocol. Having
many options makes it hard to assure interoperable devices out of the box,
in particular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is an
extremely scarce resource, and where proactive protocols cannot be used.
That makes a slim design preferable, IMO, for such protocols.
- LOADng may be used in other layers as L3, e.g. as mesh-under protocol.
- LOADng supports optimized broadcasting mechanisms such as MPR flooding
- There is no Route Reply ACK in DYMO; this is part of LOADng to verify
bidirectionality of links; as in wireless channels, links are rarely
symmetric.

> references to "Mobile Ad hoc NETworks (MANETs)."

The draft started out from where the deployments exist, which some call
LLNs. However, as a basic reactive protocol, LOADng also covers the more
general MANET case that includes a wider ranger of resources (from
extremely constrained to not-so-constrained) and mobility. In particular,
by supporting RFC5444 it fits well in the MANET architecture and the
surrounding security extensions, flooding optimizations and TLVs etc. for
RFC5444.

I hope I could shed some light on that question. I invite you to read both
drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were not
so much about technical issues, but about procedural. LOADng has started
when DYMO was stalled for more than 2 years. I think we have a well mature
document, supported by strong industry backing and running code. The latter
is crucial in the IETF.

Best regards
Ulrich

> > we have updated LOADng, to make it clear that it is in scope and charter
> for MANET. Unfortunately, it is only a minor revision of the technical
> content, since we have been in discussions with the DYMO authors and the WG
> leadership for several months on how to proceed with the reactive protocol
> in MANET. The chairs will likely reply very soon to the list with an
> outcome of the discussion.
> >
> > Best regards,
> >
> > Axel Colin de Verdiere
> >

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 23 Oct 2012 08:41:12 +0200

Hi Axel,

I hope the LOAD team answers to my inputs of previous months regarding
their individual work. I will never review/comment on such work, until
you answer to previous recommendations. Please note that we should
never ignore the WG-list's comments. If this individual-work is
presented to meeting again without replying to MANET-list I will send
complain.

AB

On 10/23/12, Axel Colin de Verdière <[email-masked]> wrote:
> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and charter for
> MANET. Unfortunately, it is only a minor revision of the technical content,
> since we have been in discussions with the DYMO authors and the WG
> in MANET. The chairs will likely reply very soon to the list with an outcome
> of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 23 Oct 2012 09:34:48 +0200

I sent an email to you & the list on October 2. I believe what I said therein to, still, be true.

But please do go ahead and "send complain[t]".

Even better: go ahead and participate constructively in the activity of some WG.

Sent from my iPad

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 23 Oct 2012 09:12:44 +0000

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with your conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alex

I agree with that, and it is a fair question to ask. Let me try to list a few differences, others may chime in with more.

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended status of "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that the WG has to come up with a std. track reactive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and no route exists for the destination of the data packet). Therefore, you will see similar message types in both protocols (Route Requests, Route Replies, and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which has been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question), and both support RFC5444. LOADng is decoupling the mechanism from the message format; RFC5444 is mapped to the mechanism, but other message formats could easily be specified (e.g., with a more compressed message format for extremely limited links in terms of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gather broad industrial support from several large companies, several large-scale deployments with several thousands of nodes, LOADng has an updated MIB document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not think that DYMO failed in any way. It turns out that the timing was different, that's all.

- Part of the reason, I believe, is that the writing style is very different. LOADng has a more algorithmic way of writing. That's immediate to see when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that an undergrad student could take the spec, spend a few days implementing it and have a reasonable and interoperable implementation. I have implemented LOADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we require more algorithmic details about DYMO, let's provide comments to the DYMO
authors.

- There are multiple optional features in DYMO that have deliberately not been included in LOADng (expanding ring multicasts, intermediate RREPs, precursor lists etc). The reason was the following: in an experimental protocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that experience now with AODV. For some of the options, such as iRREP, it has not been shown over the last decade that they are of general use. In some cases, they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. LOADng kept the mantra of a small, slim, and efficient protocol. Having many options makes it hard to assure interoperable devices out of the box, in particular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is an extremely scarce resource, and where proactive protocols cannot be used. That makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options are IMO quite useful.

JP> Another concern … If you plan using LOAD-ng as a mesh under protocol, this requires much more discussion (not sure that such discussions
should take place at the IETF, but because this would be an IETF work, we would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses instead of IP addresses: there are tons of implications of the architecture,
as described in details in http://tools.ietf.org/html/draft-routing-architecture-iot-00

- LOADng supports optimized broadcasting mechanisms such as MPR flooding
- There is no Route Reply ACK in DYMO; this is part of LOADng to verify bidirectionality of links; as in wireless channels, links are rarely symmetric.

JP> Let's discuss further about these optimizations, which if needed, could be added to DYMO.

The draft started out from where the deployments exist, which some call LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANET and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive routing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic this may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of resources (from extremely constrained to not-so-constrained) and mobility. In particular, by supporting RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizations and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were not so much about technical issues, but about procedural. LOADng has started when DYMO was stalled for more than 2 years. I think we have a well mature document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have strong industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich

Thanks
-Bo

On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdière wrote:

> [email-masked]<mailto:[email-masked]>

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

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

---

From: Bo Berry <[email-masked]>
Date: Tue, 23 Oct 2012 07:38:01 -0400

On Oct 22, 2012, at 10:49 PM, Ulrich Herberg wrote:

> The draft started out from where the deployments exist, which some call LLNs. However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of resources (from extremely constrained to not-so-constrained) and mobility. In particular, by supporting RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizations and TLVs etc. for RFC5444.

When you say, "draft started out from where the deployments exist",
where these implementations DYMO, which draft?

Since 5444 was just added to the Loadng draft, is there an implementation using 5444?

> I won't go into details here, but most of the discussions we had were not so much about technical issues, but about procedural. LOADng has started when DYMO was stalled for more than 2 years. I think we have a well mature document, supported by strong industry backing and running code. The latter is crucial in the IETF.

I'm curious why the Loadng effort did not/could not work through the WG to re-invigorate the DYMO discussions. 

January 2005 - draft-ietf-manet-dymo-00
    - Mobile Ad hoc Networks Working Group
    - Expires: July 5, 2005

... several draft updates ...

December 5, 2008 - draft-ietf-manet-dymo-16

March 8, 2009 - draft-ietf-manet-dymo-17
    - Expires: September 9, 2009

February 23, 2010 - draft-ietf-manet-dymo-18
    - Expires: August 27, 2010
    - This draft included RFC5444 formatting

March 22, 2010 - draft-ietf-manet-dymo-19
    - Expires: September 23, 2010

July 10, 2010 - draft-ietf-manet-dymo-20

July 26, 2010 - draft-ietf-manet-dymo-21
    - Expires: January 27, 2011

*October 24, 2011 - draft-clausen-lln-loadng-00
    - Title: The LLN On-demand Ad hoc Distance-vector
      Routing Protocol - Next Generation (LOADng)
    - Abstract: This document describes the LLN Ad hoc On-Demand (LOAD) distance
      vector routing protocol, a reactive routing protocol intended for use
      in Low power Lossy Networks (LLN).  The protocol is derived from AODV
      and extended for use in LLNs.

*October 31, 2011 - draft-clausen-lln-loadng-01

March 12, 2012 - draft-ietf-manet-dymo-22
    - Expires: September 13, 2012
    - Rebranding the protocol was included:
      Dynamic MANET On-demand (AODVv2) Routing

*March 12, 2012 - draft-clausen-lln-loadng-02

*March 29, 2012 - draft-clausen-lln-loadng-03

*April 22, 2012 - draft-clausen-lln-loadng-04

*July 14, 2012 - draft-clausen-lln-loadng-05
    - C. Perkins, Futurewei Inc. was added as a co-author
    - This line was removed from the Abstract: "The protocol
      is derived from AODV (RFC3561) and extended for use in LLNs."
    - This draft included RFC5444 formatting

October 23, 2012 - draft-ietf-manet-dymo-23 

*October 22, 2012 -  draft-clausen-lln-loadng-06
   - Added J. Dean from Naval Research Laboratory

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 23 Oct 2012 08:19:56 -0700

Hi JP,

I was about to write a more detailed answer and then decided against it. Bo asked a technical question, to which I replied. Let's wait what the chairs say, then I may answer to your points.

Best
Ulrich

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 23 Oct 2012 08:24:16 -0700

Bo,

> where these implementations DYMO, which draft?

Sorry that I was unclear, I meant LOADng.

> Since 5444 was just added to the Loadng draft, is there an implementation using 5444?

Other authors may be more knowledgeabe to reply to this. Note that RFC5444 is decoupled from the core protocol mechanism.

>   - Added J. Dean from Naval Research Laboratory

I was replying to your technical questions, but prefer not to go into history until the chairs reply.

Best regards
Ulrich

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Tue, 23 Oct 2012 12:27:05 -0400

Hi Ulrich,

On Oct 22, 2012, at 10:49 PM, Ulrich Herberg <[email-masked]> wrote:

> 
> Now some differences:
> - Most importantly: LOADng has achieved what DYMO failed to do: to gather broad industrial support from several large companies, several large-scale deployments with several thousands of nodes,

I have joined the list recently, so I probably missed some of the earlier discussion on LOAD-ng MANET deployment experiences. Can you point to documents reflecting MANET results? 

> LOADng has an updated MIB document, and documented interoperability test of at least four recent implementations.

Are you referring to the 2 to 5 LLN node topologies pass/fail testing draft (draft-lavenu-lln-loadng-interoperability-report-03)? 

> - Part of the reason, I believe, is that the writing style is very different. LOADng has a more algorithmic way of writing. That's immediate to see when you compare section 5.3 of DYMO with section…

Indeed, my PhD student also followed the specification and coding it was straight forward. However we did have concerns about its performance in LLNs (which the deployment efforts you spoke of seem to be), specially with regards to control overhead and end-to-end delay.  Being a reactive protocol, its dependency on user traffic may overwelm the network, which we did see in our simulation study. I have seen the email from Thierry that commented on results for 2000 nodes AMI PLC network, but did not get a reply to my inquiry with respect to the traffic used.

> The draft started out from where the deployments exist, which some call LLNs. However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of r…

Again, I may have missed this, but do you have results from deployments with mobile nodes? As you stated, the deployment were the LOADng draft started from were all LLNs, and I am still curious about the details of those studies. Do you have a pointer to a documented study?

Best regards,

Jau.

Jaudelice de Oliveira
Associate Professor
ECE Dept, Drexel University

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 23 Oct 2012 10:01:21 -0700

Hi Jaudelice,

On Tue, Oct 23, 2012 at 9:27 AM, Jaudelice de Oliveira
<[email-masked]>wrote:

> > - Most importantly: LOADng has achieved what DYMO failed to do: to
> gather broad industrial support from several large companies, several
> large-scale deployments with several thousands of nodes,
>
> I have joined the list recently, so I probably missed some of the earlier
> discussion on LOAD-ng MANET deployment experiences.

Welcome to the list!

> Can you point to documents reflecting MANET results?
>

Just to be clear here: MANET is working on an improved version of AODV. I
expect a very similar performance of LOADng compared to AODV, and there are
dozens, maybe hundreds of papers about the performance of AODV. This is
very similar between OLSR and OLSRv2; I would be very surprised to see a
significant performance difference between the two protocols, as they have
the same mechanism (however, OLSRv2 has several simplifications such as
fewer message types and is more flexible because of RFC5444). The reason
why MANET has this discussion is to come up with a standards track version
of AODV.

So compared to AODV, LOADng has some improvements which are listed in the
introduction:

Compared to [RFC3561 <http://tools.ietf.org/html/rfc3561>], LOADng is
extended as follows:

   o  Optimized flooding is supported, reducing the overhead incurred by
      RREQ generation and flooding.  If no optimized flooding operation
      is specified for a given deployment, classical flooding is used by
      default.

   o  Different address lengths are supported - from full 16 octet IPv6
      addresses over 8 octet EUI64 addresss [EUI64
<http://tools.ietf.org/html/draft-clausen-lln-loadng-06#ref-EUI64>], 6
octet MAC
      addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet
      addresses such as [RFC4944
<http://tools.ietf.org/html/rfc4944>].  The only requirement is, that
within
      a given routing domain, all addresses are of the same address
      length.

   o  Control messages are carried by way of the Generalized MANET
      Packet/Message Format [RFC5444 <http://tools.ietf.org/html/rfc5444>].

   o  Using [RFC5444 <http://tools.ietf.org/html/rfc5444>], control
messages can include TLV (Type-Length-
      Value) elements, permitting protocol extensions to be developed.

   LOADng supports routing using arbitrary additive metrics, which can
   be specified as extensions to this protocol.

> Are you referring to the 2 to 5 LLN node topologies pass/fail testing
> draft (draft-lavenu-lln-loadng-interoperability-report-03)?
>

Yes. Again, don't confuse that with a performance evaluation. It is purely
an interop document.

> Indeed, my PhD student also followed the specification and coding it was
> straight forward.

I am glad to hear that.

However we did have concerns about its performance in LLNs (which the
> deployment efforts you spoke of seem to be), specially with regards to
> control overhead and end-to-end delay.

One point to the control overhead: it is given by RFC5444. Unless there is
any fragmentation, I don't see a problem with that. Fragmentation is
unlikely, even in some of the 802.15.4 layers, as there will be a maximum
of two addresses and about two TLVs in each message (you can easily to the
math here how many octets that would be in RFC5444). Using MPR flooding or
other optimized flooding methods have shown to severely reduce the overhead
as well (and there are many studies showing the difference between classic
flooding and MPR flooding). In particular in cases where there are few
communication end-points communicating with each other at the same time and
only rarely there is data traffic, reactive protocols may have a much
better performance (no control traffic unless there is data traffic, and
only 1 route stored at each router). And this is known to MANET WG for a
long time, and reason for the current charter. There are other use cases,
where reactive protocols are not suitable, and proactive protocols are
better, which is why we have OLSR (and hopefully OLSRv2).

On the delay, what are your requirements? Sure, if you need the traffic to
be delivered within 1ms, a reactive protocol may not be the right protocol
for you. Take a proactive protocol then. This is why, contrary to other
WGs, we don't have the approach of "one-size-fits-all". Because it simply
depends on the scenario and your requirements.

> Being a reactive protocol, its dependency on user traffic may overwelm the
> network, which we did see in our simulation study.

Again, that very much depends on the traffic scenario and the topology, and
if you use optimized flooding. I have never doubted that there are
scenarios where reactive protocols suck, but there are scenarios where they
are better than proactive ones.

> I have seen the email from Thierry that commented on results for 2000
> nodes AMI PLC network, but did not get a reply to my inquiry with respect
> to the traffic used.
>
> Again, I may have missed this, but do you have results from deployments
> with mobile nodes?

Pretty much all work that has been done on AODV gives you the performance.
This is how a WG works; there was an experimental protocol, there have been
experiments over the last 10 years or so. Now we improve the protocol by
making the frame format more flexible, by allowing for optimized flooding
etc. and make a standard tracks protocol (at least that's currently in the
charter and pending a decision of the chairs).

> As you stated, the deployment were the LOADng draft started from were all
> LLNs, and I am still curious about the details of those studies. Do you
> have a pointer to a documented study?
>

As I am not one of those having a deployment that can be disclosed, I
cannot reply here.

Ulrich

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 23 Oct 2012 10:05:12 -0700

Hello folks,

I have some more to add to Ulrich's comments.

On 10/22/2012 7:49 PM, Ulrich Herberg wrote:

>
> Moreover, reactive protocols are often used in cases where memory is 
> an extremely scarce resource, and where proactive protocols cannot be 
> used. That makes a slim design preferable, IMO, for such protocols.
> - There is no Route Reply ACK in DYMO; this is part of LOADng to 
> verify bidirectionality of links; as in wireless channels, links are 
> rarely symmetric.

This functionality is easily accomplished without RREP_ACK.

The original design of DYMO was intended to have two characteristics:
- enable minimalistic implementations by making some features optional
- combine the design points of AODV and DSR, which are the two Experimental
   reactive protocols published by [manet] WG.

The name DYMO was chosen in order to signal the development of a
Proposed Standard, and to avoid showing favoritism to AODV or DSR.
In hindsight, the choice of name seems to have been a mistake, and
on the advice of several people I reverted the name back to AODV(v2).
I have made an issue on the issue tracker about the naming.

Of course AODVv2 supports optimized broadcasting, and was always
designed and intended to do so.  Also AODVv2 could equally (and, in
fact, LOADng proves this) be used in other layers.  And, as mentioned,
AODVv2 already supports the functionality of RREP_ACK, and the
specification of pre-existing methods for doing that was viewed as
a simplification.  Of course, RREP-ACK could be added back to the
protocol specification almost trivially, especially since that message
type was already specified in AODV, and later respecified in quite
similar fashion within LOADng.

It is my view that the IETF [manet] reactive protocol specification
was always intended to support minimalistic deployments such as
LOADng, and it is my intention to make sure of it.  Almost
tautologically, having optional features such as precursor lists does
not constrain minimalistic deployments.  I have reorganized the
AODVv2 specification so that the optional features mentioned by
Ulrich are clearly separated from the base protocol.

-- 
Regards,
Charlie P.

---

From: Jaudelice de Oliveira <[email-masked]>
Date: Tue, 23 Oct 2012 14:02:01 -0400

Hi Ulrich,

On Oct 23, 2012, at 1:01 PM, Ulrich Herberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jaudelice,

I have joined the list recently, so I probably missed some of the earlier discussion on LOAD-ng MANET deployment experiences.

Welcome to the list!

So compared to AODV, LOADng has some improvements which are listed in the introduction:

Compared to [RFC3561<http://tools.ietf.org/html/rfc3561>], LOADng is extended as follows:

   o  Different address lengths are supported - from full 16 octet IPv6
      addresses over 8 octet EUI64 addresss [EUI64<http://tools.ietf.org/html/draft-clausen-lln-loadng-06#ref-EUI64>], 6 octet MAC
      addresses and 4 octet IPv4 addresses to shorter 1 and 2 octet
      addresses such as [RFC4944<http://tools.ietf.org/html/rfc4944>].  The only requirement is, that within
      a given routing domain, all addresses are of the same address
      length.

   o  Control messages are carried by way of the Generalized MANET
      Packet/Message Format [RFC5444<http://tools.ietf.org/html/rfc5444>].

   o  Using [RFC5444<http://tools.ietf.org/html/rfc5444>], control messages can include TLV (Type-Length-
      Value) elements, permitting protocol extensions to be developed.

Yes. Again, don't confuse that with a performance evaluation. It is purely an interop document.

> - Part of the reason, I believe, is that the writing style is very different. LOADng has a more algorithmic way of writing. That's immediate to see when you compare section 5.3 of DYMO with section…

Indeed, my PhD student also followed the specification and coding it was straight forward.

I am glad to hear that.

However we did have concerns about its performance in LLNs (which the deployment efforts you spoke of seem to be), specially with regards to control overhead and end-to-end delay.

One point to the control overhead: it is given by RFC5444. Unless there is any fragmentation, I don't see a problem with that. Fragmentation is unlikely, even in some of the 802.15.4 layers, as there will be a maximum of two addresses and about two TLVs in each message (you can easily to the math here how many octets that would be in RFC5444). Using MPR flooding or other optimized flooding methods have shown to severely reduce the overhead as well (and there are many studies showing the difference between classic flooding and MPR flooding). In particular in cases where there are few communication end-points communicating with each other at the same time and only rarely there is data traffic, reactive protocols may have a much better performance (no control traffic unless there is data traffic, and only 1 route stored at each router). And this is known to MANET WG for a long time, and reason for the current charter. There are other use cases, where reactive protocols are not suitable, and proactive protocols are better, which is why we have OLSR (and hopefully OLSRv2).

Perhaps I was too subtle… My point was that you were alluding to LOADng's success  with respect to DYMO by pointing to existing deployments, which I believe are all LLN deployments. By that measure, there are many successful AODV (and DYMO deployments), as you pointed out, so I fail to see the deployment advantage you claimed LOADng to have with respect to DYMO.

Sure, there are scenarios were reactive protocols will thrive and others where proactive protocols are the natural choice. My point was that the LOADng deployment scenarios I have heard of (may have missed discussions on this list) are constrained LLNs, and the traffic used (realistic or not) will drive the performance results.

BR,
Jau.

On the delay, what are your requirements? Sure, if you need the traffic to be delivered within 1ms, a reactive protocol may not be the right protocol for you. Take a proactive protocol then. This is why, contrary to other WGs, we don't have the approach of "one-size-fits-all". Because it simply depends on the scenario and your requirements.

Being a reactive protocol, its dependency on user traffic may overwelm the network, which we did see in our simulation study.

Again, that very much depends on the traffic scenario and the topology, and if you use optimized flooding. I have never doubted that there are scenarios where reactive protocols suck, but there are scenarios where they are better than proactive ones.

I have seen the email from Thierry that commented on results for 2000 nodes AMI PLC network, but did not get a reply to my inquiry with respect to the traffic used.

> The draft started out from where the deployments exist, which some call LLNs. However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of r…

Again, I may have missed this, but do you have results from deployments with mobile nodes?

Pretty much all work that has been done on AODV gives you the performance. This is how a WG works; there was an experimental protocol, there have been experiments over the last 10 years or so. Now we improve the protocol by making the frame format more flexible, by allowing for optimized flooding etc. and make a standard tracks protocol (at least that's currently in the charter and pending a decision of the chairs).

As you stated, the deployment were the LOADng draft started from were all LLNs, and I am still curious about the details of those studies. Do you have a pointer to a documented study?

As I am not one of those having a deployment that can be disclosed, I cannot reply here.

Best regards,

Jau.

Best regards
Ulrich

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 23 Oct 2012 18:06:50 +0000

Hi Ulrich,

On Oct 23, 2012, at 5:19 PM, Ulrich Herberg wrote:

Hi JP,

Sure, feel free not to answer. Your call. I fully respect it.

If you want to have a technical discussion on why (as individual contributor) I think that LOAD-ng is a major issue for highly constrained LLNs,
I would be more than happy to continue that discussion on the mailing list.

That being said, my point was that DYMO/AODVv2 was a very good base to complete the reactive routing work in MANET.

Best.

JP.

Best
Ulrich

On Oct 23, 2012, at 2:12, "JP Vasseur (jvasseur)" <[email-masked]<mailto:[email-masked]>> wrote:

Dear Ulrich,

Hi Bo,

First the commonalities:

Now some differences:

Thanks.

JP.

Best regards
Ulrich

Thanks
-Bo

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Oct 2012 20:31:10 +0200

> That being said, my point was that DYMO/AODVv2 was a very good base to complete the reactive routing work in MANET.

Don't conclude to fast. AFAIK there is no WG decision to step back from DYMO/AODVv2. It just was parked for a while.
Can I assume that your point *is* that DYMO/AODVv2 *is* a very good base to complete? 

Teco

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 23 Oct 2012 19:13:22 +0000

On Oct 23, 2012, at 11:31 AM, Teco Boot wrote:

Hi Ulrich,

Hi JP,

My bad, sorry for the typo "was" should read "is" ! Indeed, Teco, this what I meant to say.

Cheers.

JP.

Teco

Best.

JP.

Best
Ulrich

Dear Ulrich,

Hi Bo,

First the commonalities:

Now some differences:

Thanks.

JP.

Best regards
Ulrich

Thanks
-Bo

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Tue, 23 Oct 2012 19:18:28 +0000

Hi,

[snip]

On Oct 23, 2012, at 10:01 AM, Ulrich Herberg wrote:

Just to be clear here: MANET is working on an improved version of AODV. I expect a very similar performance of LOADng compared to AODV, and there are dozens, maybe hundreds of papers about the performance of AODV. This is very similar between OLSR and OLSRv2; I would be very surprised to see a significant performance difference between the two protocols, as they have the same mechanism (however, OLSRv2 has several simplifications such as fewer message types and is more flexible because of RFC5444). The reason why MANET has this discussion is to come up with a standards track version of AODV.

JP> Note that there is no disagreement on the fact that AODV is a useful protocol ! The issue is when it applies to highly constrained
LLNs. For those having deploying dozens of thousands of nodes in such environments, gathering a ton of data on these networks, it
is legitimate to express real concern about the applicability of such protocols to LLNs. Hope to have a deep technical discussion at
the IETF.

I am glad to hear that.

Best regards,

Jau.

Best regards
Ulrich