Re: [manet] LOADng works

["JP Vasseur (jvasseur)" <[e-mail]>]

Hi Ulrich,

On Nov 2, 2012, at 1:22 PM, Ulrich Herberg wrote:

JP,

On Fri, Nov 2, 2012 at 10:09 AM, JP Vasseur (jvasseur) <[e-mail]<mailto:[e-mail]>> wrote:

On Nov 2, 2012, at 12:06 PM, Timothy J. Salo wrote:

>>>> JP> This is not just a question of "how large" it is … but also how
>>>> dynamic. I could show you few hundreds (if not less number of nodes)
>>>> not working if the traffic pattern is too dynamic. This is a
>>>> fundamental problem.
>
> No, it is a fundamental and well-known characteristic of reactive
> routing protocols.  It is a problem only when this behavior doesn't
> match the characteristics of the network in which the reactive routing
> protocol is deployed.

JP> Indeed … and this is why you have a fundamental issue with you have extremely high BER, PDR,
low bandwidth … as we do in LLNs. Flooding in these networks is driven by user traffic and of course
is highly undesirable. Slightly increase the use traffic and you will see the impact on the control plane ...


Yes, but as Timothy mentioned, there are cases where you don't have much user traffic.

JP> Then if you recognize that reactive routing is an issue when user traffic increases, this is a good start.
When do you put the limit ?
By the way, the topology is another argument, so does the bandwidth.

Let me be even more specific:
* Case 1: 75KBits/s, P2MP traffic (not referring to multicast), small broadcast domains, meter readout every 24h.
Certainly you can deploy a reactive routing protocol ? Still I do not see why you would not use a pro-active routing
but this is another question
Now what if you move to case 2:
* Unsolicited alarms using meters, DA, EV traffic for bill roaming ? Well you do not have
a major problem and when designing protocol we need to take this into account. Please see RFC

RFC 5548<http://datatracker.ietf.org/doc/rfc5548/>
(draft-ietf-roll-urban-routing-reqs<http://datatracker.ietf.org/doc/draft-ietf-roll-urban-routing-reqs/>)       Routing Requirements for Urban Low-Power and Lossy Networks     2009-05 RFC 5548 (Informational)                        Adrian Farrel
RFC 5673<http://datatracker.ietf.org/doc/rfc5673/>
(draft-ietf-roll-indus-routing-reqs<http://datatracker.ietf.org/doc/draft-ietf-roll-indus-routing-reqs/>)       Industrial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational)                        Adrian Farrel
RFC 5826<http://datatracker.ietf.org/doc/rfc5826/>
(draft-ietf-roll-home-routing-reqs<http://datatracker.ietf.org/doc/draft-ietf-roll-home-routing-reqs/>) Home Automation Routing Requirements in Low-Power and Lossy Networks    2010-04 RFC 5826 (Informational)
Errata<http://www.rfc-editor.org/errata_search.php?rfc=5826>                    Adrian Farrel
RFC 5867<http://datatracker.ietf.org/doc/rfc5867/>
(draft-ietf-roll-building-routing-reqs<http://datatracker.ietf.org/doc/draft-ietf-roll-building-routing-reqs/>) Building Automation Routing Requirements in Low-Power and Lossy Networks        2010-06 RFC 5867 (Informational)



* or Case 3 = Case 1 but with 5Kbits/s over PLC (at best) and number of hops >10. Try to compute the control plane
overhead with reactive routing, you will see.

This is well known. If you have more user traffic, then you may need a proactive protocol. You may not like the idea that some people actually deploy reactive protocols in LLNs, but it's a fact.

JP> Once again, people are free to deploy whatever they want - REQUESTING the IETF to standardize it is different.

And your argument, again, makes no sense that you think that DYMO is suitable and LOADng is not.


JP> I never asked from dropping reactive routing from the MANET charter (I opted for option 1 not 3).


>
> We've known for at least 15 years that reactive routing protocols are
> more appropriate for light traffic loads and that proactive routing
> protocols are more appropriate with heavier traffic loads.

JP> This is over-simplying but I see what you mean.

> Dozens,
> probably hundreds of research papers have reiterated this result.
> I don't know of any that have contradicted this result, although
> some researchers have tried to develop hybrid routing protocols
> (which don't seem to have gained much traction, either in the IETF
> or elsewhere).
>
> Claiming that reactive routing protocols don't scale to heavier traffic
> loads is neither a new result nor particularly insightful -- this hasn't
> changed for at least 15 years.

JP> Let me restate my point. Not sure of what you mean by "heavier" … but if you
flood the network with probes each time you need to find a path in a LLN you have
a major problem.

Well, if you have few communication streams, the few floods are much less heavy than having a proactive protocol exchange control traffic all day.

JP> Please careful read RFC6550 and companion documents, this is not what the protocol does.
But we can take it off-line, this is not the right mailing list.

Again, no argument in favor for DYMO and against LOADng. Note also that you only talk about LLN, but we are the [manet] WG.


Of course, there are many ways to control flooding, use caches ..
that are all well-known and by the way hard to tune. But overall, reactive routing in
*these* networks is simply ill suited.

>
> I haven't seen any evidence that _no_ LLN will experience the sort of
> light traffic load that matches the characteristics of a reactive
> routing protocol.  To the contrary, the deployment experience with
> LOADng suggests that such do networks exist.

JP> Once again it all depends on the traffic profile. Of course you could make a
reactive routing protocol work on a LLN as long as the user traffic has specific
characteristics.


Exactly! Thanks for pointing that out. That's the whole point why [manet] is chartered to do both reactive and proactive protocols.


JP> Again I am not saying that reactive cannot be very useful in some environments *but* not in LLNs.


If you carefully analyze the user traffic characteristic in networks
such as smart metering (since this was mentioned on this list), and you incorporate
additional applications such as DA, .. to mention a few, you will see that in most of
these networks this simply does not work … too many flooding, ending up not even
converging in some cases, especially when the number of hops gets high with poor
link quality.

You are not bringing up any new argument that is not known to [manet] for the last 15 years. Reactive protocols only work for certain scenarios. We know that. We have never disputed that.

JP> Excellent; the only difference is that now we have large scale deployed LLN, so we much better understand the dynamics
and why a protocol such as Load-ng is ill suited to these networks.




>
> At the risk of arguing by analogy, the argument that one can "prove"
> that reactive routing protocols don't work (in LLNs or elsewhere) seems
> to  make about as much as sense as "proving" that OSPF doesn't work
> because it doesn't behave well in dynamic environments.  The failure of
> OSPF in dynamic environments didn't cause us to abandon OSPF: there are
> many environments in which it works well.

JP> Not sure that I would have used this analogy :-( OSPF was not designed for highly
dynamic environment indeed *but* we could easily enhance it with fast failure detection
(+ BFD), fast LSA generation, fast SPF and incremental SPF, Local Fast Reroute, …
because routers had lot of resources, links were highly stable, … which is by far not the
case of LLNs.

> Rather, we concluded that we
> needed another routing protocol.  In a similar manner, the MANET
> working group, and as far as I have seen pretty much all of the
> research community, concluded that there is a need for both a
> reactive routing protocol and a proactive routing protocol.
>
> Of course, the ROLL working group can decide not to standardize
> a reactive routing protocol.  However, that doesn't prove that
> reactive routing protocols don't work (when they match the
> traffic characteristics of the network), that reactive routing
> protocols won't work better than proactive routing protocols
> in some LLNs (based on the characteristics of the traffic load),
> or that reactive routing protocols won't be successfully deployed
> in LLNs.

JP> Well … Think about this: when ROLL was formed, the IESG explicitly and rightfully asked
the WG to first prove that none of the existing protocol could be used, before standardizing a
new protocol (that was the right choice !!).


Right, but that "proof" was never published by the IETF, and as such only an assertion. Moreover, we are not the ROLL WG.


JP> I was giving you some feed-back, since LLNs are explicitly listed in the Load-ng document.


Could then prove that the current protocol cannot be used in your environment before suggesting
to standardize a new one.

Once again, if not applicable to LLNs, I have no problem whatsoever.


People have deployed reactive protocols as a matter of fact in LLNs. So, is the only reason why you like DYMO and not LOADng, because LOADng mentions the word LLN once in the introduction?

JP> Not at all. I was proposing the following:

1) Build a reactive routing for MANET
2) Start with the WG document (DYMO), call it AODVv2 to avoid conflicts,
3) Add all ideas that we (as a WG) want to keep that came from Load-ng and any why not new ideas
4) Identify what can be made optional versus mandatory
5) Move fast, in a constructive collective fashion.
Makes sense ?

Thanks.

JP.


Best regards
Ulrich



> If fact, the LOADng deployment experience strongly
> suggests that reactive routing protocols _will_ be deployed in
> some LLNs.  And, they will be deployed regardless of the ROLL
> working group's decision to not standardize a reactive routing
> protocol.

JP> And this is perfectly fine, people are free to use any protocol they want, including proprietary
ones. This does not mean that the IETF should standardize them.

>
> Claiming that reactive routing protocols don't work because they
> don't scale to higher traffic loads seems,

JP> Then we need to characterize precisely the limits.

> at best, a poor
> characterization of well-known research results, and at worst
> a distraction from the question at hand: namely how to proceed
> towards an Internet-standard reactive routing protocol.
>
> -tjs

_______________________________________________
manet mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/manet