Re: [manet] LOADng-06

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

Dear Ulrich,

Let me chine in since I do not think that we are in agreement with your conclusions here - see below

On Oct 23, 2012, at 4:49 AM, Ulrich Herberg wrote:

Hi Bo,

On Mon, Oct 22, 2012 at 6:39 PM, Bo Berry <[e-mail]<mailto:[e-mail]>> wrote:
Hi Alex

For those of us that have not have the opportunity to follow
the Loadng discussions, could you please describe the similarities
and the unique differences of Loadng relative to Dymo.  I'm aware
of the discussions about lousy nets and manets, but less between
the two protocols.

I think this would help everyone on the WG understand the benefits.


I agree with that, and it is a fair question to ask. Let me try to list a few differences, others may chime in with more.

First the commonalities:
 - Both are reactive protocols, based on AODV, with the intended status of "Proposed Standard" (AODV is "Experimental"). The MANET charter lists that the WG has to come up with a std. track reactive protocol. Essentially, in a reactive protocol, routes are requested "on-demand" (i.e. when there is data traffic and no route exists for the destination of the data packet). Therefore, you will see similar message types in both protocols (Route Requests, Route Replies, and Route Errors), and essentially the same basic mechanism.

JP> It is worth that MANET has already a WG document, DYMO, which has been discussed extensively in the WG.

- Both are applicable to MANETs (see also below for your next question), and both support RFC5444. LOADng is decoupling the mechanism from the message format; RFC5444 is mapped to the mechanism, but other message formats could easily be specified (e.g., with a more compressed message format for extremely limited links in terms of bandwidth).

Now some differences:
- Most importantly: LOADng has achieved what DYMO failed to do: to gather broad industrial support from several large companies, several large-scale deployments with several thousands of nodes, LOADng has an updated MIB document, and documented interoperability test of at least four recent implementations.

JP> If I may, this is more of a Marketing comment though. I do not think that DYMO failed in any way. It turns out that the timing was different, that's all.

- Part of the reason, I believe, is that the writing style is very different. LOADng has a more algorithmic way of writing. That's immediate to see when you compare section 5.3 of DYMO with section 12 of LOADng. It is, IMO, much harder to implement DYMO. The goal for LOADng was to make it so straight forward to implement that an undergrad student could take the spec, spend a few days implementing it and have a reasonable and interoperable implementation. I have implemented LOADng in one day, based on the specification.

JP> I personally saw several implementations of DYMO, and if we require more algorithmic details about DYMO, let's provide comments to the DYMO
authors.

- There are multiple optional features in DYMO that have deliberately not been included in LOADng (expanding ring multicasts, intermediate RREPs, precursor lists etc). The reason was the following: in an experimental protocol (AODV) it is fine to have many options, in order to explore whether they are useful. We have that experience now with AODV. For some of the options, such as iRREP, it has not been shown over the last decade that they are of general use. In some cases, they may be beneficial, but not in general. Also, they make it very hard to provide end-to-end security. LOADng kept the mantra of a small, slim, and efficient protocol. Having many options makes it hard to assure interoperable devices out of the box, in particular if there is no negotiation of capabilities.
Moreover, reactive protocols are often used in cases where memory is an extremely scarce resource, and where proactive protocols cannot be used. That makes a slim design preferable, IMO, for such protocols.

JP> We can discuss further in Atlanta, but several of these options are IMO quite useful.

- LOADng may be used in other layers as L3, e.g. as mesh-under protocol.

JP> Another concern … If you plan using LOAD-ng as a mesh under protocol, this requires much more discussion (not sure that such discussions
should take place at the IETF, but because this would be an IETF work, we would need to discuss it further). Indeed, proposing to standardize a
mesh-under protocol is not just a matter of manipulating MAC addresses instead of IP addresses: there are tons of implications of the architecture,
as described in details in http://tools.ietf.org/html/draft-routing-architecture-iot-00

- LOADng supports optimized broadcasting mechanisms such as MPR flooding
- There is no Route Reply ACK in DYMO; this is part of LOADng to verify bidirectionality of links; as in wireless channels, links are rarely symmetric.


JP> Let's discuss further about these optimizations, which if needed, could be added to DYMO.


Looking at the Tools page, the draft was first submitted October 24, 2011,
draft-clausen-lln-loadng-00.  The title was, "The LLN On-demand Ad hoc
Distance-vector Routing Protocol - Next Generation (LOADng)."  The
abstract included the statement "The protocol is derived
from AODV and extended for use in LLNs".

Then in the July 14, 2012 version, draft-clausen-lln-loadng-05, the
line "The protocol is derived from AODV (RFC3561) and extended for
use in LLNs." was removed.  This version also supported RFC 5444.

The draft posted tonight, October 22, 2012, draft-clausen-lln-loadng-06,
for the most part changes "Low power and Lossy Networks (LLN)"
references to "Mobile Ad hoc NETworks (MANETs)."


The draft started out from where the deployments exist, which some call LLNs.

JP> As pointed out earlier, then I have two major concerns:
1) If the reactive routing protocol deals with LLNs, especially "hard constrained" LLNs as pointed out in this mailing list,
then I would strongly suggest to run the document by the two WGs, MANET and ROLL. Let's see what the chairs decides.
2) ROLL co-chair hat-off, I do see a number of issues using reactive routing in hard constrained LLNs such as AMI PLC,
years of experience in routing in such networks show us that there are major scalability issues (I am not referring to the number
of nodes, but also user traffic since depending on the user traffic this may lead to massive control plane traffic churn to mention
one of the many issues).

However, as a basic reactive protocol, LOADng also covers the more general MANET case that includes a wider ranger of resources (from extremely constrained to not-so-constrained) and mobility. In particular, by supporting RFC5444 it fits well in the MANET architecture and the surrounding security extensions, flooding optimizations and TLVs etc. for RFC5444.

I hope I could shed some light on that question. I invite you to read both drafts, there is probably more to say here.

I won't go into details here, but most of the discussions we had were not so much about technical issues, but about procedural. LOADng has started when DYMO was stalled for more than 2 years. I think we have a well mature document, supported by strong industry backing and running code.

JP> I do not make this email took polemical but you also have strong industry disagreement in using such protocols for extremely
constrained LLNs to say the least.

Thanks.

JP.

The latter is crucial in the IETF.

Best regards
Ulrich




Thanks
-Bo



On Oct 22, 2012, at 8:03 PM, Axel Colin de Verdière wrote:

> Dear all,
>
> we have updated LOADng, to make it clear that it is in scope and charter for MANET. Unfortunately, it is only a minor revision of the technical content, since we have been in discussions with the DYMO authors and the WG leadership for several months on how to proceed with the reactive protocol in MANET. The chairs will likely reply very soon to the list with an outcome of the discussion.
>
> Best regards,
>
> Axel Colin de Verdiere
>
> _______________________________________________
> manet mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/manet

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

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