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

[Ulrich Herberg <[e-mail]>]

Hi Joydeep,

see below:


On Mon, Jan 6, 2014 at 6:27 PM, Joydeep Tripathi <[e-mail]> wrote:

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


Yes, the draft is about reactive protocols in general, but explicitly and
prominently cites LOADng.  But this is not the point, so I will use the
term "reactive protocol" below instead of LOADng.



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

And my counter-argument is that I can easily create LLN scenarios where all
proactive protocols suffer compared to a reactive protocol.




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

That sounds like an assertion. And it also sounds like a performance
comparison ("works better"), which you claim later in your reply this draft
is not about.



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

Yes, and I argued that there are mechanisms to extend reactive protocols
(as shown by LOADng as example), so that exactly P2MP and MP2P are
supported.



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

I am not convinced about this. How is this not about performance? You say
that proactive protocols work better than reactive. That seems like a
performance comparison to me.



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

Do you claim that the results obtained were due to a poor implementation of
RPL?



> There are many papers showing RPL outperforms LOADng, specially in large
> networks.
>

Citations always appreciated. But again, give me a protocol and I give you
a scenario where it does not perform well. This is the same discussion
MANET had many years ago. There is just no one-size-fits-all.



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

What, if not for showing better general performance of proactive protocols
(RPL), is then the intent for this draft?



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

And I argued that this only applies to some LLNs, and that in other LLNs
reactive protocols work better (as shown by experiments, as well as
multiple big deployments of reactive protocols in AMI networks).


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


Yes, absolutely. But your draft claims that reactive protocols work less
good for *all* LLNs. That seems contradictory to what you just wrote in
your previous two sentences.



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

I agree that the number of traffic flows is a factor for the control
traffic.


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

Yes, but proactive protocols have a constant periodic overhead, independent
of the number of traffic flows and the number of data packets sent through
the network. While flooding is expensive, it may occur only very
infrequently (when a new flow starts or when a route changes). When there
is no data traffic, there will be no control traffic either. Proactive
protocols will always periodically send control traffic. So in scenarios
with little data traffic, and few concurrent traffic flows, reactive
protocols can be much better (see the cited papers for examples). Note that
I am not saying that reactive protocols are generally better (I am
co-author of the proactive MANET protocol OLSRv2 that has been approved by
the IETF, so I really do see advantages of proactive protocols). I just say
that I object that claim that reactive protocols are bad for *all* LLNs.


> For deployments where reactive protocols create more control overhead,
> they may require energy expense a magnitude larger, depending on the MAC
> layer.
>

Yes, and for deployments where reactive protocols create less control
overhead, proactive protocols 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.
>

That depends on the topology. Long, chain-like topologies would suffer very
much, even if you compress each address to a single byte (e.g., line of
traffic lights along a long road).



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

That is not how I interpret the intent of this draft. Documenting a general
overview and guidelines to implementers about reactive protocols seems 20
years too late. There are tons of papers discussing differences between
proactive and reactive protocols, and it is well understood in which
scenarios which protocol type is more suited. Your draft says "The aim of
this document is not to discuss a specific reactive routing protocol but
why reactive routing protocols in general are ill-suited for LLNs.". As I
have argued, I strongly object this general assertion.



>
> I understand there is no one-size-fits-all for MANET, but this is not
> MANET WG.
>

Yes, but properties of reactive and proactive protocols are the same, no
matter whether they are discussed here or in MANET.



> What we are really trying to show in this document is where reactive
> protocols fail to meet the routing requirements for LLNs.
>

Again looking at the sentence I cited just above, this does not seem to be
the intent, but rather to generally, and for all use cases of LLNs, to
discourage the use of reactive protocols.

Best regards
Ulrich



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