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

Don Sturek <d.sturek@att.net> Sat, 30 March 2013 13:13 UTC

Return-Path: <d.sturek@att.net>
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 6EB4F21F86D8 for <roll@ietfa.amsl.com>; Sat, 30 Mar 2013 06:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 fESrJykcV-mP for <roll@ietfa.amsl.com>; Sat, 30 Mar 2013 06:13:49 -0700 (PDT)
Received: from nm17.access.bullet.mail.sp2.yahoo.com (nm17.access.bullet.mail.sp2.yahoo.com [98.139.44.144]) by ietfa.amsl.com (Postfix) with ESMTP id 938E821F86D6 for <roll@ietf.org>; Sat, 30 Mar 2013 06:13:49 -0700 (PDT)
Received: from [98.139.44.106] by nm17.access.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
Received: from [98.138.226.241] by tm11.access.bullet.mail.sp2.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
Received: from [127.0.0.1] by smtp112.sbc.mail.ne1.yahoo.com with NNFMP; 30 Mar 2013 13:13:49 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1364649229; bh=A/UMt5/8qS5XJpu8R/G/dlfKCjrND06uHWgEZoRL7k0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=RR1TCji7KlWb8dtkmM5rd6R+IwqFf5IVeYiaPGq8TZ6YFd6AbGkFit8F1IXazQI/+SzvFI+xebAZ+lxzgiUdZlb5Xw4f1HXhvZIp5EFtqVybQtcw7EJb39TjJB6jdCBupo9yXu8e2lzlq4u1fPSkcAU7zAi9rIiKqx+GRCc/Mdc=
X-Yahoo-Newman-Id: 91014.34415.bm@smtp112.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: s_cdrT0VM1nq7z83pWdQMxlNfCFXlbIn2EUxCfy_5BkvYhz tSqIcIYcQ3HNyzY2NnhghqMRWak_oKn_uUeehLm_7vt2se.zkpEG7yOXYV6f uRLVVbl24q4mo.r4vFBMZmryVG1b7Qct3jjKMAKX89F1LLeJ7ahBraiu.T4w _hEwMosRXzD1DNlRy9rdGiOs2TYaLpQDgOCiQm88HOC4QUJlKwszpO8u81fr 3F5A3k9lKo.FBm9f364kCZ9FQD2bjp8.GdCwzbDk3HbA6H3LCK42u.x5Naa4 1Slg1Dcn9GWxWkKSWmtvcZ0roRGMb8n8BVithQUFSMbhPiEJet9keQLdZR.r fkD_iItWF3R2OMMcDBqDvtR7CkI1cQqukP06KAq._XEvlc3Csg5v6rqQC0Y7 b1QRB5IAhU0MJ0ETdw5bdTmwEV5.CfYnIzDZ0bfB.01SfQG3SPjWKBluERoT qQvpwlxx0Lcm2DtyUKGY-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
X-Rocket-Received: from [192.168.0.199] (d.sturek@69.105.137.143 with login) by smtp112.sbc.mail.ne1.yahoo.com with SMTP; 30 Mar 2013 06:13:49 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.3.2.130206
Date: Sat, 30 Mar 2013 06:11:17 -0700
From: Don Sturek <d.sturek@att.net>
To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
Message-ID: <CD7C2F43.1F917%d.sturek@att.net>
Thread-Topic: [Roll] WG Last Call draft-ietf-roll-trickle-mcast-04
In-Reply-To: <c4d8412060e3c10d3696fd17471ab38f@xs4all.nl>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: 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 13:13:50 -0000

Hi Peter,

What you wrote below sounds quite correct.   Given our testing, your
statement that that recommend default paramters depend on the timing
characteristics of the application and topology of the network aligns very
well with the test results we gathered.

Our test used our assumed topology (30 node network with 3 hops).   We
created the network using IEEE 802.15.4 devices connected via wires on SMA
connectors (with attenuators to reflect distance between the devices).
Our test set up was to create a multicast message targeting from 1 to 8
devices in the network where each of the targeted devices was to create a
multicast message in response (we were testing how mDNS would work using
Trickle Multicast in our network).   Our success criteria was to see that
every node in the network (100% coverage on the requst) saw the original
multicast request and that the requestor would see all of the responses
(100% coverage on the responses received).   We ran quite a few tests with
varying numbers for Imin, Imax, tdell, k, etc.   Intiially, we wanted the
window to be small thinking that would best service the requests/responses
but could only get to around 60% of requests seen and responses received.
Finally, we had to set Imax out to 512ms to achieve our goal.   One clear
observation is that these settings were definitely tied to the number of
devices in the network and topology.

I know for lighting applications that multicasts must be received within
250ms.   That was not our use case so we did not impose this restriction.
It would have been interesting to see if we could have achieved both
goals:   all devices seeing the request AND the multicast request
delivered within 250ms.

Don


On 3/30/13 5:24 AM, "peter van der Stok" <stokcons@xs4all.nl> wrote:

>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
>_______________________________________________
>Roll mailing list
>Roll@ietf.org
>https://www.ietf.org/mailman/listinfo/roll