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

[Ines Robles <[e-mail]>]

*Hi Ulrich,Thank you very much for the detailed explanation and for the
references as well, let me analyze them deeply and get back with comments.
Kind Regards,Ines.*


2014/1/6 Ulrich Herberg <[e-mail]>

> Ines,
>
> I object any form of publication of this draft. In my opinion, it is
> another attempt to discredit LOADng and reactive protocols in general with
> false arguments. As has been mentioned before, reactive protocols (in
> particular LOADng) have been very successfully deployed in large LLN
> deployments. So there is proof that in some LLN deployments, reactive
> protocols work very well. Note that I do not claim they work in all such
> use cases, but the 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.
>
> But let me argue why I think this draft is flawed by picking the arguments
> made in the draft:
>
> 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.
>
> 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.
>
> 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. Again, observations of current traffic
> patterns in [1] show that reactive protocols have far less control traffic
> in current use cases of AMI metering. Yes, in cases with lots of concurrent
> traffic lows, then the argument is correct (note that the amount of data
> does not really matter, as the route is only discovered once; so even
> sending gigabytes/second would not be an issue as long as there are limited
> amount of traffic flows). So this is another argument of the sort that
> MANET rejected long time ago. It really depends on the use case and the
> kind of traffic we are talking about.
>
> 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].
>
> 5.1. Impact of flooding in battery operated nodes
>
> "Note that there is a lot of experimental evidence supporting the claim
> that using flooding or scoped flooding to discover routes is ill-suited to
> low-power and lossy networks (LLNs)". Where? I prefer citations over
> assertions.
> Note that I am not claiming that flooding is not costly, but it -- again
> -- depends on the scenario how many different concurrent traffic flows are
> required and how long routes are stored. Also note that optimizations, such
> as MPR flooding, can optimize flooding compared to classic flooding.
>
> 6. Impact on memory
>
> This again depends on the use case. As we have described in [4], RPL in
> storing mode also requires a lot of state. In non-storing mode, packets may
> become very long and lead to fragmentation. With few concurrent traffic
> flows, LOADng largely outperforms RPL in terms of storage requirements (in
> many cases, a single route at a time may be sufficient).
>
> 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?
>
> 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.
>
>
> [1] U. Herberg, T. Clausen, "A Comparative Performance Study of the
> Routing Protocols LOAD and RPL with Bi-Directional Traffic in Low-power and
> Lossy Networks (LLN)", Proceedings of the 8th ACM International Symposium
> on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous
> Networks (PE-WASUN), October 2011
> [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight On-demand
> Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)",
> draft-yi-loadngct-01, Internet Draft (work in progress)
> [3] J. Yi, T. Clausen, and A. Colin de Verdiere. "Efficient Data
> Acquisition in Sensor Networks: Introducing (the) LOADng Collection Tree
> Protocol", Proceedings of the 8th IEEE International Conference on Wireless
> Communications, Networking and Mobile Computing - WiCom-2012, October 2012
> [4] T. Clausen, J. Yi, U. Herberg, Y. Igarashi, “Experiences with RPL:
> IPv6 Routing Protocol for Low power and Lossy Networks”, Internet Draft
> (work in progress), draft-clausen-lln-rpl-experiences-06, February 2013.
> [5] J. Yi, T. Clausen, Y. Igarashi, "Evaluation of Routing Protocol for
> Low Power and Lossy Networks: LOADng and RPL", Proceedings of the 2013 IEEE
> Conference on Wireless Sensors
>
> Best regards
> Ulrich
>
>
>
> On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) <[e-mail]
> > wrote:
>
>>  I can see two paths: (1) ROLL WG ID (not the easiest though, although
>> this could be seen as an applicability
>> ID) or (2) AD sponsored ?
>>
>>  On Jan 6, 2014, at 7:10 PM, Ines Robles <[e-mail]>
>> wrote:
>>
>>
>>
>>
>>
>> * Hi, Thanks for this draft,
>> https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/
>> <https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/> Abstract
>> This document describes serious issues and shortcomings regarding the use
>> of reactive routing protocols in low power and lossy networks(LLNs).
>> Routing requirements for various LLN deployments are discussed in order to
>> judge how reactive routing may or may notadhere to the necessary criteria.
>> We would like to know please,  how is the intend for this document? how
>> this draft would be aligned with roll charter?, should we re-chartering?*
>>
>>  *Thank you in advance,*
>>
>>  Ines Robles
>>
>>
>>
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>>
>