Re: [manet] LOADng-06

Jaudelice de Oliveira <jau@coe.drexel.edu> Tue, 23 October 2012 18:02 UTC

Return-Path: <jau@coe.drexel.edu>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF14F11E80EC for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 11:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.196
X-Spam-Level:
X-Spam-Status: No, score=-2.196 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCWp2RF5vCF4 for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 11:01:59 -0700 (PDT)
Received: from edge02.coe.drexel.edu (edge02.coe.drexel.edu [129.25.59.24]) by ietfa.amsl.com (Postfix) with ESMTP id 506DC21F86AF for <manet@ietf.org>; Tue, 23 Oct 2012 11:01:59 -0700 (PDT)
Received: from ex.coe.drexel.edu ([169.254.1.82]) by Edge02.coe.drexel.edu ([129.25.59.24]) with mapi; Tue, 23 Oct 2012 14:01:58 -0400
From: Jaudelice de Oliveira <jau@coe.drexel.edu>
To: Ulrich Herberg <ulrich@herberg.name>
Date: Tue, 23 Oct 2012 14:02:01 -0400
Thread-Topic: [manet] LOADng-06
Thread-Index: Ac2xSH5tzkzA74gPRGut1Hfi0fk2ZQ==
Message-ID: <FC12CF8A-1E6D-490E-96B8-CFFF48686584@coe.drexel.edu>
References: <785B9E4F-2715-4E20-A7A3-0A49403F458A@axelcdv.com> <0DB6C46A-2B04-4714-AB59-F10D27885B05@cisco.com> <CAK=bVC-o9xfMANAAreesaTcLCT+HyMqNA_yAB-bjxDB960jMVA@mail.gmail.com> <46EE1684-91A3-467E-9530-C9A02819AB6E@coe.drexel.edu> <CAK=bVC_1LFKg7N4euUA7XKDh=8=x0ku+JMy9cqDiuxTwhMj3Kg@mail.gmail.com>
In-Reply-To: <CAK=bVC_1LFKg7N4euUA7XKDh=8=x0ku+JMy9cqDiuxTwhMj3Kg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_FC12CF8A1E6D490E96B8CFFF48686584coedrexeledu_"
MIME-Version: 1.0
Cc: "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] LOADng-06
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 18:02:01 -0000

Hi Ulrich,


On Oct 23, 2012, at 1:01 PM, Ulrich Herberg <ulrich@herberg.name<mailto:ulrich@herberg.name>> 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  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.



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


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

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

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