[Roll] ticket - 172 - clarify units of trickle timers

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 14 August 2015 12:28 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 235111ACE91 for <roll@ietfa.amsl.com>; Fri, 14 Aug 2015 05:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.211
X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Wt2sIfMpnkEs for <roll@ietfa.amsl.com>; Fri, 14 Aug 2015 05:27:59 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF451ACE87 for <roll@ietf.org>; Fri, 14 Aug 2015 05:27:58 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C1C4E200A1 for <roll@ietf.org>; Fri, 14 Aug 2015 08:46:01 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 7F7FF63B18; Fri, 14 Aug 2015 08:27:57 -0400 (EDT)
Received: from sandelman.ca (localhost []) by sandelman.ca (Postfix) with ESMTP id 663EC63AE8 for <roll@ietf.org>; Fri, 14 Aug 2015 08:27:57 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2
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: Fri, 14 Aug 2015 08:27:57 -0400
Message-ID: <29012.1439555277@sandelman.ca>
Sender: mcr@sandelman.ca
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/imdDHSymt2ow9Jpg07H3epsChXs>
Subject: [Roll] ticket - 172 - clarify units of trickle timers
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 14 Aug 2015 12:28:01 -0000


This ticket was opened in response to a DISCUSS from AD Alia Atlas,
on the draft-ietf-roll-mpl-parameter-configuration document.

As a result of this DISCUSS the processing of trickle-mcast was held
up at the RFC-editor, as there was concern that we needed to fix that
document.  Ines and I are looking for opinions from the WG about this
situation; better text, even just "yes, you described the problem correctly"

The specific confusion is that draft-ietf-roll-mpl-parameter-configuration
and trickle-mcast are not explicit enough about the units of IMIN and IMAX

Jonathan Hui commented that the origin of the problem is
really RFC RFC 6206, and he wrote on a thread involving the ADs:

       - On one hand, RFC 6206 says "the maximum interval size Imax", which
       is an absolute value.
       - On the other hand, RFC 6206 says that Imax "is described as a number
       of doublings of the minimum interval size", which is a relative value.

       - Later, RFC 6206 uses Imax as if it were an absolute value. For
       example, "When the algorithm starts execution, it sets I to a value in
       the range of [Imin, Imax]". In another example, "Nodes with small Imax
       values will transmit faster, suppressing those with larger Imax
       values. The nodes with larger Imax values, always suppressed, will
       never transmit." That statement only makes sense if Imax was an
       absolute value, and not relative to Imin.

       - RFC 6206 also uses Imax as it it were a relative value. "Note that
       mismatched Imin values and matching Imax doubling constants will lead
       to mismatched maximum interval lengths."

It seems clear to me that it doesn't really *internally* matter if Imax is a
timer or a doubling of Imin, as long as it can be used an alarm that causes
the trickle algorithm to run.  It is only when we get to
draft-ietf-roll-mpl-parameter-configuration when we put these values
on the wire that we have to deal with it clearly.

mpl-paramaeter-configuration says (section 2.1):

   Note that all time values (Trickle timers and expiration periods) are
   in TUNIT milliseconds precision.  For example, if TUNIT is 20 and the
   data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms, then
   DM_IMIN shall be set to 50.

and I suggest that it instead say:

   Note that time values DM_IMIN, DM_T_EXP, C_MIN, C_T_EXP are in units
   of TUNIT. TUNIT is a multiplier, and is in units of miliseconds.
   For example, if TUNIT is 20 and the
   desired data message interval minimum (DATA_MESSAGE_IMIN) is 1000ms,
   then DM_IMIN shall be set to 50 (1000ms/ 20 = 50).

   Time values: DM_IMAX, and C_IMAX are in multiples of the respective
   DM_IMIN and C_IMIN values, so if a DM_MIN value of 50 (1000ms) is
   encoded, and DM_IMAX contains the number 4, then the DATA_MESSAGE_IMAX value
   would have be 4000ms (4s).

Also, mpl-parameter-configuration needs a reference to 6206.

As such I don't think we need to fix anything in the trickle-mcast document

Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/