Re: [manet] LOADng works

"JP Vasseur (jvasseur)" <jvasseur@cisco.com> Sat, 03 November 2012 08:18 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 B5F7D21F9495 for <manet@ietfa.amsl.com>; Sat, 3 Nov 2012 01:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.398
X-Spam-Level:
X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, 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 lnXKh11LK9zK for <manet@ietfa.amsl.com>; Sat, 3 Nov 2012 01:18:09 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C979421F842B for <manet@ietf.org>; Sat, 3 Nov 2012 01:18:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19489; q=dns/txt; s=iport; t=1351930688; x=1353140288; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UPTHCPR8Fl1/CIlNCxmAkuQ6TDhaELjIlKrxMXiOz8k=; b=IDGk6iuvqe6m/D7iYpiQToEPXbBYMVnXGBC00/9qSSBs+1P0gd44QiBN nk/s+pbtZUtyevzYJPDdM49oBJHXNJmeTpCRVSNpejZYPCxhl3PPx36oX faJqNh6P9IGkMit9wWXV9APbEd/GEab0dzbJnfwRiJ81YciOot/2Ttc+7 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAKTSlFCtJXHA/2dsb2JhbAAqGoJJwGqBCIIeAQEBBBIBZhACAQgOBw0LEgcyFBECBA4FCBqHaAstm1WfeIwBFQaCcIJQYQOXF409gWuCb3JqCBce
X-IronPort-AV: E=Sophos; i="4.80,704,1344211200"; d="scan'208,217"; a="138413357"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 03 Nov 2012 08:18:08 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qA38I82p021844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 3 Nov 2012 08:18:08 GMT
Received: from xmb-rcd-x02.cisco.com ([169.254.4.118]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.001; Sat, 3 Nov 2012 03:18:07 -0500
From: "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
To: Jon Black <jblack.ietf@yahoo.com>
Thread-Topic: [manet] LOADng works
Thread-Index: AQHNuF9dW2UMul6sMEaXNf6TARakEQ==
Date: Sat, 03 Nov 2012 08:18:06 +0000
Message-ID: <03B78081B371D44390ED6E7BADBB4A772204D692@xmb-rcd-x02.cisco.com>
References: <1351706263.11550.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220464DA@xmb-rcd-x02.cisco.com> <1351726777.19955.YahooMailNeo@web160602.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A77220486F0@xmb-rcd-x02.cisco.com> <1351783936.31212.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A7722049540@xmb-rcd-x02.cisco.com> <1351828308.94489.YahooMailNeo@web160601.mail.bf1.yahoo.com> <03B78081B371D44390ED6E7BADBB4A772204AAED@xmb-rcd-x02.cisco.com> <5093EF93.70201@saloits.com> <03B78081B371D44390ED6E7BADBB4A772204C49F@xmb-rcd-x02.cisco.com> <CAK=bVC8dtnAFkg3Q=pAbU0P0c4rOY0sDfDi9z3bKNj9sAKjV5A@mail.gmail.com> <03B78081B371D44390ED6E7BADBB4A772204C845@xmb-rcd-x02.cisco.com> <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com>
In-Reply-To: <1351891402.40332.YahooMailNeo@web160605.mail.bf1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.21.147.169]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19336.001
x-tm-as-result: No--55.665500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772204D692xmbrcdx02ciscoc_"
MIME-Version: 1.0
Cc: "Timothy J. Salo" <salo@saloits.com>, "manet@ietf.org" <manet@ietf.org>
Subject: Re: [manet] LOADng works
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: Sat, 03 Nov 2012 08:18:10 -0000

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) <jvasseur@cisco.com<mailto:jvasseur@cisco.com>>

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) <jvasseur@cisco.com<mailto:jvasseur@cisco.com>> 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)



[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