Subject: [Roll] IETF 107: Call for presentations

From: Ines Robles <[email-masked]>
Date: Mon, 2 Mar 2020 12:19:57 +0200

Dear all,

Following the preliminary agenda, ROLL is scheduled with two meetings of
one hour on Monday and two hours on Tuesday.

Please let us know before 10th March if you desire to present a topic
during IETF 107 specifying:

1- Topic
2- Presenter
3- Time needed
4- Please specify if it is remotely or on-site.

Thank you! :-)

Ines, Dominique and Michael.

---

From: Konrad Iwanicki <[email-masked]>
Date: Mon, 2 Mar 2020 12:59:02 +0100

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.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Mar 2020 14:11:45 -0500

Welcome!

Konrad Iwanicki <[email-masked]> wrote:
    > invented to significantly improve handling crashes of border routers. Since I
    > have little experience writing RFC-like drafts, I would greatly appreciate
    > any help.

Use the markdown method, and use someone's template github.

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

Rahul and Pascal (and others) have had a lot of conversation about how we
deal with the various lollipop counters.  So I am interested in what your
border router does when it boots: how does it announce the new DIOs?

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

okay.

    > [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:

Unfortunately, it's behind the IEEE paywall.
I have given up on getting documents from the IEEE.
I guess you have been working on this for at least five years now.

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 3 Mar 2020 16:15:18 +0530

Welcome Konrad and great to hear you on ROLL,

I had access to your paper (through my office IEEE act) and have read the
problem statement and the proposed solution.

I have a few questions with regard to the problem statement before we dive
into the solution part.

Border Router (BR) crash/restart is an issue and any deployment needs to
tackle it (IMO, in version 0.1). As I understand the aim of the paper is to
ensure that the attached nodes should detect the BR failure asap. Just
curious to understand how the nodes use this information in your
deployments? What will be the use-case of this detection?

In my deployments, my focus was to get the BR restarted as soon as possible
and then ensure that the nodes below it could rejoin the restarted BR. This
would mean that BR needs to backup some state information that would be
used post-crash-recovery.
On the contrary, in my scenario, it was necessary to detect 6LN/6LR failure
without depending on periodical pings from nodes to central sever i.e., for
some reason if the node (non-BR node) is stuck, then BR should detect it
asap (without depending on route lifetime since it could be very high) so
that measures could be taken (for e.g., send a personnel to repair the
smart meter). This also is non-trivial to handle. For BR, it is always
possible to ping on the external leg and check availability. Also, BR
unavailability means no traffic going out from any nodes and thus is easy
to identify on the external monitoring system.

Also, as Michael mentioned, the working group had discussed some issues
with respect to reboot handling (on 6LN/6LR/BR) and it has been captured in
https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/
It would be immensely helpful to get your view on those points.

Best,
Rahul

On Tue, 3 Mar 2020 at 00:42, Michael Richardson <[email-masked]>
wrote:

> crashes of
> Failures
> Implementations:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Ines Robles <[email-masked]>
Date: Tue, 3 Mar 2020 14:27:34 +0200

Hi Konrad,

Thank you very much for your email to the mailing list and welcome :-)

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.

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.

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.

Please let us know if you need further help.

Best regards,

Ines.

[1]
https://ietf.org/about/participate/tutorials/process/creating-internet-drafts-and-rfcs/

[2]
https://www.ietf.org/about/participate/tutorials/process/writing-rfcs-and-internet-drafts-markdown-and-bit-yaml/
[3] https://www.rfc-editor.org/pubprocess/tools/
[4] https://www.ietf.org/about/participate/tutorials/
[5] https://www.ietf.org/about/participate/tutorials/newcomers/
[6] https://www.ietf.org/about/note-well/
[7] https://github.com/roll-wg
[8] https://www.ietf.org/how/tools/
[9] https://ietf.org/how/meetings/107/remote/

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Tue, 3 Mar 2020 18:53:25 +0100 (CET)

Hello all,

I'd like to ask for a slot if possible, to discuss the updates to
draft-ietf-roll-nsa-extension.

1- Topic: draft-ietf-roll-nsa-extension
2- Presenter: Remous-Aris Koutsiamanis
3- Time needed: 5-10 minutes
4- Please specify if it is remotely or on-site: Remotely

Best,
Aris

> 1- Topic: draft-ietf-roll-nsa-extension
> 2- Presenter
> 3- Time needed

---

From: Ines Robles <[email-masked]>
Date: Wed, 4 Mar 2020 12:56:41 +0200

Thank you very much Aris.

We will keep you posted.

Ines.

---

From: Konrad Iwanicki <[email-masked]>
Date: Wed, 4 Mar 2020 12:05:20 +0100

Dear Michael,

> Use the markdown method, and use someone's template github.

Thanks. But I guess, I would also need some guidelines doing the writing.

> border router does when it boots: how does it announce the new DIOs?

Internal lollipop counters used within RNFD are always relative to the 
DODAG version number counter. Whenever that counter is refreshed, the 
others are initialized anew. Therefore, for RNFD, the easiest solution 
upon a border router reboot is to broadcast a DIO with a new value of 
the DODAG version.

This, however, is not completely straightforward. We have to either keep 
the counter value in the router's persistent memory, which is not always 
feasible, or learn the last DODAG version value by having the router 
broadcast a DIS and its neighbors reply with DIOs containing the last 
number they are aware of.

In either case, it makes sense for the router to delay broadcasting a 
new DODAG version (and hence the first DIO) for a while after the 
reboot. If "for a while" is long enough, this heuristic helps alleviate 
situations in which the router continuously reboots for some reason but 
manages to bump the DODAG version (e.g., when power is restored but then 
shortly after lost again). More elaborate mechanisms can be deployed as 
well.

> I have given up on getting documents from the IEEE.

Try the ACM Digital Library (the paper is in both libraries):
https://dl.acm.org/doi/abs/10.5555/2959355.2959368

If you fail to download from this source, I can try to get you a preprint.

> I guess you have been working on this for at least five years now.

Well, we wanted to have the problem well studied. And it inspired other 
interesting research as well.

Best regards,
-- 
- Konrad Iwanicki.

---

From: Rahul Jadhav <[email-masked]>
Date: Wed, 4 Mar 2020 16:51:15 +0530

Dear Chairs,

I would like to request for following:

Topic: Capabilities Update, Rahul, 15 mins
Topic: NPDAO and unaware leaves, Rahul, 5 mins
Topic: Observations draft - Next plan, Rahul, 10 mins

Presenting remotely.

Thanks,
Rahul

---

From: Ines Robles <[email-masked]>
Date: Wed, 4 Mar 2020 13:32:34 +0200

Thank you Rahul

Best,

Ines and Dominique

---

From: Konrad Iwanicki <[email-masked]>
Date: Wed, 4 Mar 2020 13:54:33 +0100

Dear Raul,

> Welcome Konrad and great to hear you on ROLL,

Thank you.

> I have a few questions with regard to the problem statement before we
> dive into the solution part.
>
> tackle it (IMO, in version 0.1). As I understand the aim of the paper is
> to ensure that the attached nodes should detect the BR failure asap.
> Just curious to understand how the nodes use this information in your

Yes, the main goal is to detect a failure of a border router asap. In 
general, the use-cases cover highly available systems. Faster detection 
of BR failures gives more possibilities when switching to fallback 
mechanisms, rebinding to a different DODAG, or spawning a new one. A few 
concrete examples:

1. Minimizing lost samples in push-based data-collection apps.

A classic app: each node periodically sends data upward to a BR, which 
then forwards them to a sink.

If one aims at perfect reliability, an end-to-end solution is required: 
the sink acknowledges each data sample, and samples that have not been 
acknowledged are buffered and retransmitted when possible. This requires 
downward-routed ACKs.

In contrast, if we assume nearly-perfect data delivery in that we 
occasionally allow individual samples to be lost, we can have a more 
efficient solution. To begin with, if implemented properly, link-layer 
mechanisms such as hop-by-hop acks, queuing, and retransmissions already 
allow for a very high end-to-end packet reception rate for many 
deployments. As I mentioned in my first e-mail, this leaves BR failures 
as the main cause of burst data loss, at least in our experience. 
Therefore, if we can detect a BR failure fast, nodes can quickly switch 
to buffering samples instead of forwarding them (few samples are lost), 
and start forwarding again only when the BR recovers. What we gain in 
this approach is first eliminating end-to-end ACKs, which reduces 
data-related traffic up to two times. Second, if the nodes just collect 
data, the network's MOP can be downgraded to 0, which in particular 
eliminates DAOs and DAO-ACKs, thereby further reducing the overall 
traffic. Third, when operating under MOP 0, we can employ a dedicated 
radio activity scheduling algorithms at the link layer, which reduces 
energy expenditures even more and can further improve end-to-end packet 
reception rate. Overall, with RNFD we can get a few-fold extension of 
the node battery lifetime without sacrificing end-to-end data delivery 
much compared to the end-to-end solution.

2. Maximizing availability in pull-based data-collection apps.

Here an opposite approach: nodes act as servers from which other 
Internet hosts pull data on demand. (The applicability of the approach 
below is much wider though).

In this app, and actually in general, it makes sense for a node to be a 
member of as few DODAGs as possible, ideally just the best one. This is 
because belonging to a DODAG incurs an overhead on memory, computation, 
and control traffic, not only on this node but also its ancestors in the 
DODAG. The problem is that if a BR goes down, a node may be unreachable 
for a while.

One solution would thus be joining multiple DODAGs, irrespective of the 
overhead. The drawback is that this overhead is to be paid always, even 
when the network operates correctly. If, in turn, we have fast BR 
failure detection, nodes can belong to just one DODAG, and quickly 
switch it upon a BR failure. Again, this can reduce the overhead, at 
least twice, without sacrificing availability much (at least 
unavailability due to BR failures).

3. Maximizing availability in networks with actuation.

We have sensor and actuator nodes. Routing from sensors to actuators is 
normally driven by a BR. This allows, for instance, for traffic analysis 
and forwarding sensor samples to other sinks (e.g., analytical or 
visualization components) besides the relevant actuators.

If a BR goes down, however, what you want to have at the very least is 
communication between sensors and actuators, so that the system 
continues to operate. To this end, the actuators can be roots of their 
own (floating) DODAGs. Again, for efficiency one would probably prefer 
this to happen only upon a BR failure not throughout the entire lifetime 
of the system. This means that being able to detect a BR failure as fast 
as possible may be crucial to ensure that actuators spawn their own 
DODAGs and get sensor readings without major disruptions.

> In my deployments, my focus was to get the BR restarted as soon
> as possible and then ensure that the nodes below it could rejoin the
> restarted BR. This would mean that BR needs to backup some state
> information that would be used post-crash-recovery.

This is very important as well. However, in our case, the control of 
when the BR is restarted was limited to some extent. The goal of RNFD is 
giving additional possibilities to improve the network's performance 
over the period of such a failure. The two problems are thus orthogonal.

> On the contrary, in my scenario, it was necessary to detect 6LN/6LR
> failure without depending on periodical pings from nodes to central
> sever i.e., for some reason if the node (non-BR node) is stuck, then BR
> should detect it asap (without depending on route lifetime since it
> could be very high) so that measures could be taken (for e.g., send a
> personnel to repair the smart meter). This also is non-trivial to
> handle. For BR, it is always possible to ping on the external leg and
> check availability. Also, BR unavailability means no traffic going out
> from any nodes and thus is easy to identify on the external monitoring
> system.

True this is also not trivial but, as I wrote above, it is an orthogonal 
problem.

In general, RNFD is no silver bullet. Apart from the cases that both of 
us mentioned, there are other types of failures possible in a network 
that RNFD does not address. What it does, however, is solving a 
particular problem that we found relevant in practice and that hopefully 
may be relevant for other people as well.

> with respect to reboot handling (on 6LN/6LR/BR) and it has been captured
> in https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/

Sure, I will take a look at this when I find some time slot.

Best regards,
-- 
- Konrad Iwanicki.

> Best,
> Rahul
>
> On Tue, 3 Mar 2020 at 00:42, Michael Richardson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Welcome!
>
>     Konrad Iwanicki <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>, Sandelman Software Works
>     [email-masked] <mailto:[email-masked]>

---

From: Konrad Iwanicki <[email-masked]>
Date: Wed, 4 Mar 2020 14:02:12 +0100

Dear Ines,

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

> 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 <[email-masked]
> <mailto:iwanicki@mimuw..edu.pl>> wrote:
>
>     Dear all,
>

---

From: <[email-masked]>
Date: Mon, 9 Mar 2020 11:16:18 +0000

Working Group,

This is a friendly reminder.
If you want to present during the IETF107, please send a request to us by tomorrow, along the format below.
Thanks

Dominique

De : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Monday 2 March 2020 11:19
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc : Dominique Barthel <[email-masked]<mailto:[email-masked]>>, "Michael ca>" <[email-masked]<mailto:[email-masked]>>
Objet : IETF 107: Call for presentations

Dear all,

Following the preliminary agenda, ROLL is scheduled with two meetings of one hour on Monday and two hours on Tuesday.

Please let us know before 10th March if you desire to present a topic during IETF 107 specifying:

1- Topic
2- Presenter
3- Time needed

Thank you! :-)

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Mon, 9 Mar 2020 15:09:56 +0100

Hello Dominique and Ines,

I would like to request for following :

Topic: dis-modifications-use-cases, Georgios, 10 mins

Thx,
Giorgos

> On Mar 9, 2020, at 12:16, <[email-masked]> <[email-masked]> wrote:
> 
> Working Group,
> 
> De : "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> À : "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> Cc : Dominique Barthel <[email-masked] <mailto:[email-masked]>>, "Michael ca>" <[email-masked] <mailto:[email-masked]>>