Re: [manet] LOADng works

[Jon Black <[e-mail]>]

What so now you want the draft to explicitly state that it cannot be used in a LLN?

This is beside the point of any technical discussion related to the two drafts.

This group should stop getting sidetracked (and I have been also) on the wrong topic.  We need to look at the two drafts and determine which is the best to continue to put working group effort behind.

Charlie has indicated and is working to improve DYMO.  This is great.

Ulrich and others have been making updates to LOADng.

This WG should read both draft with an eye on which is closer to implementation, stability and has the technical features for a Manet reactive protocol.

The issue is not about could someone use whatever Manet publishes as reactive protocol in an LLN.  Lets stop getting distracted from the necessary discussion.

I've read both drafts.  I find the LOADng draft more concise, and something I can implement.  I find the DYMO draft less understandable, many more options and not in a state that I could try to write code to implement it.

I obviously feel strongly that we should use LOADng as the basis for the reactive protocol from Manet - what ever the name eventually is (I don't care) and whatever the eventual applicability.

To Joe and Stan, I really do think that we are not far from agreement (save for few) if we look at the discussion with a filter on just the technical merits of the two drafts and eliminate the rhetoric around where people can choose to use the protocol.

Jon




________________________________
 From: JP Vasseur (jvasseur) <[e-mail]>
To: Jon Black <[e-mail]> 
Cc: Ulrich Herberg <[e-mail]>; Timothy J. Salo <[e-mail]>; "[e-mail]" <[e-mail]> 
Sent: Saturday, November 3, 2012 2:18 AM
Subject: Re: [manet] LOADng works
 

Once again you always restart from scratch ignoring emails - I was providing you the rationale on why you cannot use one 
deployment of LLN (not even knowing any details) to claim that the protocol actually works, this is in reply to Ulrich's email.
If indeed, MANET designs a reactive routing protocol for MANET including LLNs, since it was (finally) said that this could work 
in very specific (restrained) conditions, otherwise we would need to use the protocol the IETF has designed for LLN (RFC6550 
and companion) then let's specifically remove LLN (not implicitly, by removing a section or chaining a name) from the protocol 
designed in MANET, and use that protocol (RFC6550) for LLNs.


On Nov 2, 2012, at 5:23 PM, Jon Black wrote:

see line [Jon]
>
>
>
>
>
>
>________________________________
> From: 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]> 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 
>(draft-ietf-roll-urban-routing-reqs) Routing Requirements for Urban Low-Power and Lossy Networks 2009-05 RFC 5548 (Informational)   Adrian Farrel 
>RFC 5673 
>(draft-ietf-roll-indus-routing-reqs) Industrial Routing Requirements in Low-Power and Lossy Networks 2009-10 RFC 5673 (Informational)   Adrian Farrel 
>RFC 5826 
>(draft-ietf-roll-home-routing-reqs) Home Automation Routing Requirements in Low-Power and Lossy Networks 2010-04 RFC 5826 (Informational) 
>Errata   Adrian Farrel 
>RFC 5867 
>(draft-ietf-roll-building-routing-reqs) Building Automation Routing Requirements in Low-Power and Lossy Networks 2010-06 RFC 5867 (Informational)
>
> 
>
>[Jon] Which RFC?  Do you mean RFC 5826 or 5867 both of which seem to need RPL P2P which looks like a new protocol?  Do you mean RFC 5548 which seems to be the use case from EDF that is using a reactive protocol (LOADng), or RFC5673 which no one has tried.
>
>Just because something was designed to do something you can't claim that it actually will do it.  The Titanic was designed to be unsinkable...  But I digress, since you did.
>
>It does appear that your objection is the name ('cause it could confuse someone into think they could use this manet protocol in an LLN - which as you said was their choice) and that there is one small paragraph there it says that they might be able to use
 this protocol in their LLN.
>
>Really, this is what all the hub-bub is about.  After all they really are both AODV++.  So we find a new name and remove one paragraph.
>
>I think now the debate is what is the proper base from which to start.  Which document is clearer, and more stable.
>
>Jon
>
>
>
>
>
>