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

peter van der Stok <stokcons@xs4all.nl> Mon, 17 August 2015 07:15 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022151B2C21 for <roll@ietfa.amsl.com>; Mon, 17 Aug 2015 00:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmsNqEo6j4J6 for <roll@ietfa.amsl.com>; Mon, 17 Aug 2015 00:15:28 -0700 (PDT)
Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45BBC1B2C20 for <roll@ietf.org>; Mon, 17 Aug 2015 00:15:28 -0700 (PDT)
Received: from webmail.xs4all.nl ([194.109.20.211]) by smtp-cloud2.xs4all.net with ESMTP id 5jFR1r00A4ZF39u01jFR4G; Mon, 17 Aug 2015 09:15:25 +0200
Received: from [2001:983:a264:1:18d:11cc:b19f:7478] by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 17 Aug 2015 09:15:25 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Mon, 17 Aug 2015 09:15:25 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
In-Reply-To: <29012.1439555277@sandelman.ca>
References: <29012.1439555277@sandelman.ca>
Message-ID: <3ac1e1929e2d2c781db8ce08a6955e7e@xs4all.nl>
X-Sender: stokcons@xs4all.nl (cRFNIvOM8HWTbEePvshRLOVTercCHyUv)
User-Agent: XS4ALL Webmail
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/4jaRsfVioVc06a1HvSskntu1RFs>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [Roll] ticket - 172 - clarify units of trickle timers
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: consultancy@vanderstok.org, 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: Mon, 17 Aug 2015 07:15:31 -0000

Hi Michael,

thanks for trying to solve this issue.
I must confess that I had not recognized the problem.
For interoperability is seems an issue when values are initialized (as 
you point out as well)
It will be a nuisance if sets of nodes must be initialized with 
different Imin and Imax values to reach the same behaviour.
The same problem will occur when a YANG (SMIv2) description is made for 
managing these parameters.

Suggestion: write an ERRATA document for RFC6206 which then solves 
draft-ietf-roll-trickle-mcast-12 issue.

Peter

Michael Richardson schreef op 2015-08-14 14:27:
> https://tools.ietf.org/wg/roll/trac/ticket/172
> 
> 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
> values.
> 
> 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
> itself.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
> IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll