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 |