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

Abdussalam Baryun <abdussalambaryun@gmail.com> Wed, 08 January 2014 04:48 UTC

Return-Path: <abdussalambaryun@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6C91AE2CA for <roll@ietfa.amsl.com>; Tue, 7 Jan 2014 20:48:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iffw2iBPXV3Z for <roll@ietfa.amsl.com>; Tue, 7 Jan 2014 20:48:00 -0800 (PST)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 82AAA1AE2C6 for <roll@ietf.org>; Tue, 7 Jan 2014 20:48:00 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id g10so1293358pdj.1 for <roll@ietf.org>; Tue, 07 Jan 2014 20:47:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.68.224.34 with SMTP id qz2mr4913316pbc.84.1389156471579; Tue, 07 Jan 2014 20:47:51 -0800 (PST)
Received: by 10.68.0.104 with HTTP; Tue, 7 Jan 2014 20:47:51 -0800 (PST)
In-Reply-To: <CAK=bVC8Bvd+rxZmroCFaWiV=O1Tj8=gF7+fR+EVqFw=xBAV+RQ@mail.gmail.com>
References: <CAP+sJUfBoD_L1o2W4viAdn4DayfbksbZPNB5ezujDbEtojps=A@mail.gmail.com> <E9B58E97-B9C8-4BCF-8B48-8EF6E0B8CDBD@cisco.com> <CAK=bVC8Bvd+rxZmroCFaWiV=O1Tj8=gF7+fR+EVqFw=xBAV+RQ@mail.gmail.com>
Date: Wed, 8 Jan 2014 05:47:51 +0100
Message-ID: <CADnDZ8_F0EjykwNAhkv-f4nn+JEGxdDP08sACrSwBc2g7S5+RA@mail.gmail.com>
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b2e07a706bc9904ef6e3253
Cc: Ines Robles <mariainesrobles@googlemail.com>
Subject: Re: [Roll] Intend for draft-tripathi-roll-reactive-applicability
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=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
categorised).

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

AB




>