Re: [manet] LOADng-06

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Tue, 23 October 2012 19:18 UTC

Return-Path: <jvasseur@cisco.com>
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 A43DC11E80E3 for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 12:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.369
X-Spam-Level:
X-Spam-Status: No, score=-10.369 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 IX-YcYXBrYhl for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 12:18:30 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0E29611E80D9 for <manet@ietf.org>; Tue, 23 Oct 2012 12:18:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18523; q=dns/txt; s=iport; t=1351019910; x=1352229510; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+WntOFHHoY+CdKui926ub+GroCFDwEASPqwlAak+PXE=; b=OR49BfGozQAer+wC9B8TsvcvXJbn/hqclS71YR4V8raE5WIo0dnT4yUJ fnSs3r4z3Rd8JLoW8vSwmCWWEyXliN06FUL6rV5gPjid2ocXyUdavgAO8 8COST/9hoyCoVchw24dTKsLLi9DmTwpna16iyujT7ia1HyAxywS8f4Aoi A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhUFANHshlCtJXG8/2dsb2JhbABEuQcBiHWBCIIeAQEBAwEBAQEPAVQHCwULAgEIEhAdBycLFAMOAgQOBQgah1wGC5t0j1yQNItghX5gA4gmjmONN4Frgm+BYxce
X-IronPort-AV: E=Sophos; i="4.80,637,1344211200"; d="scan'208,217"; a="131593220"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 23 Oct 2012 19:18:30 +0000
Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9NJITr6028579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 19:18:29 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 14:18:29 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: Ulrich Herberg <ulrich@herberg.name>
Thread-Topic: [manet] LOADng-06
Thread-Index: AQHNsVMuoCdWGOst6kOKVbo4pjGngA==
Date: Tue, 23 Oct 2012 19:18:28 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7722017CF4@xmb-rcd-x02.cisco.com>
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:
x-originating-ip: [10.60.114.231]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000
x-tm-as-result: No--55.880300-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7722017CF4xmbrcdx02ciscoc_"
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 19:18:31 -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.


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

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
_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet