Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability

Abdussalam Baryun <> Wed, 08 January 2014 04:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4D6C91AE2CA for <>; Tue, 7 Jan 2014 20:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iffw2iBPXV3Z for <>; Tue, 7 Jan 2014 20:48:00 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c02::22a]) by (Postfix) with ESMTP id 82AAA1AE2C6 for <>; Tue, 7 Jan 2014 20:48:00 -0800 (PST)
Received: by with SMTP id g10so1293358pdj.1 for <>; Tue, 07 Jan 2014 20:47:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mqp1nP4Arj6c1LLTc8IfTdHy0nOzigYPIx44gCdjr5M=; b=MaVB+xDzCtbuC9ObeEXLw2Hruhv8u2Jb19NU1JCwmENSly5m+tyH2L2XKjP7Rw8Szc Ubh1VwEBw2aAZ+hTHE57OfYMuo/gm/pnxFr7r4rfDNpgo36nl78kyPfQgt5URYw4yPYx DbeeppFd8FOIsQvvEthydogX3fOsN2sBA4WAuRk1hSAbEsXNjzvFqsheZ0rZUJEW9xj6 tB8CgDBDcolXWqPrNcLsRnuDnGmC7dz9Yg6X2KJ96sNOgApHT4DSksLZVOLGKz4Kcuce QDimq5pRfGBgyFX/zVgIHXHpqWmR6BZ939gPny5FNRu3ZjGUMzhqrFvbRVexJhc6PcV2 8FAg==
MIME-Version: 1.0
X-Received: by with SMTP id qz2mr4913316pbc.84.1389156471579; Tue, 07 Jan 2014 20:47:51 -0800 (PST)
Received: by with HTTP; Tue, 7 Jan 2014 20:47:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 8 Jan 2014 05:47:51 +0100
Message-ID: <>
From: Abdussalam Baryun <>
To: Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary=047d7b2e07a706bc9904ef6e3253
Cc: Ines Robles <>
Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 Jan 2014 04:48:03 -0000

On Tuesday, January 7, 2014, Ulrich Herberg wrote:

> MANET WG has understood this more than a decade before that reactive
> protocols can work in some scenarios, not in all. It is possible to create
> scenarios where reactive protocols are better, and others where proactive
> protocols are better. Claiming that, in general, for LLNs one is better
> than the other is incorrect in my opinion.
There are difference between MANETs and LLNs scenarios. I never like
general drafts without applicability statements. In LLN we should not
categorise protocols only as reactive or proactive (that is manet routing

> 3.1. Inability to support P2MP traffic pattern
> This very much depends on the use case. LOADng has been deployed in
> several scenarios where P2MP traffic is sparse, and where few concurrent
> traffic flows are used. This is not a theoretic scenario, but a deployment
> that is actually used by some utilities. We have shown in [1] that in this
> case, LOADng outperforms RPL by far. See also [5] further evaluations. Not
> only has LOADng orders of magnitude less control traffic than RPL in the
> investigated scenarios, but also the state requirements are far smaller.
Both references 1 and 5 are similar to this draft still not adopted or
published by IETF.  Any document author will argue for their doc but did
any specify all LLN scenarios in the doc.

> 3.2. Inability to support MP2P traffic pattern
> There is an easy-to-implement extension to LOADng submitted as [2] that
> solves this. Performance evaluations in [3] show the efficiency of the
> solution.
The draft does not evaluate that protocol or possible solutions but it was
saying reactive.

> 4. Dependency of control overhead on application module
> This is a general observation of reactive protocols that the MANET WG has
> understood more than a decade ago.

In IETF MANET is not LLN. Even in many work published outside-IETF  they
are different with different protocols.

> 5. Flooding issues in LLNs
> It is correct that flooding causes a lot of overhead and battery drain.
> But note that we also observed in [1] and [4] that RPL in downward mode
> also causes a lot of control traffic, more than LOADng for a similar
> scenario that is described in the draft. It again depends on the use case.
> For example, with the extension proposed in [2], the performance for such
> traffic in LOADng is at least as good as with RPL (see also [3]). Note that
> in the described scenario, RPL would require an equal amount of state (in
> storing mode), or lead to very long packets in non-storing mode and
> therefore potential fragmentation, such as described in [4].
I don't think we are comparing protocols but we need to compare flooding
techniques in specific use cases. I think your references don't cover all
use cases as well.

> 6. Impact on memory
> This again depends on the use case.

Depends on many issues not only use cases.

> 7. Lack of support for routing based on node capability
> This argument is flawed. LOADng provides a very extensible and flexible
> definition of route metrics. It is easy to create a metric that reflects
> limitations of the nodes, such as energy and CPU/memory resource
> limitations. How is this different from RPL?
>> I think both protocols don't have that is why I wanted to do a protocol
for node capability, NAP, but still work in progress.

> 8. High delay for emergency traffic
> While it is true that reactive protocols have a higher delay requirement
> than proactive protocols, the argument is, again, flawed. The draft writes
> "*Some* data in an LLN are delay sensitive by nature". I agree. It further
> mentions industrial automation settings. Yes, in *some* LLNs, delay is
> indeed critical (e.g., light switch), but in others it is not as much (AMI
> metering). The draft argues that reactive protocols are bad for *all* LLNs,
> but provides evidence only for *some*. This is exactly what the MANET WG
> has agreed on in the 1990s that there is no one-size-fits-all.
>  The draft should say: manet reactive protocols are bad for most LLNs,
because no one in IETF has published that reactive protocols are good for
all LLNs or even all MANETs.