Re: [Roll] Telechat update notice: <draft-ietf-roll-trickle-mcast-11.txt>
Badis Djamaa <badis.djamaa@gmail.com> Mon, 02 February 2015 21:56 UTC
Return-Path: <badis.djamaa@gmail.com>
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 B5E341A037A for <roll@ietfa.amsl.com>; Mon, 2 Feb 2015 13:56:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 8pWaJo4vhxzX for <roll@ietfa.amsl.com>; Mon, 2 Feb 2015 13:56:51 -0800 (PST)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48261A1AC6 for <roll@ietf.org>; Mon, 2 Feb 2015 13:56:50 -0800 (PST)
Received: by mail-ig0-f170.google.com with SMTP id l13so20343974iga.1 for <roll@ietf.org>; Mon, 02 Feb 2015 13:56:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vjpQQZIKeL9clnVTofXRdmOfATHrJ9O8gljV7JPlrd4=; b=c6PXLSIzezmiqXThnfl1/rqH7Op0DTbuQm+oPZa8fJJ0c+KljHFSXDwJtPIy3N6DSf 4xmwcRJ0u3qateXLlu6bG5WisoiDdODPHUBjyw/MZvVBnI2S/EYY3fVCsVfo+IhRy/+I ZdAogZHv8fnrT/wGo/LeAqGgbRb01jEeb0ozMeSgEXND9rbLzG1CqdOoJrymCZl1+OqL Kt5A4q8jpsXHyIz1n/eMu8Hmk8VFAwTxETATAEqag+XoDyDTvBJ2cYeB89b2b47JaOZZ ixcRXschbLv2y5kdGLYfajB0P0ybMzpZk7b6w3b9dqJr2+RZS8rgSzWzDFQOtaUIbs+E Ai/Q==
MIME-Version: 1.0
X-Received: by 10.107.132.101 with SMTP id g98mr19786655iod.66.1422914209839; Mon, 02 Feb 2015 13:56:49 -0800 (PST)
Received: by 10.107.52.16 with HTTP; Mon, 2 Feb 2015 13:56:49 -0800 (PST)
In-Reply-To: <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk>
References: <20150118201333.15474.51860.idtracker@ietfa.amsl.com> <32747.1421682839@sandelman.ca> <CAPm4LDQUBUDfGcPeuj1FXy3D7ZtfEHnM7RjnU5ett7A8Moaacw@mail.gmail.com> <01cd01d03e3f$e688a140$b399e3c0$@olddog.co.uk>
Date: Mon, 02 Feb 2015 21:56:49 +0000
Message-ID: <CAPm4LDSRTrgc-Chb3RT_2ps4-tKiC7f_LrsZqur+e+0yrJzQog@mail.gmail.com>
From: Badis Djamaa <badis.djamaa@gmail.com>
To: adrian@olddog.co.uk
Content-Type: multipart/alternative; boundary="001a113eccb8060045050e220884"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/iCuFmmN15hNT_t95uMYhMJX7prc>
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: 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: Mon, 02 Feb 2015 21:56:54 -0000
Much clearer now Thnak you Adrian best, badis On 1 February 2015 at 16:55, Adrian Farrel <adrian@olddog.co.uk> wrote: > 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 > >
- Re: [Roll] Telechat update notice: <draft-ietf-ro… Michael Richardson
- Re: [Roll] Telechat update notice: <draft-ietf-ro… Badis Djamaa
- Re: [Roll] Telechat update notice: <draft-ietf-ro… Adrian Farrel
- Re: [Roll] Telechat update notice: <draft-ietf-ro… Adrian Farrel
- Re: [Roll] Telechat update notice: <draft-ietf-ro… Badis Djamaa