Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03

[Philip Levis <[e-mail]>]

On Mar 30, 2010, at 12:46 AM, Joydeep Tripathi wrote:

> Hi,
> 
> We published another draft on Simulation results of RPL. In this
> revision, we added path stretch and delay metric comparison of the
> packets in RPL routing with shortest path routing. We also added
> Simulation results of RPL in a typical home/building routing traffic
> scenario. Thanks to Jerry for providing the details of message length
> and distribution in such a network. Note, we did not attempt to use
> any random topology with a random link quality, cause that might not
> provide us with intuition into how real deployment may behave in
> presence of link quality variation and link PDR distribution. We also
> simulate RPL with a 86 node topology, and in process of simulating it
> in another real network of few thousand nodes.
> 
> This simulation study shows, the path stretch is very less in
> the home/building routing scenario. Also, the delay bound in RPL is
> not worse than that of shortest path routing, showing P2P routing in
> RPL a viable option for this kind of applications in terms of Path quality.
> 
> Looking forward to any comments/suggestions.
> 

Joydeep,

I have concerns with the simulation methodology. In particular:

1) Links are selected randomly. Links in real networks can be correlated in behavior, either due to hardware variations or correlated environmental effects (e.g., interference). The problem with random selection is that as a node has more links, it will inevitably have some good ones. In practice this isn't always true (e.g., a node is near an interference source). This will lead the simulation results to think that RPL behaves better than it does in practice.

2) Links vary on the time scale of 10 minutes and have iid losses within those ten minute intervals. Links are bursty, and protocols respond to bursty losses very differently than iid ones. In particular, retransmission policies.

I'm a big fan of simulation as a debugging tool to find problems early and easily. I'm just very wary of using it for any kind of definite conclusion.

Phil