Re: [Roll] Border router failure detection

Konrad Iwanicki <iwanicki@mimuw.edu.pl> Wed, 04 March 2020 13:02 UTC

Return-Path: <iwanicki@mimuw.edu.pl>
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 4AE773A0E66 for <roll@ietfa.amsl.com>; Wed, 4 Mar 2020 05:02:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 HXgO-6BR8Yqp for <roll@ietfa.amsl.com>; Wed, 4 Mar 2020 05:01:56 -0800 (PST)
Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [IPv6:2001:6a0:5001::4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 580AC3A0E60 for <roll@ietf.org>; Wed, 4 Mar 2020 05:01:56 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id ABC55605A370D; Wed, 4 Mar 2020 14:01:54 +0100 (CET)
X-Virus-Scanned: amavisd-new at mimuw.edu.pl
Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id J2gW_ZpHmSS1; Wed, 4 Mar 2020 14:01:52 +0100 (CET)
Received: from [IPv6:2001:6a0:5001:2:f041:42a0:d6:8071] (unknown [IPv6:2001:6a0:5001:2:f041:42a0:d6:8071]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA; Wed, 4 Mar 2020 14:01:50 +0100 (CET)
From: Konrad Iwanicki <iwanicki@mimuw.edu.pl>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles=40googlemail.com@dmarc.ietf.org>
References: <CAP+sJUfcEY2DNEQV=duJdN6P8zZn0ccuei+4ra-B6TcLb5z8Kg@mail.gmail.com> <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <CAP+sJUdj4VrmR=+=9_uKyvKOFE5uu98x3Qog43+_tOmTgd+A3A@mail.gmail.com>
Message-ID: <0cb817c8-cccf-c8bb-1e39-8c6167bf4aa2@mimuw.edu.pl>
Date: Wed, 4 Mar 2020 14:02:12 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAP+sJUdj4VrmR=+=9_uKyvKOFE5uu98x3Qog43+_tOmTgd+A3A@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/IGNy_qcjRav00uPrcxuPfM1u2J8>
Subject: Re: [Roll] Border router failure detection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Wed, 04 Mar 2020 13:02:01 -0000

Dear Ines,

On 03.03.2020 13:27, Ines Robles wrote:
> Thank you very much for your email to the mailing list and welcome :-)

Thank you.

> Here are some guidelines [1] to write IETF-Drafts, e.g. as Michael says
> for markdown[2], good tools for writing IETF-Drafts [3] and good
> tutorials about IETF [4] and for newcomers [5].
>
> Please be aware that all the IETF activities follows the note well [6]
>
> This is our github [7], in general we create one repository for
> ietf-draft. If you desire, you could give me your username I can add you
> with the permissions, so you can create a repository and put your public
> work there. That is very useful to work together and easy for people to
> create issues.

Sure. That would be great. My login is just: konrad-iwanicki

> To submit the draft to the ROLL site, please goes to [8] and select I-D
> submission tool: name your draft as
> follows: draft-yourlastname-roll-maintopicofdraft-00 and it is going to
> be displayed in the section called "Related Internet-Drafts " in the
> ROLL Documents page.

Thank you for the pointers. Once I am at that stage, it will be 
extremely useful to have everything in one place.

> It would be great if you could attend the IETF 107 remotely [9], so you
> can see how it is an IETF meeting. There is no fee to participate
> remotely in IETF, but registration is required to access video and other
> information via Meetecho.

Thanks for the invitation. I will try to find a slot in my agenda.

> Please let us know if you need further help.

Thank you. This is definitely more than enough for now.

Best regards,
-- 
- Konrad Iwanicki.

> On Mon, Mar 2, 2020 at 1:59 PM Konrad Iwanicki <iwanicki@mimuw.edu.pl
> <mailto:iwanicki@mimuw..edu.pl>> wrote:
>
>     Dear all,
>
>     I am new to the list, so apologies if I fail to follow some conventions.
>
>     In a nutshell, I would like to propose an extension to RPL that had
>     been
>     invented to significantly improve handling crashes of border routers.
>     Since I have little experience writing RFC-like drafts, I would greatly
>     appreciate any help.
>
>     Following Dominique’s advice, I did browse the topics that were being
>     discussed on the ROLL list in the last two years and did not find any
>     major overlaps. At the same time, the extension seems to match the
>     current charter of the WG, notably with respect to reliability and
>     manageability. Below I thus try to briefly motivate and summarize the
>     extension, so that you can judge how relevant it is and so that
>     hopefully somebody gets interested in helping to write it up.
>
>     The extension was inspired by numerous commercial LLN deployments,
>     which
>     we did for a range of industries. What we noticed in virtually all
>     cases
>     is that the major causes of sensor data unavailability were crashes of
>     border routers. The explanation is rather intuitive. Border routers
>     typically rely on a tethered power supply and in practice it is often
>     not economic, or even impossible, to provide them with a battery
>     backup.
>     Therefore, power outages are major problems. Another issue is that
>     border routers are also more intricate, in terms of both hardware and
>     software, than low-power nodes. As such, they are also more likely to
>     malfunction.
>
>     What we observed, however, is that RPL does not efficiently handle
>     crashes of border routers [1][2]. Upon such a failure, tearing down
>     nonexistent upward routes can take a lot of time (depending on the
>     data-plane traffic) and generate considerable control traffic, which is
>     problematic in many applications.
>
>     What we did to address the problem was developing an algorithm, called
>     RNFD, in which nodes collaborate to monitor the state of a border
>     router
>     of the DODAG they belong to [1]. Experiments with a TinyOS
>     implementation of the algorithm on two testbeds (32 nodes at 2.4GHz and
>     76 nodes at 868MHz) and in simulations show that it can outperform bare
>     RPL: it can detect a border router crash one or two orders of magnitude
>     faster and with much lower control traffic [1].
>
>     To verify these results and come up with a way of best integrating RNFD
>     with RPL, we also did an independent implementation of RNFD (for
>     which I
>     did not write a single line of code) and integrated it with RPL-Lite
>     from ContikiNG [3]. Experiments with that implementation on a
>     network of
>     ~150 nodes at 2.4GHz and in a different simulator again confirmed the
>     aforementioned performance gains resulting from employing RNFD [3].
>
>     I am looking forward to your comments or questions (and hopefully
>     volunteers to help me with the draft). Below you can find the previous
>     citations. I would also be happy to provide more details.
>
>     References:
>
>     [1] K. Iwanicki: “RNFD: Routing-Layer Detection of DODAG (Root) Node
>     Failures in Low-Power Wireless Networks,” in IPSN 2016: Proceedings of
>     the 15th ACM/IEEE International Conference on Information Processing in
>     Sensor Networks. IEEE. Vienna, Austria. April 2016. pp. 1—12. DOI:
>     10.1109/IPSN.2016.7460720
>
>     [2] A. Paszkowska and K. Iwanicki: “Failure Handling in RPL
>     Implementations: An Experimental Qualitative Study,” in
>     Mission-Oriented
>     Sensor Networks and Systems: Art and Science (Habib M. Ammari ed.).
>     Springer International Publishing. Cham, Switzerland. September 2019.
>     pp. 49—95. DOI: 10.1007/978-3-319-91146-5_3
>
>     [3] P. Ciolkosz: “Integration of the RNFD Algorithm for Border Router
>     Failure Detection with the RPL Standard for Routing IPv6 Packets,”
>     Master's Thesis, University of Warsaw. November 2019.
>
>     Best regards,
>     --
>     - Konrad Iwanicki.
>
>     _______________________________________________
>     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
>