Re: [manet] MANET meeting at IETF85

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Mon, 15 October 2012 06:28 UTC

Return-Path: <jvasseur@cisco.com>
X-Original-To: manet@ietfa.amsl.com
Delivered-To: manet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7626021F85C3 for <manet@ietfa.amsl.com>; Sun, 14 Oct 2012 23:28:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.403
X-Spam-Level:
X-Spam-Status: No, score=-10.403 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9YsDRM0L7tL for <manet@ietfa.amsl.com>; Sun, 14 Oct 2012 23:28:17 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id AAEC921F85A8 for <manet@ietf.org>; Sun, 14 Oct 2012 23:28:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25018; q=dns/txt; s=iport; t=1350282496; x=1351492096; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BazFnnvhJMslVO9DMK06RGfJH0dMwQ+1rqVUzoqyw+Y=; b=h1wR2g6XT+oPfZB2yHPlz+NAYowgx35kyhhlP+9UszxPKDp4uqvIZovU fiGO+3GPvBvp/KkWNBDgyWzn0GfpSYmKtViqx5Medj9P4Fc9W75pwWArK CvE8MyOEqdlfBkT/tWtzEEoGiLdmesX6eiihIxQb8BVVBckftAZKveSNy Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhQFAJ6re1CtJV2Y/2dsb2JhbABFtxYBiGCBCIIhAQEEAQEBDwFYAwIJEAIBCCIdBycLFBECBA4FCAwFCYdiC50qnyCLWRQGAYVCYAOXAY0wgWuCbYFaCTQ
X-IronPort-AV: E=Sophos; i="4.80,587,1344211200"; d="scan'208,217"; a="131325244"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP; 15 Oct 2012 06:28:15 +0000
Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9F6SFN5016339 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Oct 2012 06:28:15 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Mon, 15 Oct 2012 01:28:15 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: Ulrich Herberg <ulrich@herberg.name>
Thread-Topic: [manet] MANET meeting at IETF85
Thread-Index: AQHNqdqPxQdayxYbx0aw5eRdXfbe8w==
Date: Mon, 15 Oct 2012 06:28:14 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A7721FE083C@xmb-rcd-x02.cisco.com>
References: <CAK=bVC8EPURNU7yQqsckzSXoxXP-xP_pOSHSd1fepQ30Y2pC-A@mail.gmail.com> <CADnDZ8-xwpk8rewCYOVxWSJVkU3jf1dw+D=VrZVF6hxYtTGVYg@mail.gmail.com> <54F3B19D-4657-4AA3-B323-25F407357EB3@cisco.com> <ADAF144E-8A9E-4808-8203-0438C4A89899@cisco.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D24F7841F@GLKXM0002V.GREENLNK.net> <318ECCCC-3DCD-46C8-8D0F-95AEBAE9D468@inf-net.nl> <2ED1D3801ACAAB459FDB4EAC9EAD090C0F404E40@xmb-aln-x03.cisco.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30D24F7849C@GLKXM0002V.GREENLNK.net> <CFDBF585-8FC9-4569-9248-C51302EECC07@herberg.name> <B3AF1549-D185-46A9-995E-566C9D2E877B@inf-net.nl> <29959252-16D7-470C-96A5-05E70D218849@watteco.com> <CAK=bVC8XX=CRHmiHfO83ZbHz-rRDj2DcSbuPmjKnd-5JCjH0oQ@mail.gmail.com> <546B80D0-7AA7-4320-B28A-AC6059C6084E@watteco.com> <CAK=bVC_ehKiFh_R0whYCLf2Gf+9kbaf-xr=9rPnSxs3jgiVFEQ@mail.gmail.com> <03B78081B371D44390ED6E7BADBB4A7721FD99E1@xmb-rcd-x02.cisco.com> <D14600E7-B21E-454B-90A8-8C29060523F9@herberg.name> <03B78081B371D44390ED6E7BADBB4A7721FDC303@xmb-rcd-x02.cisco.com> <CAK=bVC8UTbDPp=rDQYYBHZYLNbFvSbYW_z12-bLR1x7HXWFzSA@mail.gmail.com>
In-Reply-To: <CAK=bVC8UTbDPp=rDQYYBHZYLNbFvSbYW_z12-bLR1x7HXWFzSA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.60.114.231]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19274.004
x-tm-as-result: No--53.059400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A7721FE083Cxmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Stan Ratliff (sratliff)" <sratliff@cisco.com>, "<manet@ietf.org> List" <manet@ietf.org>, "Bo Berry (boberry)" <boberry@cisco.com>, "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
Subject: Re: [manet] MANET meeting at IETF85
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/manet>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Oct 2012 06:28:18 -0000

Hi Ulrich,

On Oct 15, 2012, at 2:57 AM, Ulrich Herberg wrote:

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.

JP> Here we do not disagree at all. I am not saying that reactive protocols are not appropriate in a number of scenario. All I am saying is that *if* you intent to specify
a reactive routing protocol for LLNs, knowing the years of intense work and efforts of the ROLL WG, then it should be discussed with a wider audience. On the other
hand, if your explicitly exclude LLNs from your protocol in your protocol, it is no longer required to involve the ROLL WG. The objective is simply to avoid WG charter
overlap but more importantly try to benefit from the benefit of experts in the area of LLNs to build a good protocol for the Internet.

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.

JP> No, this your recollection of the discussion. "less-focussed" or "de-emphasize" was I think your interpretation. Mine was "not referring to LLNs" at all.
Otherwise, it should be reviewed by both WGs (to be discussed between chairs and AD).

Thanks.

Best Regards.

JP.


Best regards
Ulrich


On Sun, Oct 14, 2012 at 9:13 AM, JP Vasseur (jvasseur) <jvasseur@cisco.com<mailto:jvasseur@cisco.com>> 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)" <jvasseur@cisco.com<mailto:jvasseur@cisco.com>> 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 <c.chauvenet@watteco.com<mailto:c.chauvenet@watteco.com>> 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
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet