Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>

"Adrian Farrel" <> Mon, 19 January 2015 18:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A34A1B2AA5 for <>; Mon, 19 Jan 2015 10:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.599
X-Spam-Status: No, score=-99.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LSBIAN=2.3, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLv9qACBM3WI for <>; Mon, 19 Jan 2015 10:20:22 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DD2431ACDC9 for <>; Mon, 19 Jan 2015 10:20:21 -0800 (PST)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t0JIKIKg006490; Mon, 19 Jan 2015 18:20:18 GMT
Received: from 950129200 ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t0JIKG6Q006480 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 19 Jan 2015 18:20:17 GMT
From: "Adrian Farrel" <>
To: "'Badis Djamaa'" <>
References: <> <> <>
In-Reply-To: <>
Date: Mon, 19 Jan 2015 18:20:16 -0000
Message-ID: <032a01d03414$942753e0$bc75fba0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_032B_01D03414.94392E30"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCw53+4e4VHsW0uBojrMI8G7plKKAIWK/tsAexzYaue5kQeoA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--36.703-10.0-31-10
X-imss-scan-details: No--36.703-10.0-31-10
X-TMASE-MatchedRID: HQYVVRq48Rw7iuZ/mdYYtoC2JZZqplZZqJlo5lQZWaqCRevBKC63H8+W uBBZb8XUL0W1btd8e55NI82n17+7U0J1RkW+/L6QV8ukjx868O4Pu/0Lj0myKzeN6XEp4FxwYN6 TBpc4S7r3Zb7NlHCdGKwOh3D3JSTGyTFXR0Y1Ln1nLGaEhTh9zXpENQeTdVXWCBu/kovAHgrLnJ 2UnhQqek5w1HfNpbI4pvwZ9GmdwDP4qCLIu0mtILzZNXfJG3+a/YFClZMrgo0Jc82L/U086xuE0 ttyj7pm3p2WLLHw99BoMLOoNHsM9kPeRdiIlVJEMMn1rcqKQajxO6J7oUevkY52xiOhtMCpz/I8 aG2VMKLwqh5qas50dWwbuvhCHs3cTJDl9FKHbrmCsBeCv8CM/R5FuGz2xZhR8WjLShvBXkJgCvt Ai5GTZKpi1mhIp0HhR+GtoiXVeDEmOHJ0aBcO1PdG7cmuMnEoMY+4OQNXcFHLT/U2lBdAEXC306 CXQ8Uh5ftso2zM73vDg+U1NSmcuesrMeqeicvCJLfQYoCQHFbh0m+JrKxx7FfHpvNvgXmDKGUgI kQkCExNC83U+LUUUJN65fjGjYMQ3vw1aViiOSvJ2i9a4v4pV3Tv7ZA0xIMkEVtxaPoSt7C7Zsqv nT9bvjblc6Gei4nld7yMwO18iIghBdUXaqx1XbXcdpVx4xdSIvwdoLo6xB8wehHQpjQxlVWxAz9 Ls6I1tVWReSlqXepdMrg609R9BKO4XjVpMlFdn+lpJmYuEaN7ltqyJvHgp/JOjUaxKXKqGSKDIg jU9nky499dCbQy8IoLoibgjVEX1WPYxCHVrqebKItl61J/yZUdXE/WGn0FSlnU38LCY8usqqtfp bNXHcgzkpaAyM7aF70JBot7Y88AyZjSuX9209K49nBUaX25m1u+rM16bUmO3uRZC95efSihFyXt pTfA
Archived-At: <>
Cc: 'Routing Over Low power and Lossy networks' <>
Subject: Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To:, Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 19 Jan 2015 18:20:26 -0000

Hi Badis,
You sent your comments to the authors in private? Hmmm, that's a shame.
But thanks for forwarding them to us all now.
Since it is now very late in the process for new comments, what I'll do is discuss your mail with the authors and chairs, and pick up any important issues as part of my IESG ballot.
From: Roll [] On Behalf Of Badis Djamaa
Sent: 19 January 2015 16:26
To: Routing Over Low power and Lossy networks; Michael Richardson
Subject: Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>
Hi Michael,
I had some comments about this draft that I sent to the authors. Having not heard from the authors, I though it might be useful to copy them below
Dear authors,
having read and examined the MPL-drafts-07-11 and having worked thoroughly with Trickle for my PhD, I have some comments regarding MPL's Trickle parameters. 
Draft 11, Section 5.4.  MPL Parameters states:
MPL-TEXT: DATA MESSAGE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206 <> ], for MPL Data Message transmissions.  DATA_MESSAGE_IMAX
      has a default value equal to DATA_MESSAGE_IMIN.
Starting from the above statement (dubbed MPL-TEXT), I have two main comments
1) terminology related: [RFC6206 <> ]  ( <> 4.1.  Parameters and Variables) defines "The maximum Trickle timer interval" as:
RFC6206-TEXT1:  The maximum interval size, Imax, is described as a number of
      doublings of the minimum interval size (the base-2 log(max/min)).
      For example, a protocol might define Imax as 16.  If the minimum
      interval is 100 ms, then the amount of time specified by Imax is
      100 ms * 65,536, i.e., 6,553.6 seconds or approximately
      109 minutes.
MPL-TEXT refers to RFC6206 <>  for the definition of "The maximum Trickle timer interval". However, I think "The maximum Trickle timer interval" usage in MPL-TEXT is different than its definition in RFC6206-TEXT1. Thus, I think it would be better to explicitly specify what is meant by "The maximum Trickle timer interval" to avoid any ambiguity. 

Note that the same comment is also valid for this MPL text (Draft 11, Section 5.4.  MPL Parameters )
CONTROL_MESSAGE_IMAX  The maximum Trickle timer interval, as defined in [RFC6206 <> ], 
for MPL Control Message transmissions. CONTROL_MESSAGE_IMAX has a default value of 5 minutes.
2) Now arriving to the main concern, suppose that  DATA_MESSAGE_IMAX literally means the maximum trickle interval (the time specified by Imax using RFC6206 <>  terminology), then: "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." in MPL-TEXT could result in a "non-wanted" behavior . This is because RFC6206 <> 's section  <> 4.2.  Algorithm Description, rule 6 states:
RFC6206-TEXT2: 6.  ...If I is equal to Imin when Trickle hears an
       "inconsistent" transmission, Trickle does nothing...
Recommending "DATA_MESSAGE_IMAX has a default value equal to DATA_MESSAGE_IMIN." makes the trickle timer always fall under RFC6206-TEXT2 and hence the timer will never get reset when hearing "inconsistencies" 
However, if this default recommendation is deliberately designed  considering the above point, then choosing a non-default value of DATA_MESSAGE_IMAX will result in a different behavior (nodes will reset their timers when receiving inconsistencies). This might even propagate faster than the default recommendation.
To avoid the aforementioned ambiguities, I can think of recommending either a default DATA_MESSAGE_IMAX equals 2*DATA_MESSAGE_IMIN or propose a change to RFC6206-TEXT2 in the MPL draf, if the current default recommendation is not deliberately designed to work as shown above. Otherwise, explicitly state in the MPL text that choosing a non-default value of DATA_MESSAGE_IMAX may result in different behavior.
3) By the way, RFC6206 also contains a typo, which might confuse the reader, in the following text ( <> RFC6206 4.2. Algorithm Description, rule 1): 
1.  When the algorithm starts execution, it sets I to a value in the
       range of [Imin, Imax] -- that is, greater than or equal to Imin
       and less than or equal to Imax.  The algorithm then begins the
       first interval.
Following the definition of the maximum interval size (RFC6206-TEXT1, above) this rule should be rewritten 
1.  When the algorithm starts execution, it sets I to a value in the 
       range of [Imin, Imin x POW(2, Imax)] -- that is, greater than or equal to Imin 
       and less than or equal to the time specified by Imax.  The algorithm then begins 
       the first interval.
Note that the rest of the rules are written taking into account RFC6206-TEXT1.
all the best
On 19 January 2015 at 15:53, Michael Richardson <> wrote:

After some significant delays, and some minor rework the document is now
going to IESG telechat.
Ines and I thank the authors and the community for their patience.

IETF Secretariat <> wrote:
    > Placed on agenda for telechat - 2015-02-05
    > ID Tracker URL:

Michael Richardson < <> >, Sandelman Software Works
IETF ROLL WG co-chair.

Roll mailing list