Re: [manet] MANET meeting at IETF85

[Ulrich Herberg <[e-mail]>]

Hi JP,

I think this discussion diverges into a comparison proactive vs. reactive
protocols. I do not doubt that you can show me proof that in certain
scenarios, reactive protocols perform poorly. I can do the same exercise
for proactive protocols in other scenarios. MANET has gone though that
about 10 years ago, and decided that "no-one-size-fits-all", but rather
that we were chartered to produce a std. track reactive protocols *and*
a std. track proactive protocol.

And I think this is the most important argument in this discussion: MANET
is chartered to come up with a reactive protocol for MANETs. And I believe
it is a good idea to mention in which deployments a specification is used.
It was also agreed at the last MANET meeting that if LOADng was to be
considered for MANET, it needs to de-emphasize LLNs (which I have not heard
anybody disagree with so far). So I don't understand what we are even
discussing here.

Best regards
Ulrich


On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jvasseur)
<[e-mail]>wrote:

>  Hi Ulrich,
>
>  On Oct 14, 2012, at 5:12 PM, Ulrich Herberg wrote:
>
>  Hi JP,
>
> On Oct 14, 2012, at 0:07, "JP Vasseur (jvasseur)" <[e-mail]>
> wrote:
>
>  Hi Ulrich,
>
>  On Oct 14, 2012, at 3:13 AM, Ulrich Herberg wrote:
>
> Hi Cédric,
>
> On Sat, Oct 13, 2012 at 11:16 AM, C Chauvenet <[e-mail]>wrote:
>
>> [...]
>>
>>
>>  The distinction between MANET and LLNs seems to be vanish here.
>> This brings us back to the summer discussion between what is a MANET and
>> what is a LLN that did not really fostered on a consensus.
>> WG chairs could help there, as it is their related scope.
>>
>
>
>  I am not suggesting to revive a discussion of the definition of a MANET
> vs LLN.
>
>
>  JP> Mei neither - this is why, if you suggest to indicate the
> applicability of the protocol in the document which makes total sense, the
> WG should exclude LLNs from
> this ID explicitly.
>
>
>
>  I disagree. How can we exclude it from the document when it is as a
> matter of fact used in LLNs?  I am just saying that if LOADng is to be
> accepted by the WG, it has been clearly expressed in the last meeting that
> it is too focused on LLNs, and should instead focus on the general MANET
> case. I agree with that. Mentioning one, out of many use cases, in
> particular when people actually deploy it in that use cases seems just
> fair, and does not cause any overlap between two working groups.
>
>
>  JP> This is your interpretation of the last discussion - please discuss
> with the WG chairs of ROLL and MANET. We have the mandate to design one
> protocol for
> LLN at the IETF, which leads to no overlap. If you think that the protocol
> designed by the IETF (RPL) does meet the requirements, and you would like
> to see some
> improvements, then you are extremely welcome in ROLL, to keep improving
> it. As a matter of fact, there are now several large scale deployments in
> production but
> again we can keep improving it. The "too focussed" is your interpretation,
> I do no agree with it at all. Actually there are papers available showing
> why using Load-ng
> may lead to serious issues in LLNs; we need to be cautious and conscious
> on these issues for the best of the Internet.
>
>
>
>
>
>  I did not bring up this discussion. All I am saying is that MANET is
> chartered to come up with a reactive protocol. And I believe it should be
> allowed to mention where a protocol is used in deployments.
>
>
>
>
>>   My vision is that LLNs are more constrained than MANET for the
>> following criterion : Power consumption, Loss of the media, Computation
>> capability, Throughput.
>> What do you think ?
>> My vision is also that the level of constraints of LLNs should not be
>> considered in a MANET protocol.
>> Do you agree ?
>>
>
>
>  Since you ask here...In my personal opinion,  LLNs are a 100% subset of
> a MANET. Both are usually multi-hop, often wireless, with constrained
> routers, in many cases incoming packets leave a router on the same
> interface that they have been received on, and the topology is dynamic.
>
>
>  JP> Well, in this case, pushing your reasoning a bit further, this may
> very well apply to OSPF, ISIS, … too.
>
>
>
>  These protocos don't cope well with lossy channels and dynamic topology
> changes.
>
>
>  JP> I am sure that yo understood the analogy, I was not proposing to use
> OSPF and ISIS … these were example to show that your characterization was
> not a compelling
> argument.
>
>
>   I clearly do not think that LLNs are 100% subset of MANET; there is a
> tremendous difference between several dozens of highly constrained fixed
> routers interconnected
> by very lossy links providing a few KBits/s and several hundreds of
> routers with high mobility interconnected by Wifi links.
>
>
>  Nobody ever said that MANETs are interconnected by wifi only, or
> anything about limited size of the network (quite the contrary, they are
> intended to be very large). Also, MANETs such as Funkfeuer are non-mobile.
>
>
>  JP> I was giving an example ...
>
>
>
>  MANETs, IMO, have a larger range of "constrained routers", from very
> constrained routers (e.g. LLN) to somewhat constrained routers (e.g.
> community networks) to non-constrained routers (e.g. certain military
> deployments). LLN is focused on extremely constrained devices.
> However, I don't say that we should revisit the way how the Routing Area
> distributed the tasks in the WGs, nor do I suggest to change the charters.
>
>
>  JP> IF that were the case, we would not have formed two WG but one.
>
>
>
>  I don't want to go in there.
>
>
>
>
>
>
>>
>>  I'm trying to figure out if LOADng is efficient over a mains-powered
>> computer using Wifi, a 8K/48K RAM/ROM device,  or both (cover such a wide
>> range would be magical !).
>>
>
>  I cannot answer this question, as I have not deployed LOADng on a 8K/48K
> RAM/ROM device. Those who have deployments and are willing to disclose
> details, may have more details. Just one comment: I have implemented
> numerous ad-hoc protocols (OLSRv2, LOADng, RPL, DSDV, ...). LOADng is by
> far the simplest to implement and has the least lines of code (by far)
> compared to all these other protocols that I have implemented. If you can
> run any of these beforementioned protocols on such a device, you can
> certainly run LOADng on it.
>
>
>  JP> I wish life was so simple … The argument around simplicity is a
> recurring one. And unfortunately, simple protocols do not always WORK … I
> could actually show
> you, taking real-life networks (no simulation), how a (simple) reactive
> routing protocol would break in a LLN.
>
>
>
>  As a matter of fact, there are large-scale deployments of LOADng by
> industry. If LOADng was not working, I doubt that there would be any money
> spent on that.
> And your last argument is not helpful; I am convinced that for any
> Standards Track routing protool, I can show you scenarios where it breaks
> (whereas in other scenarios it works fine).
>
>
>  JP> Then let's justify carefully why and when the current standard does
> not meet the requirements, see how we can improve it if needed and then in
> a second step
> seek of another protocol if required. Once again I am ONLY referring to
> LLNs, not other types of networks.
>
>  Best Regards.
>
>  JP.
>
>
>  Best
> Ulrich
>
>
>
>
>
>
>
>>
>>  I see in the interop report
>> http://tools.ietf.org/html/draft-lavenu-lln-loadng-interoperability-report-02 in
>> section 3 :
>>
>> [...]
>>
>> So my first guess is that LOADng is suitable for what I called
>> "mains-powered computer using Wifi" ?
>>
>
>
>  I think Jiazi has already replied to that in a later mail. Interop !=
> performance test. LOADng (like any other MANET protocol) can run on any
> medium. Testing it on wifi is a simple thing to do. Interop tests are
> solely to find out if messages can be parsed correctly, and if the
> implementations behave according to the specification.
>
>  As Jiazi pointed out correctly, I don't understand why we have this
> discussion before you have seen the latest LOADng revision.
>
>  Best
> Ulrich
>
>  _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>
>
>
>