Subject: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-01

From: Jaudelice de Oliveira <[email-masked]>
Date: Mon, 21 Dec 2009 23:12:04 -0500

Dear WG,

We have just posted draft-tripathi-roll-rpl-simulation-01with a  
detailed performance evaluation of RPL for several metrics of  
interest (please see PDF file with plots). We are currently working  
on results with local repair and shall post them shortly. We would  
love feedback/suggestions from the WG. Are there other metrics you  
would like to see?

Cheers,

Jau.

Jaudelice C. de Oliveira
Associate Professor
ECE Dept., Drexel University
http://www.ece.drexel.edu/faculty/deoliveira/

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: December 21, 2009 10:58:21 PM EST
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for  draft-tripathi-roll-rpl- 
> simulation-01
>
>
> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has  
> been successfuly submitted by Jaudelice Oliveira and posted to the  
> IETF repository.
>
> Filename:	 draft-tripathi-roll-rpl-simulation
> Revision:	 01
> Title:		 Performance Evaluation of Routing Protocol for Low Power  
> and Lossy Networks (RPL)
> Creation_date:	 2009-12-21
> WG ID:		 Independent Submission
> Number_of_pages: 12
>
> Abstract:
> This document presents a performance evaluation of the Routing
> Protocol for Low power and Lossy Networks (RPL).  Detailed
> simulations are carried out to produce several routing performance
> metrics using a set of real-life scenarios.
>
> Status of this Memo
>
> This Internet-Draft is submitted to IETF in full conformance with the
> provisions of BCP 78 and BCP 79.
>
> Internet-Drafts are working documents of the Internet Engineering
> Task Force (IETF), its areas, and its working groups.  Note that
> other groups may also distribute working documents as Internet-
> Drafts.
>
> Internet-Drafts are draft documents valid for a maximum of six months
> and may be updated, replaced, or obsoleted by other documents at any
> time.  It is inappropriate to use Internet-Drafts as reference
> material or to cite them other than as "work in progress."
>
> The list of current Internet-Drafts can be accessed at
> http://www.ietf.org/ietf/1id-abstracts.txt.
>
> The list of Internet-Draft Shadow Directories can be accessed at
> http://www.ietf.org/shadow.html.
>
> This Internet-Draft will expire on June 24, 2010.
>
> Copyright Notice
>
> Copyright (c) 2009 IETF Trust and the persons identified as the
> document authors.  All rights reserved.
>
> This document is subject to BCP 78 and the IETF Trust's Legal
> Provisions Relating to IETF Documents
> (http://trustee.ietf.org/license-info) in effect on the date of
> publication of this document.  Please review these documents
> carefully, as they describe your rights and restrictions with respect
> to this document.  Code Components extracted from this document must
> include Simplified BSD License text as described in Section 4.e of
> the Trust Legal Provisions and are provided without warranty as
> described in the BSD License.
>
>
>
> The IETF Secretariat.
>
>

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 22 Dec 2009 23:09:59 -0800

It is great to start understanding how RPL would work.

On this file:
http://tools.ietf.org/html/draft-tripathi-roll-rpl-simulation-00

I don't see the figures...

- om_p

On Mon, Dec 21, 2009 at 8:12 PM, Jaudelice de Oliveira
<[email-masked]> wrote:
> Dear WG,
> We have just posted draft-tripathi-roll-rpl-simulation-01with a detailed
> performance evaluation of RPL for several metrics of interest (please see
> PDF file with plots). We are currently working on results with local repair
> and shall post them shortly. We would love feedback/suggestions from the WG.
> Are there other metrics you would like to see?
> Cheers,
> Jau.
>
>
>
>
> Jaudelice C. de Oliveira
> Associate Professor
> Subject: New Version Notification for
> draft-tripathi-roll-rpl-simulation-01
>
> A new version of I-D, draft-tripathi-roll-rpl-simulation-01.txt has been
> successfuly submitted by Jaudelice Oliveira and posted to the IETF
> repository.
> Title: Performance Evaluation of Routing Protocol for Low Power and Lossy
> Networks (RPL)
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 22 Dec 2009 23:52:16 -0800

I managed to find the pdf with the graphs. Here are some comments.

It will help greatly if more information about the link model were
included. -01 mentions:

"* Link failure model: Time varying real network traces containing
packet delivery probability for each
link and over all channels for both indoor network deployment and
outdoor network deployment were used.
Thus, di erent types of link characteristics are used in the study.
* Topology: The topologies are gathered from real-life deployment
(traces mentioned above) as opposed
to random topology simulations. are repeated here:"

Is the simulation topology a topology from real-world deployment or
the one mentioned in figure 1?

Some graphs showing link characteristics (including temporal
characteristics) will also be helpful. Right now, we just know that
the link is modeled on real world deployments. What radio was used?
Indoor/outdoor? And any other relevant information.

These additional information will help us understand how and why of
RPL's performance.

A lot of people are interested in path stretch for p2p routing. Some
of this information is available on the plots but not directly. It
will be great if we can have a plot that shows the distribution of
path stretch for p2p routing.

- om_p

---

From: Stephen Dawson-Haggerty <[email-masked]>
Date: Wed, 23 Dec 2009 13:12:12 -0500

> to random topology simulations. are repeated here:"

Also, it would be great if you could model link bandwidth and packet collisions.  When using low-bandwidth links these become very significant, since each packet may take 5-500ms of air time to transmit. 

Thanks for getting started on this!
Steve

---

From: Hajime Tazaki<[email-masked]>
Date: Thu, 24 Dec 2009 09:26:02 +0900

Dear authors,

I also really wanna see the pdf with figures.

regards,
hajime

At Tue, 22 Dec 2009 23:09:59 -0800,

---

From: Joydeep Tripathi <[email-masked]>
Date: Thu, 24 Dec 2009 01:24:23 -0500

Hi,

For those who cannot find the pdf version, you can click this link

 http://tools.ietf.org/pdf/draft-tripathi-roll-rpl-simulation-01.pdf

Thanks,
Joydeep

>
> On Wed, Dec 23, 2009 at 7:26 PM, Hajime Tazaki <[email-masked]> wrote:
>>
>> Dear authors,
>>

---

From: Joydeep Tripathi <[email-masked]>
Date: Thu, 24 Dec 2009 01:24:41 -0500

> to random topology simulations. are repeated here:"
Actually,we collected real-life traces with hundreds of links varying
with time for the network,  and simulated the same variation in PDR
for each link as in the real deployment.
> the one mentioned in figure 1?

It is indeed from a real life deployment of an indoor network, where
the topology looks like the one shown in figure 1. We have shown a
link between two nodes in the topology if they are heard by each
other.

> Indoor/outdoor? And any other relevant information.

That is a wonderful idea. We will include temporal link
characteristics in further revision which we plan to submit very soon.

> path stretch for p2p routing.

We also plan to show this metric, keeping in mind the typical
scenarios of P2P routing in building and home routing (or any other
interesting scenario, on request). Once again, thanks for your
feedback.

Thanks,
Joydeep

>> >> detailed
>> >> been

---

From: Joydeep Tripathi <[email-masked]>
Date: Tue, 29 Dec 2009 18:58:33 -0500

Hi,

On Thu, Dec 24, 2009 at 2:25 AM, Philip Levis <[email-masked]> wrote:
>
> On Dec 23, 2009, at 10:24 PM, Joydeep Tripathi wrote:
>
> I don't understand -- how do you do this? There has to be some interval over
> which you average, unless you are replaying success/failure traces. Link can
> very much faster than every ten seconds.

Actually you are right, the PDR value of a link is averaged over 100
packets over an interval. When the trace was gathered, during each 15
minutes interval, 100 packets are transmitted over a link in the
network. Out of 100 packets, number of successfully received packets
was count for each link between two communicating nodes that are
physically one hop away. The number of successfully received packets
out of 100 packets originally transmitted was recorded as the PDR of
the link after each 15 minutes interval. In our simulation, we
consider the PDR between those two nodes to be constant during a 10
minutes interval. When an interval gets over, we consider the next PDR
value between same two nodes in the database of traces, that was
collected during the next interval and use that value for next
interval.

I hope this clarifies how the link quality traces are gathered and
used. Please let me know if you have further questions.

Thanks,
Joydeep
> Phil

---

From: Omprakash Gnawali <[email-masked]>
Date: Tue, 29 Dec 2009 19:17:34 -0500

> used. Please let me know if you have further questions.

Each node sends a packet every 9 seconds to estimate the link quality
and the estimate is updated every 100 packets?

Do you consider datarate in your simulation?

I did not understand why data collection uses a window of 15 mins and
data use uses a window of 10 mins.

- om_p

---

From: Joydeep Tripathi <[email-masked]>
Date: Tue, 29 Dec 2009 20:11:59 -0500

> Do you consider datarate in your simulation?

When the link  trace was gathered, I believe the intention was to
check how the connectivity between the nodes vary over time. The trace
reflects the quality of the links between the nodes, and the packets
used for trace gathering in real implementation did not use RPL
headers. However, in our simulation, we considered RPL headers, MAC
headers etc. For simulation, we also used specifications of TelosB
CC2420 radio, which has a datarate of 250 Kbps.

> data use uses a window of 10 mins.

The simulation used a 10 minute window to update PDR for every link.
However, in simulation also, the links have same temporal
characteristics as seen in the real link quality trace gathering. The
10 minutes interval is just to make the simulation generic to other
gathered traces from other deployment as well. There may be traces
which update the link quality after an interval other than 15 minutes
(we do have such traces). We will include samples of link quality (in
terms of PDR) in our next revision as well.

---

From: Philip Levis <[email-masked]>
Date: Tue, 29 Dec 2009 18:19:20 -0800

> terms of PDR) in our next revision as well.

Jodeep,

It's worth noting that links can vary as quickly as 500ms or less[1]. So 10 minute variations ignore some of the short-term dynamics you might see. This is especially important for problems like establishing an efficient yet reasonably stable tree.

Phil

[1] Kannan Srinivasan, Maria A. Kazandjieva, Saatvik Agarwal, Philip Levis: The beta-factor: measuring wireless link burstiness. SenSys 2008: 29-42