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

[Abdussalam Baryun <[e-mail]>]

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




>