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

Joakim Eriksson <joakime@sics.se> Mon, 02 May 2016 21:06 UTC

Return-Path: <joakime@sics.se>
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 BC95812D63C for <roll@ietfa.amsl.com>; Mon, 2 May 2016 14:06:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=sics-se.20150623.gappssmtp.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 zvwbvz53ov-z for <roll@ietfa.amsl.com>; Mon, 2 May 2016 14:06:24 -0700 (PDT)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 240D312D115 for <roll@ietf.org>; Mon, 2 May 2016 14:06:24 -0700 (PDT)
Received: by mail-lf0-x233.google.com with SMTP id y84so620757lfc.0 for <roll@ietf.org>; Mon, 02 May 2016 14:06:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sics-se.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=KWMylkUDhsgm+umqIphEhkbtWk6k9LaafxtrdG3Cgpk=; b=NV38g1fa2he1NJANEAIRpU6F7+JHqDIlKOTiV4hEiNRWo2iLwcmLM0nKsHMSNkS03l xW7HpHjHk6A8iwoVAiT21JKj2b1tKHcnkUAPKhBXh1/qLT7g9co95jDZ5cPnjqUqDMTh kwY1s/I0GeGv8Y9OnttDC0OfH/t4Y1zLKxS3gnvcRyGUXVLwPgXwE7Tf0+kX6bSV02sp 0Q86I5d/MEQfJJ3YGruefCN0g6cKk1OXudf+n1gHrj1V7gyfPQPpw1myhHXR1eHO+712 +05jqf5X7J2T37r5bEan/Z0A1aJWvLqnINKairKtS/PD0oM7y88zZiftiAQkaBnVnsHN 5Trg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=KWMylkUDhsgm+umqIphEhkbtWk6k9LaafxtrdG3Cgpk=; b=XSjIP6opGxboRCTysKmP9LWa8Mvo+hcsNoGgR/mEUKrRQPTe83J8M2cJubb9EbET1K Y6O91L7YBMEr61oGAdPYrpwxthm0f41pmZO+36GrAZeW90yB/5U25xTQTjR4oPE0psN5 D1nn5VcRHhbvAfgmStSDH/IkmKy3JmrChcm1rormj+LTNNVqFaIuFU5FmKnqyndwuOOX 414+1LsbQMYQgn8sBXMm2DF9BpuCLjJDT5J5xPhxso3MABzo+Bvrw2JFRD8S3+7TX0tz T56tJQPMf5Q0Ttl4IqHcVIanSnzh0Z8ub95O92RFXHwO/vhWAppevH26mdoiMBE1ZCLC CcvA==
X-Gm-Message-State: AOPr4FXa54YV9Vmp1aJ7WlpLuv+GOqHl7SSjxPBVkbvG2Fx+UR2Gz3TQ651komjsVn31DD9H
X-Received: by 10.25.160.13 with SMTP id j13mr13024513lfe.57.1462223182192; Mon, 02 May 2016 14:06:22 -0700 (PDT)
Received: from [192.168.1.102] (195-67-245-31-no175.tbcn.telia.com. [195.67.245.31]) by smtp.gmail.com with ESMTPSA id q13sm7669lfi.21.2016.05.02.14.06.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 14:06:21 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_7087BDE4-F649-42B6-9084-C47C16D6553D"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Joakim Eriksson <joakime@sics.se>
In-Reply-To: <f2ed4c67-66f6-d70e-24c1-a820e9fd690b@gmail.com>
Date: Mon, 2 May 2016 23:06:20 +0200
Message-Id: <F678C25E-2780-4561-A364-87869CEE24C1@sics.se>
References: <2591c152-29fd-ce24-d4c2-27fc23a9a034@gmail.com> <CAMxvJt+FnZQOtv2yFE7t6s-e97DirGHVHCbLGz2U-CJnHC8cBQ@mail.gmail.com> <f2ed4c67-66f6-d70e-24c1-a820e9fd690b@gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
X-Mailer: Apple Mail (2.3124)
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/9ychGw0VvzE1C5Sh3YltHo3RgRs>
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 21:06:27 -0000

Hello,

> On 02 May 2016, at 22:46, Cenk Gündogan <cnkgndgn@gmail.com>; wrote:
> 
> 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).

Typically the RPL parent will get lots of data from the children which will cause the link-metric to change
so it is not always the case that a defunct parent (at least not any of the actively used ones) will be just
kept for 2.3 hours but rather be switched out since it’s link is detected to be really bad.

> 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.

Yes, a regular unicast DIS is a good way to keep both link metrics and other important liveliness
information up to date.

> 
> 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?

It might affect something, but I would guess there are many other things that might be worse when it comes
to impact on interoperability between implementations. Especially DAO / DAO ACK feels underspecified in
the RFC.

Best regards,
— Joakim 

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