Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04

peter van der Stok <stokcons@xs4all.nl> Sat, 30 March 2013 12:24 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BE721F8814 for <roll@ietfa.amsl.com>; Sat, 30 Mar 2013 05:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.796
X-Spam-Level:
X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xFmBcMf4LSw for <roll@ietfa.amsl.com>; Sat, 30 Mar 2013 05:24:19 -0700 (PDT)
Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4F62A21F8801 for <roll@ietf.org>; Sat, 30 Mar 2013 05:24:19 -0700 (PDT)
Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr8.xs4all.nl (8.13.8/8.13.8) with ESMTP id r2UCOISb029757 for <roll@ietf.org>; Sat, 30 Mar 2013 13:24:18 +0100 (CET) (envelope-from stokcons@xs4all.nl)
Received: from a82-95-140-48.adsl.xs4all.nl ([82.95.140.48]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Sat, 30 Mar 2013 13:24:17 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Sat, 30 Mar 2013 13:24:17 +0100
From: peter van der Stok <stokcons@xs4all.nl>
To: roll@ietf.org
Organization: vanderstok consultancy
Mail-Reply-To: <consultancy@vanderstok.org>
In-Reply-To: <CD7B00E0.1F89F%d.sturek@att.net>
References: <CD7B00E0.1F89F%d.sturek@att.net>
Message-ID: <c4d8412060e3c10d3696fd17471ab38f@xs4all.nl>
X-Sender: stokcons@xs4all.nl (e/nSuDJBDQVB5VrDsKDb0NazPZ8oAo26)
User-Agent: XS4ALL Webmail
X-Virus-Scanned: by XS4ALL Virus Scanner
Subject: Re: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Sat, 30 Mar 2013 12:24:20 -0000

Hi Don, Kerry,


As I tried to express earlier, I am not too happy with the suggested 
default values for the mpl parameters.
Their recommended values very much depend on the timing characteristics 
of the application and the topology of the network.
I think it is more appropriate to have these values cited in the 
applicability statements (if they are focused enough).

Coming back to simulation c.q. operation results:
I can well imagine that with a network that is loaded for a few percent 
of the time with mpl messages the value of k is not that important.
I can also imagine that at the edge of networks with a strongly varying 
density of repeaters, it is possible that some nodes at the edge only 
receive messages with a given regularity when k is infinity.
In the applications that I consider the density of repeaters is quite 
homogeneous, the end to end delays are expressed in hundreds of 
milliseconds and multiple seeds generate messages on a (tens of) seconds 
scale. In that case k=1 is often excellent and a higher k is not 
recommended.

hope this helps,

peter

Don Sturek schreef op 2013-03-29 16:28:
> Hi Kerry,
> 
> Do you have actual test results to back up the claims below?   We (the
> ZigBee IP team) tested these parameters among 7 solution providers and 
> did
> not see what you are reporting.
> 
> Interested in seeing your results.....
> 
> Don
> 
> 
> On 3/29/13 8:08 AM, "Kerry Lynn" <kerlyn@ieee.org> wrote:
> 
>> On Fri, Mar 29, 2013 at 10:37 AM, Don Sturek <d.sturek@att.net> 
>> wrote:
>>> Hi Kerry,
>>> 
>>> The problem that  draft-ietf-roll-trickle-mcast-04 addresses really 
>>> only
>>> occurs in route-over mesh routing.  I don't believe Homenet has such
>>> routing solutions in their charter.  It is possible to see how a 
>>> group
>>> like Manet might use the draft but the only concrete forwarding 
>>> solution
>>> proposed is over ROLL RPL instances (certainly, provision was left 
>>> in
>>> for
>>> other multicast address usage and attendant forwarding rules but 
>>> those
>>> were out of scope for this draft).
>>> 
>> I don't think this opinion reflects on the validity of my comments 
>> for
>> even
>> the restricted ROLL use and I'd be interested in feedback from the
>> authors.
>> 
>> In addition to the comments I made previously, I am concerned that 
>> the
>> default for Imax (== Imin) prevents the Trickle timer interval I from 
>> ever
>> doubling.  Combined with a high k, this leads to aggressive Trickle
>> forwarding
>> in dense parts of the mesh that may inhibit (by interfering with) 
>> unicast
>> responses in transit to the original sender.  Is there a reason for 
>> not
>> relaxing DATA_MESSAGE_IMAX to e.g.
>> DATA_MESSAGE_TIMER_EXPIRATIONS?
>> 
>> -K-
>> 
>>> I would propose that we move forward with the draft, within ROLL, 
>>> and
>>> not
>>> wait for input from other groups since the scope of the initial 
>>> draft
>>> (absent extensions that other groups could propose in the future) is
>>> focused on ROLL RPL.
>>> 
>>> Don
>>> 
>> _______________________________________________
>> Roll mailing list
>> Roll@ietf.org
>> https://www.ietf.org/mailman/listinfo/roll
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll