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

From: Ines Robles <[email-masked]>
Date: Mon, 6 Jan 2014 16:10:44 -0200

*Hi,Thanks for this draft,
https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/
<https://ietf.org/doc/draft-tripathi-roll-reactive-applicability/>AbstractThis
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

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Mon, 6 Jan 2014 18:24:44 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks for this draft, 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

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 6 Jan 2014 16:14:23 -0800

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)
<[email-masked]>wrote:

>  On Jan 6, 2014, at 7:10 PM, Ines Robles <[email-masked]>
> wrote:
>
>
>
>
>
> * Hi, Thanks for this draft,
> <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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Ines Robles <[email-masked]>
Date: Mon, 6 Jan 2014 22:58:06 -0200

*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 <[email-masked]>

> 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
> 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
> 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
> [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
> [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
> On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) <[email-masked]
> > wrote:
>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 6 Jan 2014 19:21:09 -0800

Hi Joydeep,

see below:

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

> Hi Ulrich,
>
> Thanks for your comments and feedback. Let me respond inline.
>
> On Mon, Jan 6, 2014 at 7:14 PM, Ulrich Herberg <[email-masked]>wrote:
>
>> Ines,
>>
>> 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:
>>
>> 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).

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

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

> 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.
>
>
> 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
>
>
>>
>> [2] J. Yi, T. Clausen, "Collection Tree Protocol for Lightweight
>> On-demand Ad hoc Distance-vector Routing - Next Generation (LOADng-CT)",
>> On Mon, Jan 6, 2014 at 10:24 AM, JP Vasseur (jvasseur) <
>> [email-masked]> wrote:
>>

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 8 Jan 2014 05:47:51 +0100

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

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

> solves this. Performance evaluations in [3] show the efficiency of the
The draft does not evaluate that protocol or possible solutions but it was
saying reactive.

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

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

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

>  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

---

From: Joydeep Tripathi <[email-masked]>
Date: Wed, 8 Jan 2014 15:19:35 -0500

Somehow this email did not make it to the WG mailing list. Sorry if you get
duplicate copy.

Hi Ulrich,

draft. Note that there may be example where a reactive protocol works for a

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

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.

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.

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.

Thanks & Regards,
Joydeep

---

From: Joydeep Tripathi <[email-masked]>
Date: Tue, 07 Jan 2014 02:27:37 -0000

Hi Ulrich,

Thanks & Regards,
Joydeep

---

From: Joydeep Tripathi <[email-masked]>
Date: Tue, 07 Jan 2014 03:01:26 -0000

Hi Ulrich,

Thanks & Regards,
Joydeep