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

[Joydeep Tripathi <[e-mail]>]

Hi Ulrich,

Thanks for your comments and feedback. Let me respond inline.

On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg <[e-mail]> wrote:

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

Well LOADng is one recent example of reactive protocols. However, we are
not discussing about LOADng to *any* extent in this draft.


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

We had tons of discussions on whether LLNs can be generalized as MANETs.
You are right to point out that "MANET WG has understood this more than a
decade before that reactive protocols can work in some scenarios, not in
all". Our argument through this draft is, LLNs in general come under the
scenario where reactive protocols suffer due to the points made out in the
draft. Note that there may be example where a reactive protocol works for a
deployed LLN, but it does not mean it will work better than a proactive
counterpart for that deployment or for any other deployment.

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

Ability to support P2MP traffic pattern for routing protocols in LLN is
mandated by RFC 5548. Actually P2MP and MP2P traffics are pre-dominant for
LLNs, and P2P traffic is considered rare. So for a protocol type to be
considered a candidate to be used in LLNs it is required to examine how it
fairs to handle P2MP traffic.


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

 At the same time, I wish to point out that this document, in no form is a
comparison between RPL and LOADng. Simulation results in form of academic
paper references are used to show how a reactive protocol behaves in
different scenarios in terms of different metrics. Any protocol
implementation can be done in an non-optimized manner to show that performs
poorly than another protocol. There are many papers showing RPL outperforms
LOADng, specially in large networks. But as I mentioned before, this
document does not provide any performance comparison. LOADng is used as an
example. To my intuition, AODVv2 may behave in a similar way as well. I do
not think this WG is the right place to debate how LOADng or any other
protocol performs compared to RPL. This document shows in which areas
reactive protocols in general suffer to meet the routing requirements in
LLNs, thus pointing out pitfalls to look for / areas of improvement.


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

I guess it is again a deployment and protocol specific example. For a
particular deployment and traffic pattern, one protocol may work and meet
the requirements. That does not mean the protocol, or protocol-family in
general, will be suited to meet the routing requirements spelled out for
LLNs in RFC 5548, RFC 5673, RFC 5826, RFC 5867 etc.


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

The draft not does not even consider any application traffic rate or range
of data traffic rate. It considers, as you pointed correctly, different
flows, and future installation of application modules. So I guess we both
agree, that number of traffic flows is a factor in generating control
overhead.


> 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 would again like to point out that this draft is not a performance
comparison between RPL and LOADng. However, I would also like to point out
that `N' number of unicast control packets consume less energy than `N'
number of broadcast control packets. The reasoning is provided in next
subsection (5.1). In smaller deployments and light traffic scenario,
reactive protocols may incur less control overhead than a proactive
counterpart. However, most of these control packets are broadcast packets,
thus consuming much more energy than a proactive counterpart even if the
proactive protocol shows more control packets in the simulation. For
deployments where reactive protocols create more control overhead, they may
require energy expense a magnitude larger, depending on the MAC layer.


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

The reasoning why this is the case is provided with references is provided
i version-02 of the draft. For the detailed text, please refer to the
version 02, which we just posted.


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

With the assertion one more time that this is not a performance comparison
draft, I would like to point out that with header compression, source
routing is very much feasible even over 802.15.4. And once again, you are
comparing LOADng with *few concurrent flows*. The argument will be invalid
for nodes closer to a sink for a large scale network. I agree it depends on
use cases and traffic profiles. However this document, as I mentioned,
provides a general overview, and is intended to consider superset of cases,
and to guide implementors to look at the probable pitfalls that reactive
protocols may be subjected to.

I understand there is no one-size-fits-all for MANET, but this is not MANET
WG. What we are really trying to show in this document is where reactive
protocols fail to meet the routing requirements for LLNs.

I would appreciate further comments or feedback.

Thanks & Regards,
Joydeep


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