Skip to main content

Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)
draft-tripathi-roll-rpl-simulation-08

Revision differences

Document history

Date Rev. By Action
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Dan Romascanu
2012-04-03
08 Jaudelice de Oliveira New version available: draft-tripathi-roll-rpl-simulation-08.txt
2011-11-01
07 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent.
2011-09-27
07 Cindy Morgan IESG state changed to Approved-announcement sent
2011-09-27
07 Cindy Morgan IESG has approved the document
2011-09-27
07 Cindy Morgan Closed "Approve" ballot
2011-09-27
07 Cindy Morgan Approval announcement text changed
2011-09-27
07 Cindy Morgan Ballot writeup text changed
2011-09-26
07 Amy Vezza Approval announcement text regenerated
2011-09-23
07 Adrian Farrel Ballot writeup text changed
2011-09-11
07 Dan Romascanu
[Ballot comment]
As this document defines metrics and used them for performance evaluation of
ROLL, should not IPPM and BMWG also be mentioned in the …
[Ballot comment]
As this document defines metrics and used them for performance evaluation of
ROLL, should not IPPM and BMWG also be mentioned in the IESG note?
2011-09-11
07 Dan Romascanu [Ballot Position Update] Position for Dan Romascanu has been changed to No Objection from Discuss
2011-09-08
07 Cindy Morgan Removed from agenda for telechat
2011-09-08
07 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-09-08
07 Dan Romascanu
[Ballot discuss]
As this document defines metrics and used them for performance evaluation of ROLL, should not IPPM and BMWG also b ementioned in the …
[Ballot discuss]
As this document defines metrics and used them for performance evaluation of ROLL, should not IPPM and BMWG also b ementioned in the IESG note?
2011-09-08
07 Dan Romascanu [Ballot Position Update] New position, Discuss, has been recorded
2011-09-07
07 Jari Arkko
[Ballot comment]
In general, it is extremely good that we have documents like this. Thank you for doing this work! I have not dug in …
[Ballot comment]
In general, it is extremely good that we have documents like this. Thank you for doing this work! I have not dug in deep enough to understand the details and whether all the measurements make sense, but I think we should encourage both this document and other similar ones to be published. Thomas Clausen has been showing some measurement results (incidentally with somewhat different conclusions) and I think we should ask him to publish his results also as a similar RFC. As well as others who have data.

I also believe that the RFC Editor stream is a good place to put this type of publications.

The one high-level comment that I have is that we should be very careful about conclusions from these types of measurements in the resulting RFCs. Its a natural tendency for people to make generic conclusions when most of the results apply to a specific scenario that they measured, not everything. You also have to be very careful in making system-level applicability statements based on single-packet level performance (e.g., 99% packet reliability => system reliability is good -- I don't know if that's the case or not. We'd have to do the math to really understand if 99% is good or bad). I think the authors, the RFC Editor, and the IESG should all check to make sure there are no too wide ranging conclusions in documents like this.

Finally, I did have some reactions to this specific document. Please consider them as improvement suggestions. It is of particular importance that we pay attention to various conclusions about the good or bad operation of a given IETF technology, as noted above.

----

Section 3 seems to say that nodes send 80% of their traffic to root, but I can't find a statement that says something about the root sending traffic back to the nodes. I think in most realistic cases there will also be acknowledgments. Am I just missing the text that explains the return traffic, or did you not simulate the return traffic at all?

Section 4.3 states that as 90% of nodes are capable of operating under 10 routing table entries, then the protocol is capable of working in constrained nodes. I do not think this can be inferred. If 10% of my nodes have to store significantly larger routing tables (and those nodes are not the root or some other conveniently a priori known device), its not going to help. I still have to deploy more memory to every node.

Section 4.4 should make a similar conclusion about the satisfaction of the latency requirements. Again, if 99% of communications are timely, it may not help satisfy requirements of industrial installations, for instance. The requirements are usually stated as, say, no communication failures within a period of time (say, a month or even a year) that could not be handled with the used reliability mechanisms. These mechanisms could include, for instance, repeated transmissions, acknowledgments, or transmissions to duplicate destinations. If a single packet reliability is 99%, what's the likelihood of the a communications problem in an N device system with communication event frequency F and, say, triple transmissions to ensure reliability? You need to do the math to provide an evaluation of whether 99% is good or bad.
2011-09-07
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
07 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
07 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-09-07
07 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-09-06
07 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-09-06
07 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded
2011-09-05
07 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-09-05
07 Stephen Farrell
[Ballot comment]
- Luckily, I read the PDF. I agree with the comments that
noting its existence in the ascii would be good.

- Documents …
[Ballot comment]
- Luckily, I read the PDF. I agree with the comments that
noting its existence in the ascii would be good.

- Documents such as this are always much more valuable
(IMO) if the underlying simulation code and data can be
made available for others. I don't know if that's
possible here or has been done, but if so, a link
from which those could be downloaded would be a great
addition.

- Figure 1 has two colours for links but doesn't say
why.

- I didn't get the spike to the right in figure 9 - it'd
be no harm to say why that's there for (I guess) node
38. The scaling on that figure could also be better, the
control traffic is hardly visible - a logarithmic scale
would be clearer.

- 1st para of 5.2 is repeated.
- 1st para of 5.2 is repeated.
2011-09-05
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded
2011-09-05
07 Adrian Farrel
[Ballot comment]
I have reviewed this document in accordance with RFC 5742 and am making the following recommendation to the IESG as a response to …
[Ballot comment]
I have reviewed this document in accordance with RFC 5742 and am making the following recommendation to the IESG as a response to be sent to the ISE. The IESG will formally decide on their response on 8th September 2011.

    The IESG has concluded that this work is related to IETF work done in the
    ROLL WG, but this relationship does not prevent publishing

=========

Editorial Comments.

These comments are provided for the information of the authors and ISE.

---

It would be considerably helpful if the document included text
explaining the absence of the figures, giving a URL for the PDF,
and resolving any issues of discrepency between the text and PDF files.

---

Section 1 is not clear on the difference between a hop metric and a
transmission metric. Naifly, one might assume that a pcacket is
transmitted exactly once per hop on the path.

---

The reference to RFC 2119 seems inappropriate in this document.

---

You will want to note that draft-ietf-roll-trickle has been published
as RFC 6206
2011-09-03
07 Stewart Bryant
[Ballot comment]
Picking up from Peter's point I also started to review text version and realized that there must be a pdf version. Many readers …
[Ballot comment]
Picking up from Peter's point I also started to review text version and realized that there must be a pdf version. Many readers will not know this and will not know how to get the pdf version. They would be better served if a note directing them to read the pdf version was provided at the beginning of the document. Indeed the RFC editor may be spared considerable work by making the text version of the document simply the abstract and a pointer to the pdf.

I note that there is no security section to the document. Is this not also mandatory in the independent stream?
2011-09-03
07 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded
2011-08-31
07 Peter Saint-Andre
[Ballot comment]
The PDF version makes for interesting reading. Unfortunately, the ASCII version is considerably less valuable because so much of the text makes reference …
[Ballot comment]
The PDF version makes for interesting reading. Unfortunately, the ASCII version is considerably less valuable because so much of the text makes reference to graphical aspects that are available only in the PDF version.
2011-08-31
07 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-08-26
07 Amanda Baber This document doesn't have an IANA Considerations section, but we understand that it doesn't require any actions.
2011-08-23
07 Adrian Farrel Ballot writeup text changed
2011-08-23
07 Adrian Farrel State changed to IESG Evaluation from Publication Requested.
2011-08-23
07 Adrian Farrel
[Ballot comment]
I have reviewed this document in accordance with RFC 5742 and am making the following recommendation to the IESG as a response to …
[Ballot comment]
I have reviewed this document in accordance with RFC 5742 and am making the following recommendation to the IESG as a response to be sent to the ISE. The IESG will formally decide on their response on 8th September 2011.

    The IESG has concluded that this work is related to IETF work done in the ROLL WG, but
    this relationship does not prevent publishing

=========

Editorial Comments.

These comments are provided for the information of the authors and ISE.

---

It would be considerably helpful if the document included text
explaining the absence of the figures, giving a URL for the PDF,
and resolving any issues of discrepency between the text and PDF files.

---

Section 1 is not clear on the difference between a hop metric and a
transmission metric. Naifly, one might assume that a pcacket is
transmitted exactly once per hop on the path.

---

The reference to RFC 2119 seems inappropriate in this document.

---

You will want to note that draft-ietf-roll-trickle has been published
as RFC 6206
2011-08-23
07 Adrian Farrel [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel
2011-08-23
07 Adrian Farrel Ballot has been issued
2011-08-23
07 Adrian Farrel Created "Approve" ballot
2011-08-23
07 (System) Ballot writeup text was added
2011-08-23
07 (System) Last call text was added
2011-08-23
07 (System) Ballot approval text was added
2011-08-23
07 Adrian Farrel Ballot writeup text changed
2011-08-23
07 Adrian Farrel Telechat date has been changed to 2011-09-08 from 2011-08-25
2011-08-23
07 Adrian Farrel Responsible AD has been changed to Adrian Farrel from Russ Housley
2011-08-22
07 Cindy Morgan
The draft draft-draft-tripathi-roll-rpl-simulation-07
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The …
The draft draft-draft-tripathi-roll-rpl-simulation-07
is ready for publication from the Independent Stream.
Please ask IESG to review it, as set out in RFC 5742.

The following is some background for this draft, please forward it
to IESG along with this request ...

This is an Informational draft describing a simulation of RPL,
a routing protocol designed for Low Power and Lossy networks.

It was reviewed by Craig Partridge, the authors have improved
it in answer to hic comments.

The .txt version of the draft has only placeholders for its
diagrams, however the authors have also published a .pdf version
of the draft that include the diagrams.

Thanks, Nevil (ISE)

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org
2011-08-22
07 Cindy Morgan Draft added in state Publication Requested
2011-08-22
07 Cindy Morgan Placed on agenda for telechat - 2011-08-25
2011-08-22
07 Cindy Morgan [Note]: 'ISE Submission' added
2011-08-16
07 (System) New version available: draft-tripathi-roll-rpl-simulation-07.txt
2011-07-25
07 (System) Document has expired
2011-01-11
06 (System) New version available: draft-tripathi-roll-rpl-simulation-06.txt
2010-12-14
05 (System) New version available: draft-tripathi-roll-rpl-simulation-05.txt
2010-06-12
04 (System) New version available: draft-tripathi-roll-rpl-simulation-04.txt
2010-03-24
03 (System) New version available: draft-tripathi-roll-rpl-simulation-03.txt
2010-01-02
02 (System) New version available: draft-tripathi-roll-rpl-simulation-02.txt
2009-12-22
01 (System) New version available: draft-tripathi-roll-rpl-simulation-01.txt
2009-11-12
00 (System) New version available: draft-tripathi-roll-rpl-simulation-00.txt