Re: [manet] LOADng-06

Ulrich Herberg <ulrich@herberg.name> Tue, 23 October 2012 17:01 UTC

Return-Path: <ulrich@herberg.name>
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 8559C1F0419 for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 10:01:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.874
X-Spam-Level:
X-Spam-Status: No, score=-2.874 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 qTYOKAVM3M6q for <manet@ietfa.amsl.com>; Tue, 23 Oct 2012 10:01:22 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C392A11E80CC for <manet@ietf.org>; Tue, 23 Oct 2012 10:01:21 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id fc26so4924975vbb.31 for <manet@ietf.org>; Tue, 23 Oct 2012 10:01:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SReK5F1O49Yc1yuyxrijkUse+VA22ravKcjkbXXCoXo=; b=OLgbAlkVgEAQh8cLaFyj2b579PqMro/w0Ve7jCoOn9Zj19RXIFMbwayyTUiZLvmjnq 6hF/4I2A6+zDNHuMPHTxAtebLNBd6TMNNX2kOFAq1WhHdSLIsJYIX54A4xwXQagCUpMs Ehz0mFy6qVhTZBusBfLrH0DNxfHoL5B65BT64=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=SReK5F1O49Yc1yuyxrijkUse+VA22ravKcjkbXXCoXo=; b=TUVNZr9xLPCdUulXO1JKE2Y5Wckii0cO438rDRJyhKl40ZaCwW8tWDq70uYN6OfLEP lOYmuPYB86hR/S4dBFapPK05MdOUUlEtbvm8ZsHBinI3GYFwLGVdzetIx0iwXvosj0x7 Yf9f6X3EU4Yv4FtyYGcZlaEveDn156nmjuUtOwvU7bMn1AKnctLMIFjpmXuhRO5y0dY3 aSYjJork3yoEx5vg89bL2M38JW8Ba6EoOmtm29TNCf3FQgYxxomYqdf3yuCHrufplQ+7 7b84TttAS0Dyuw5M7ptfbBVcmx15Acliqz9d15yyAPtw6TDi+Z+YmozJEtpTWAhaU04c SQdQ==
MIME-Version: 1.0
Received: by 10.221.2.76 with SMTP id nt12mr3266305vcb.12.1351011681458; Tue, 23 Oct 2012 10:01:21 -0700 (PDT)
Received: by 10.58.94.103 with HTTP; Tue, 23 Oct 2012 10:01:21 -0700 (PDT)
In-Reply-To: <46EE1684-91A3-467E-9530-C9A02819AB6E@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>
Date: Tue, 23 Oct 2012 10:01:21 -0700
Message-ID: <CAK=bVC_1LFKg7N4euUA7XKDh=8=x0ku+JMy9cqDiuxTwhMj3Kg@mail.gmail.com>
From: Ulrich Herberg <ulrich@herberg.name>
To: Jaudelice de Oliveira <jau@coe.drexel.edu>
Content-Type: multipart/alternative; boundary="bcaec54a377a5c5a5d04ccbceb8f"
X-Gm-Message-State: ALoCoQmR6ohet0X8/7/LEOzPavuAru7r2YhB+xJqZQ8fTnQcs2ruKyA8+9S5lHCXP50P1nmFQ4A2
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 17:01:23 -0000

Hi Jaudelice,

On Tue, Oct 23, 2012 at 9:27 AM, Jaudelice de Oliveira
<jau@coe.drexel.edu>wrote:

> Hi Ulrich,
>
> On Oct 22, 2012, at 10:49 PM, Ulrich Herberg <ulrich@herberg.name> 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.


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.




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