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

"Adrian Farrel" <adrian@olddog.co.uk> Sun, 01 February 2015 16:55 UTC

Return-Path: <adrian@olddog.co.uk>
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 7A79F1A8998 for <roll@ietfa.amsl.com>; Sun, 1 Feb 2015 08:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.2
X-Spam-Level:
X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 c9ZGGqkRySD8 for <roll@ietfa.amsl.com>; Sun, 1 Feb 2015 08:55:40 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222D31A898B for <roll@ietf.org>; Sun, 1 Feb 2015 08:55:39 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t11Gta9U018894; Sun, 1 Feb 2015 16:55:37 GMT
Received: from 950129200 (089144235122.atnat0044.highway.a1.net [89.144.235.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id t11GtZUd018868 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 1 Feb 2015 16:55:36 GMT
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Badis Djamaa'" <badis.djamaa@gmail.com>
References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> <CAPm4LDQUBUDfGcPeuj1FXy3D7ZtfEHnM7RjnU5ett7A8Moaacw@mail.gmail.com>
In-Reply-To: <CAPm4LDQUBUDfGcPeuj1FXy3D7ZtfEHnM7RjnU5ett7A8Moaacw@mail.gmail.com>
Date: Sun, 1 Feb 2015 16:55:34 -0000
Message-ID: <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCw53+4e4VHsW0uBojrMI8G7plKKAIWK/tsAexzYaue+pZIMA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21298.001
X-TM-AS-Result: No--22.045-10.0-31-10
X-imss-scan-details: No--22.045-10.0-31-10
X-TMASE-MatchedRID: PL66URbwWA+0m/IROg5s5Z21GZGE81yGLi2dwKiMR9yqvcIF1TcLYKjg 8LvuPaQlQzWq4+8TLKt0kid+wG2aZ05w1HfNpbI4pvwZ9GmdwDOH7D1bP/FcOkENV4Lwnu7BRzW p7lR8ws4wpXxVu0nDORi8DAZaW4MB/c/S25H4jhvaUa2JYfrGrIVdLK46Krcf+a3bC2tdCMzRLH HtqtWAcfz4vZmX3KxYBuY9AIeqHo50tMeOizCSGsNrWpY804TGU5ulGJaO5WvfUZT83lbkEMCS2 AMm1nQC0PWu5Ebg3mbUTchm4zJLB6ezlDj0PvT93FqOVb7PDEK+F//Mn3a2w+Rmz46Q29bDlSpE XhOCtBSVgn2f2/Mgg6JtjVoePu+q/0j7XSCRjJCVOwZbcOalS279evoIpeI3CpfQdoiBsn4P/Fb H9DutneRY/3djULvkNPDRjTX9xLjl+2yjbMzve8OD5TU1KZy5zJmqByfAaS2X1Zxre5XTAMjeyY VLjHqEISf7n2qaXhJftuJwrFEhTbew1twePJJB3QfwsVk0UbslCGssfkpInQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/LAjOw45oMMTrLSW_v0fIQfTm_jc>
Cc: 'Routing Over Low power and Lossy networks' <roll@ietf.org>
Subject: Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk, 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: Sun, 01 Feb 2015 16:55:42 -0000

Hi Badis,

I'm finally processing your comments on this draft before it goes in front of the IESG on Thursday.

Comments in line.

> 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. 

I agree this is somewhat confusing. 
However, it states that Imax "is described as a number of doublings" not that Imax is a count of doublings.
Sigh - we should have made this clearer in 6206.
Of course, an implementation can do this however it likes, but Imax specifies an amount of time, and I think 6206 is clear about this in the text you quoted.

That means that the text in this draft is also unambiguous that Imax specifies a time.

> 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.

Same answer :-)

> 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.
 
Well, we can come back and work on 6206, but we only have *this* document in front of us at the moment.

I tripped over the IMAX==IMIN piece until reading (later in the section) the explanation...

|  Setting DATA_MESSAGE_IMAX to the same as DATA_MESSAGE_IMIN
|  in this case is acceptable since subsequent MPL Data Message
|  retransmissions are triggered by MPL Control Messages, where
|  CONTROL_MESSAGE_IMAX is greater than CONTROL_MESSAGE_IMIN.

> 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): 
> Current:
> 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 
> Proposed:
> 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.

This could be approached with an Errata Report for RFC 6206, but I think you have fixated on how Imax is expressed, rather than the fact that Imax is a time.

Thanks,
Adrian