Re: [Roll] How to react if Trickle Interval > Default Lifetime

Cenk Gündogan <cnkgndgn@gmail.com> Mon, 02 May 2016 20:46 UTC

Return-Path: <cnkgndgn@gmail.com>
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 BB77212D19F for <roll@ietfa.amsl.com>; Mon, 2 May 2016 13:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.198
X-Spam-Level:
X-Spam-Status: No, score=-2.198 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 hN8npY9nFlvz for <roll@ietfa.amsl.com>; Mon, 2 May 2016 13:46:56 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 1803612B074 for <roll@ietf.org>; Mon, 2 May 2016 13:46:56 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id a17so5813237wme.0 for <roll@ietf.org>; Mon, 02 May 2016 13:46:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=ujaWqE34sEPVG7TxN6eSln3ahzDGK9rhQ80vsv9joZs=; b=MZLPNPVwgJxvGw0sZZXxyjoN7JP0e1Knnot6HeO1PMrEGKaeT7O5BGZUzlj8eeDs+k 5eGWUnpA6JRASkCjaXnFlQNwhCNLFZwoPAwOBTU5stpFFi6pX7dPXCq2uS6ijcryi4SU okqQORKbrJaWWpwa5AtIYOdALF43OhsEmF/pQUv/4f+RQFAI0w2RM1xfhNFeEAXc5EMp mdW69IBpV3uotv4EWRA4GNXLb0poRFL2W/6SAuYcypcN6kOOENDRiroqfNkBekcIB1I+ pSvGjRqPmnsyzjZB2baLRbV8uwQYBxMKgIBEkELAFjWo0Cr4gW/Kd+L7pski2mLdKNOM EXqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=ujaWqE34sEPVG7TxN6eSln3ahzDGK9rhQ80vsv9joZs=; b=k9DJ0cp59u6oUt5GV9KKGGtVT/R8vimrCGfp8fGxCPz77sp5ZsMEJ0anecCoAdX5Dc ObO2qzOLe2CkJOiCrIRGc3arGM4yhWL0327+k7B+Eqb9/xr0hCCvIIKjorsXeKicleCY NU4uN0LR+2+RUU+k4jMgTll8pPv5uP9XG322pQnrEHHkTt9HYiC0U9c9UCQnhFXk+P8c 1zug05S9hm0WzE+Ck3Ny9+FyFXTCrK/KljwVQPltajL6QfqiPetZVDFtxV56pZA3DaO0 VdyKiPCkXjQp30518Ef3/U6E1UB/7JhSqhUcOrW3XZZIlpp3Dq1QZbFaxiZRKpS3+tWo 855w==
X-Gm-Message-State: AOPr4FXjaazrD9Em+HS5DN7wRu5JMoUE3hy/m1YtxZupjiRlKpymM+VRAQEI+nt8S+fLDw==
X-Received: by 10.194.166.3 with SMTP id zc3mr39023858wjb.104.1462222014637; Mon, 02 May 2016 13:46:54 -0700 (PDT)
Received: from ?IPv6:2a02:8109:8680:45c:221:ccff:fe67:d847? ([2a02:8109:8680:45c:221:ccff:fe67:d847]) by smtp.googlemail.com with ESMTPSA id c4sm32319826wjm.24.2016.05.02.13.46.53 for <roll@ietf.org> (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 13:46:53 -0700 (PDT)
To: roll@ietf.org
References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> <CAMxvJt+FnZQOtv2yFE7t6s-e97DirGHVHCbLGz2U-CJnHC8cBQ@mail.gmail.com>
From: =?UTF-8?Q?Cenk_G=c3=bcndogan?= <cnkgndgn@gmail.com>
Message-ID: <f2ed4c67-66f6-d70e-24c1-a820e9fd690b@gmail.com>
Date: Mon, 2 May 2016 22:46:52 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAMxvJt+FnZQOtv2yFE7t6s-e97DirGHVHCbLGz2U-CJnHC8cBQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------4E3B72B318D9F5774DA39F53"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/oQE2Kb02P0r4em-2W9wBlJL5EkA>
Subject: Re: [Roll] How to react if Trickle Interval > Default Lifetime
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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 May 2016 20:46:59 -0000

Hello Simon, Joakim,

Thank you for the quick reponses!

On 05/02/2016 09:55 PM, Simon Duquennoy wrote:
> Dear Cenk,
>
> In Contiki we send periodic multicast DIS until the node has joined 
> any DAG.
> After that, one thing you can do if enable "probing", which will 
> periodically send a unicast DIS to your preferred parent (and also 
> cover other candidates neighbors, to keep link estimates up-to-date).
> In general wouldn't it be the expected practice to advertise trickle 
> parameters that never surpass the default lifetime?
I would actually expect to find expected practices in the RFC.

The default values of the trickle timer as defined in RFC6550 can result 
in intervals of up to
2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even 
infinite), then it's not really possible to notice
defunct parents within that time span (apart from checking DAO-ACKs and 
signaling of other layers..).
By restricting the lifetimes to such intervals, we basically increase 
the convergence time
of the routing protocol to the same amount of time (worst case).

As a matter of fact, I considered the DIS solution to request a DIO 
before a timeout occurs
as an expected practice and I was a little bit surprised to see that 
implementations are handling
this differently.

However, it seems that there are some degrees of freedom in this matter,
and I am wondering if this can affect interoperability of different 
implementations used in the same network?

Best,
Cenk

> Simon
>
>
> On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan <cnkgndgn@gmail.com 
> <mailto:cnkgndgn@gmail.com>> wrote:
>
>     Dear RPL Veterans,
>
>     I recently came across the question of how a RPL router may react,
>     if a parent's default lifetime (and unit -- specified in the DODAG
>     Conf. Opt.)
>     is surpassed by the parent's continuously rising trickle interval?
>
>     Without any action from the children, I would assume that the
>     upward link to
>     the parent would time out before the next DIO arrives to refresh
>     the lifetime,
>     hence breaking the child -> parent relation.
>
>     Implementations seem to handle this case very differently..
>
>     * The RPL implementation of RIOT uses unicast DIS messages to
>     request a one-shot DIO
>     from a parent that has a link which is about to expire.
>     * From what I could gather in [1], Contiki also seems to send
>     unicast DIS
>     messages randomly in an interval of 30~55 seconds (Please correct
>     me if I am wrong).
>     * In an off-list discussion with Michael, I learned that unstrung
>     is e.g. handling
>     this case by not letting the Trickle interval exceed the default
>     lifetime
>     (Again, please correct me if I am wrong).
>
>     I couldn't find any hints regarding this situation in RFC6550.
>     Is there actually an obvious way to handle this, but I am just not
>     seeing it?
>
>     Best,
>     Cenk Gündoğan
>
>     [1]
>     https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c
>
>     _______________________________________________
>     Roll mailing list
>     Roll@ietf.org <mailto:Roll@ietf.org>
>     https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll