Re: [Roll] AMI applicability: storing/non-storing.

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 04 November 2013 21:47 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B03721E816D for <roll@ietfa.amsl.com>; Mon, 4 Nov 2013 13:47:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level:
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_MARKET=2.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXIGEHrWasAO for <roll@ietfa.amsl.com>; Mon, 4 Nov 2013 13:47:22 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4BF11E8163 for <roll@ietf.org>; Mon, 4 Nov 2013 13:47:22 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5D0F9E0B7 for <roll@ietf.org>; Mon, 4 Nov 2013 17:58:55 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 5FD6C63B88; Mon, 4 Nov 2013 16:47:17 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52D6163AED for <roll@ietf.org>; Mon, 4 Nov 2013 16:47:17 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
References: <23764.1375904475 at sandelman.ca>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 04 Nov 2013 16:47:17 -0500
Message-ID: <13540.1383601637@sandelman.ca>
Sender: mcr@sandelman.ca
Subject: Re: [Roll] AMI applicability: storing/non-storing.
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Nov 2013 21:47:26 -0000

{I deleted this email by mistake from my inbox, so I had to go back to the
archive to get a copy of it}
The original thread is here:
   http://www.ietf.org/mail-archive/web/roll/current/msg08082.html

I asked about:

    >> As a result, different AMI deployments can vary significantly in terms
    >> of memory size, computation power and communication capabilities.  For
    >> this reason, the use of RPL storing or non-storing mode SHOULD be
    >> deployment specific.  When meters are memory

   mcr> a manufacturer that wishes to make meters for more than one
   mcr> market/RFP would nee d to put in enough memory for the worst case
   mcr> storing situation.  So the advice here is empty. And how many
   mcr> routes is enough?

Daniel gave a well written overview of the considerations about how much ram
to use, and I can't disagree with any of it.  The thing is, one of the
purpose of the applicability document it to make it clear how to use RFC6550
in a particular situation.  There are very very very real needs for a
document (specificallly, a "performance specification" to use language from
trade agreements) that can be used to procure product.  This is what we are
here for: to write specifications.

It seems to me that the AMI applicability statement is still overbroad in
scope if it is not possible to answer the question of storing or non-storing.

As such, in order to progress here, I think that we need to define clearly
what kind of network we are talking about here.  If that excludes some
network that someone cares about, then we need another document.  

Let me suggest some constraints.
1) lets deal with powered electric meters only as routers
   (unpowered meters -- water -- which operate on batteries may be leaf nodes
   only)

2) lets deal with (sub-)urban housing densities. (so this rules out 47 story
   apartment buildings in Manhatten until someone either writes another
   document, or shows that the numbers we picked will work)

3) let's decide on storing mode and decide upon 64 route entries, 
   and see what happens for the 1000 nodes described in the Cisco experience document
      http://tools.ietf.org/html/draft-hui-vasseur-roll-rpl-deployment-01

(I'll bet somehow has simulator published results that support or update this
analysis):

 - 51% of nodes were 1 hop away
 - 30% of nodes were 2 hops away, etc...

100-51% of 1000 = 490 nodes need to be reached by a 1st rank node.
There are 510 first rank nodes, so on average each 1st rank node needs to
have 1 route entry for one of the 490 downstream nodes.  That's << 64!

(I assume that the root node is special, and has more capacity)

Based upon another diagram I saw about how meters might mesh down a street in
a linear fashion, and taking my street as an example (my meter is smart, but
not IPv6), there are approx 12 houses on my side of the street on my side of
the block.  So, the house nearest the root needs 12 routes, and the depth of
the three is 12.   I assume that the ETX across the street or onto next block
is too poor to bother.

I'm not claiming that my numbers are sane, I'm just saying that we absolutely
need to have a number here.

    Daniel> memory resources, and so on. As an example, although an AMI
    Daniel> platform for US mar ket is sharing some in common with an AMI
    Daniel> platform for EU market, their requirem ents/constraints,
    Daniel> functionalities and applications can be significantly differen t.

Then, let's please write two documents.

I also want to point out, if one has power, then number of bits on the wire
might not matter as much, and non-storing mode may be good.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [