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

Philip Levis <pal@cs.stanford.edu> Thu, 01 April 2010 04:35 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314CC3A67F0 for <roll@core3.amsl.com>; Wed, 31 Mar 2010 21:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.014
X-Spam-Level:
X-Spam-Status: No, score=-4.014 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMzjbfg5jBea for <roll@core3.amsl.com>; Wed, 31 Mar 2010 21:35:33 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 1A58C3A67B2 for <roll@ietf.org>; Wed, 31 Mar 2010 21:35:33 -0700 (PDT)
Received: from [76.14.71.8] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from <pal@cs.stanford.edu>) id 1NxC8S-0002Gr-Oz; Wed, 31 Mar 2010 21:36:05 -0700
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <i2ue9ba5eb81003312031j567b7ccdz43cdba7dccc0ec34@mail.gmail.com>
Date: Wed, 31 Mar 2010 21:36:04 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <55F65F58-A813-4D50-969B-D17C1C3BC027@cs.stanford.edu>
References: <19e8ae197e37.197e3719e8ae@drexel.edu> <e9ba5eb81003300046h10eb34cbmb74cb4fb22e5359c@mail.gmail.com> <B33A68D5-C90B-4139-BE17-12D35D6C9F64@cs.stanford.edu> <i2ue9ba5eb81003312031j567b7ccdz43cdba7dccc0ec34@mail.gmail.com>
To: Joydeep Tripathi <joydeep.tripathi@gmail.com>
X-Mailer: Apple Mail (2.1077)
X-Scan-Signature: 34530ccd932157cd24ba9d2c27818ca4
Cc: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] Fwd: New Version Notification for draft-tripathi-roll-rpl-simulation-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Apr 2010 04:35:34 -0000

On Mar 31, 2010, at 8:31 PM, Joydeep Tripathi wrote:

> On Tue, Mar 30, 2010 at 1:29 PM, Philip Levis <pal@cs.stanford.edu> wrote:
>> 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.
> 
> Hi,
> 
> I understand your concern. But these link data have been gathered from
> a real network. We will also try acquiring more data, where the link
> PDR may vary much more faster. We are also in the process a bigger
> network data and come up with simulation result for a bigger scale
> real network with real PDR variation.

Joydeep,

I realize those data have been collected from a real network. I collect data from real networks too. :)

The issue is not a network where the link PDR varies much faster: the issue is the interval over which you compute the PDR. Do you have experimental evidence that links exhibit iid losses for 10 minute stretches? This goes against most measurement studies and RF communication theory.

The question here isn't size or scale: it's accuracy. Smoothing over details such as these can lead to incorrect conclusions. E.g., if a link has independent losses, the retransmissions can be used for arbitrary reliability. A simulation could demonstrate perfect reliability with low latency, something which clearly isn't true in practice.

Phil