Re: [Roll] Border router failure detection

[Konrad Iwanicki <[e-mail]>]

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