Re: [coman] are we there yet?

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 14 March 2013 17:33 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: coman@ietfa.amsl.com
Delivered-To: coman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3259F21F8D31 for <coman@ietfa.amsl.com>; Thu, 14 Mar 2013 10:33:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.249
X-Spam-Level:
X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 dDQNXvv8vIVJ for <coman@ietfa.amsl.com>; Thu, 14 Mar 2013 10:33:40 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id A480021F8D17 for <coman@ietf.org>; Thu, 14 Mar 2013 10:33:39 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08FA320BFE; Thu, 14 Mar 2013 18:33:39 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NlBZr2Kw5jsM; Thu, 14 Mar 2013 18:33:38 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6784F20BDE; Thu, 14 Mar 2013 18:33:38 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1A22924FCEE3; Thu, 14 Mar 2013 18:33:50 +0100 (CET)
Date: Thu, 14 Mar 2013 18:33:50 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Carsten Bormann <cabo@tzi.org>
Message-ID: <20130314173350.GA18524@elstar.local>
Mail-Followup-To: Carsten Bormann <cabo@tzi.org>, Michael Richardson <mcr+ietf@sandelman.ca>, "coman@ietf.org" <coman@ietf.org>
References: <34966E97BE8AD64EAE9D3D6E4DEE36F21EDDDD20@szxeml525-mbx.china.huawei.com> <20130312014021.GA64284@elstar.local> <34966E97BE8AD64EAE9D3D6E4DEE36F21EDDDF18@szxeml525-mbx.china.huawei.com> <BBD6E278-49FC-42FB-A342-E40086B6B364@sensinode.com> <8254.1363105006@sandelman.ca> <DA0F7870-F728-4E4C-8A70-F681FE2CF408@sensinode.com> <2D81839E-121C-49E6-ABC0-EE37558638D2@nsn.com> <36CE85CA-0ED6-48E7-8784-A107E5370795@sensinode.com> <13298.1363211415@sandelman.ca> <E390887E-A841-4EE6-BD14-B9590E4E6D63@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <E390887E-A841-4EE6-BD14-B9590E4E6D63@tzi.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "coman@ietf.org" <coman@ietf.org>, Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [coman] are we there yet?
X-BeenThere: coman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: Management of Constrained Networks and Devices <coman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/coman>, <mailto:coman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/coman>
List-Post: <mailto:coman@ietf.org>
List-Help: <mailto:coman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/coman>, <mailto:coman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Mar 2013 17:33:44 -0000

On Wed, Mar 13, 2013 at 08:04:43PM -0400, Carsten Bormann wrote:
 
> Before we can do the tailoring, we need to know what we need.
> We have the 6LoWPAN and RPL MIBs as fleshed out prototypes for a solution.
> Is this the kind of information that people need for managing smart object networks?
> How do we find out?

The 6LoWPAN MIB defines very basic counters that actually did help us
in our lab to _troubleshoot_ issues with both 802.15.4 radios and
Contiki's 6lowpan implementation. I would assume others face similar
issues that we see (e.g. a decent probability for 802.15.4 frames to
not arrive combined with Contiki's notion of "once I start to
reassemble a packet, I wait for remaining fragments, dropping
everything else until I am done or I eventually timeout in case one of
the fragments got lost"). I am not blaming Contiki, they do have
limits in the number of reassembly buffers they can support. Its just
that issues like these are out there and do impact stuff (we did run
into this while we were trying to measure how well out TLS/DTLS
implementation is doing and we got rather surprising results due to
stuff happening in the 6lowpan layer).

The implementation and runtime costs for these counters is small, I
actually doubt you can provide a similar troubleshooting mechanism at
lower costs instrumentation wise. For me, MIB modules are primarily
about what to instrument, that is finding agreement which counters are
needed and when they are exactly incremented so that it is clear how
the counters relate to each other. Sure, with MIB module there is an
implicit binding how to access those counters via SNMP. But there have
always been alternate ways to access such counters (e.g. via CLIs or
other interfaces). I hope this implicit binding to SNMP is not taken
as a reason to not standardize such basic counters.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>