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, 2 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
>
>