Re: [Roll] RPL Simulation

["Anders Brandt" <[e-mail]>]

Jerry,
 
>That was what was nice about an AODV concept, because even route repair
was fairly deterministic. 

As far as I am informed some reactive discovery mechanism is still
needed for all the reasons that you list below.

You may remember that we have the same needs in home automation.
By utilizing the fact that source routing is already used to jump
between RPL-capable routers AND the fact that the (time critical)
point-to-point communication is limited to 5 hops or less, some
TTL-aware, source-route-based AODV hybrid may not cause so
much flooding as one could fear.
 
- Anders
 
 
________________________________

From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Thursday, January 14, 2010 19:11
To: Joydeep Tripathi
Cc: ROLL WG
Subject: Re: [Roll] RPL Simulation



Hi Joydeep, 

Mukul's been doing some simulations for my company for the past 3 years.
He has a good handle on the commercial building performance
requirements.  It would be good for you to run those he notes below.  It
might be advantageous then for you two to share the results to better
correlate the simulations. 

I would also look at the latency for P2P messages when the packet(s)
need to traverse the DAG all the way up to the LBR and back down to the
destination node.  Of course, this is now a function on DAG depth.  Also
since all our messages require ACK, the additional latency of the ACK
having to return possibly through a different set of nodes yet via the
LBR.  That would be the worst case scenario.  If other nodes could short
circuit the packets through a shorter path, that would on;y help. 

Since Building systems are real-time (smoke/fire detection, turning on
lights, etc) latency is a big issue.  Moving the packet up and down the
DAG is reasonably deterministic and should be primarily a function of
the DAG depth.  However, what will really affect the system performance
is 'DAG Repair'.  I have no sense how long a packet in transit would
have to wait if the DAG was under repair.  Since we require ACKs of
every message, the source node would time-out and retry a few times
(usually 3).  After that, the source node would have to fall into some
'failsoft' mode depending on the type of data it was trying to access.
This is not a good situation.  The source node can only assume that its
data is inaccessible, not just held up in transit.  The fail-soft mode
will have large hysteresis since it can't be constantly dithering
between modes.  This will all be logged to the operator which is a bad
thing!!!  That was what was nice about an AODV concept, because even
route repair was fairly deterministic. 

So... if your simulation could measure packet latency as a function of
DAG repair severity, that would be terrific. 

Hope this makes sense. 

Jerry 



  



Mukul Goyal <[e-mail]> 

01/13/2010 10:17 AM 

To
Joydeep Tripathi <[e-mail]> 
cc
ROLL WG <[e-mail]>, Jerald P Martocci <[e-mail]> 
Subject
Re: [Roll] RPL Simulation

	




Joydeep

Here are a few suggestions for your simulations:

1. Simulate a 100 node and a 1000 node topology operating under a single
DAG

2. Simulate both scenarios: optimal DAG routes (ie the path through the
DAG from a source to a destination passes through their closest common
ancestor) and DAG routes through root (all DAG paths have to go through
the DAG root).

3. Study the stretch factor (increase in length/cost of routes over the
DAG versus the length/cost of ideal routes) for given number of flows:
100, 1000, 10000 and possibly n*(n-1) flows (where n is the number of
nodes in the topology:
a) the scenario you suggested: Choose 20% flows over 2 hop neighbors,
10% flows over longer paths.
b) randomly selected source and destinations (in n*(n-1) case, from each
possible source node to each possible destination node).

4. In addition to the stretch factor, calculate/simulate the traffic
loads as well as packet loss/delay along the DAG links. Compare these
values against values with ideal P2P routing.

Thanks
Mukul
----- Original Message -----
From: "Joydeep Tripathi" <[e-mail]>
To: "Jerald P Martocci" <[e-mail]>
Cc: "ROLL WG" <[e-mail]>
Sent: Wednesday, January 13, 2010 2:24:36 AM GMT -06:00 US/Canada
Central
Subject: [Roll] RPL Simulation

Hi,

In the next revision, we are also planning to implement a typical
building routing scenario, where 60-70% of the P2P traffic are
confined within 1 hop physical distance and, 20% of the P2P traffic
are to a 2 -hop distance destination, and observe the performance of
RPL against the ideal shortest route. Also, please let us know if
there is any other scenario or traffic pattern you want to be
implemented.

Thanks,
Joydeep
_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll