Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home

From: [email-masked]
Date: Mon, 1 Feb 2010 15:45:03 -0600

Hi Joydeep,

Attached is a spreadsheet we developed in 2005 that described the device 
density, packet sizes, hops and packet densities into various kinds of 
buildings.  I think it should answer your questions.  It might require a 
bit more explanation to make the data obvious.  Don't hesitate to write or 
call.

Regards,

Jerry

Joydeep Tripathi <[email-masked]> 
01/31/2010 04:55 PM

To
"jerald.p.martocci" <[email-masked]>
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the 
home

Hi Jerry,

Thanks a lot for the information you provided on simulation details, we're 
making excellent progress on the P2P simulation results which will be 
posted soon in the next revision. Could you just tell us which packet size 
we should be using and the average number of packets? Then we could 
provide with you with actual delay bound for P2P routing. 

Thanks,
Joydeep

--- On Tue, 1/26/10, [email-masked] <[email-masked]> 
wrote:

From: [email-masked] <[email-masked]>
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL 
Simulation in the home
To: "JP Vasseur" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "Mukul Goyal" <[email-masked]>, 
[email-masked]
Date: Tuesday, January 26, 2010, 12:20 PM

Hi JP, 

My $.02 on your answers: 

1) In a building there may 1000 devices in an LLN; hence even if Anders 
does not have this requirement for a home, I do have this requirement for 
a building. 

2) My understanding is that for 6LoWPAN networks all devices are on a flat 
network (i.e. all LLN nodes have the same prefix) (see RFC 4944); hence 
there is no way to aggregate routes. 

2a) Source/destination routes are completely random; hence there is no a 
priori way to preselect routes. 

Regards, 

Jerry 

JP Vasseur <[email-masked]> 
Sent by: [email-masked] 
01/26/2010 11:01 AM 

To
Mukul Goyal <[email-masked]> 
cc
ROLL WG <[email-masked]> 
Subject
Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation       
 in the home

Hi Mukul,

On Jan 26, 2010, at 5:30 PM, Mukul Goyal wrote:

> JP,
>
> The obvious problem with proactive approaches, such as RPL, is the  
> need to maintain reachability information for all possible  
> destinations to which some source might send a packet some day.  
> That's why we need source-initiated route discovery, i.e. a reactive  
> approach.
>

Several answers here:
1) Are there such as huge number of unicast addresses in a home ?
2) In so, this is where route aggregation/summarization can help.

This is why I'm challenging the need for an a priori reactive  
mechanism here before we prove that
reactive is not good enough.

Makes sense ?

ps: again acting with no co-chair hat.

Thanks.

JP.

> Thanks
> Mukul
>
> ----- Original Message -----
> From: "JP Vasseur" <[email-masked]>
> To: "Anders Brandt" <[email-masked]>
> Cc: "ROLL WG" <[email-masked]>
> Sent: Tuesday, January 26, 2010 8:18:48 AM GMT -06:00 US/Canada  
> Central
> Subject: Re: [Roll] RPL Simulation in the home
>
>
> Copying the list to continue that discussion - see below
>
>
>
> Anders>
>
>
>
>
>
>
>
>
>
>
>
> Anyway,
> the use case is quite simple:
>
> Z - R1 - R2 - R3 - A
>
> 1) Lamp module A was recently controlled by controller Z via router  
> 1 -> router 2 -> router 3
>
>  Z - R1 - R2 - R3 - A
>
> 2) Something renders the radio connection unusable from router 3 to  
> lamp module A
> 3) The lamp module can however be reached via router 1 -> router 4 - 
> > router 5
>    but router 5 has never been routing traffic to lamp module A
>
>  Z - R1 - R2 - R3 - .
>        \
>         - R4 - R5 - A
> 4) Controller Z sends another command to lamp module A via router 1
> 5) Router 1 sends the command to router 2 which forwards the command  
> to router 3
> 6) Router 3 is unable to deliver the command
>
> What happens now?
>
>
> This is exactly why I was asking you the reason why you think that  
> it should be reactive.
> What you describe is routing protocol convergence, which of course  
> does not imply that the
> protocol should be reactive. This is a typical case where the  
> topology is changing and RPL
> needs to adapt to it, which it does. The way to meet your time  
> requirements is to adjust
> the RPL parameters to make it quicker to converge. If there is a  
> link between A and R5,
> as soon as it becomes operational, A can send a DAO and R1 will  
> direct the traffic to R4
> instead of R2.
>
>
>
>
> Will the lamp go on within 250ms?
>
>
>
> So you raise the issue of convergence time, fair. It all depends on  
> how you tune RPL and A
> selects R5 as a new parent. Note that you do not have to keep  
> sending control traffic for
> that. If you links are extremely lossy you will have to make the DAG  
> fairly reactive, which
> means more control traffic of course. If you are using a reactive  
> mechanism instead of
> proactive, this is not a magic solution either since you flood your  
> network and add control
> messages too.
>
>
> What I think is that by using these mechanism you can achieve a good  
> level of convergence
> time with reasonable traffic in presence of lossy link w/o too much  
> control traffic. We can try
> to quantify if you can provide an example topology, few stats on the  
> link flaps trying few RPL
> tuning. Could you ?
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
>
>
>
>
> Thanks,
>  Anders
>
>
> From: JP Vasseur [ mailto:[email-masked] ]
> Sent: Thursday, January 21, 2010 09:11
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 21, 2010, at 8:47 AM, Anders Brandt wrote:
>
>
>
>
> Sorry JP
>
> I really have no intention of spreading FUD.
> Guess this mainly indicates that I and Jerry need education of what  
> RPL is expected/able to deliver.
>
> At the most recent telecon we again touched the issue of e.g. a lamp  
> module which due to rf phenomena
> cannot be reached via the recent router - and I thought we had a  
> common understanding that some reactive mechanism
> would be needed.
>
> Can RPL - in its current shape - identify a new route via a router  
> which did not previously forward traffic to said lamp module?
>
>
>
> Not sure of what you mean by this ?
>
>
>
>
> I would love that but I need to understand how - and I would love to  
> see your evidence!
>
>
>
> Here is what I can propose: could you provide a home network  
> topology that I could use to provide
> simulations results ?
>
>
> Cheers.
>
>
> JP.
>
>
>
>
> Thanks,
>  Anders
>
>
>
> From: JP Vasseur [ mailto:[email-masked] ]
> Sent: Wednesday, January 20, 2010 18:21
> To: Anders Brandt
> Subject: Re: SV: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
>
> On Jan 20, 2010, at 5:44 PM, Anders Brandt wrote:
>
>
>
>
>
>
> Hi JP
>
>> Are you saying that RPL is not good enough for P2P  in home and  
>> building?
>
> Well - which incarnation of RPL? (!)
> I was of the impression that we had a common understanding that the  
> ability to
> operate in a reactive fasion is critical to home & building and that  
> the DAG update
> signaling currently designed will have much bigger delays than the  
> 250ms real-time
> users will tolerate.
>
>
> Where does that come from ?
>
>
>
>
>
>
>
>> Since I have evidence that it is not the case.
>> Do you have data that shows different results ?
>
> I may have misunderstood the telecon conclusions, but I got it so  
> that over time
> DAG routes will reconstructed, but that the current spec cannot find  
> a lost target on demand (?).
>
>
>> Because as you know it is now in our charter to work on other  
>> protocols.
> now? I guess you mean "not" ? (!)
> My conclusion from the Rolle interim was that we needed something  
> special to find routes across the cloud.
> If the DAG can re-establish contact within 250ms to an operational  
> node that was just lost in a routing table,
> I would really love it. Is that the case?
>
>
> mmm I do not think so ... happy to discuss it live with you though.
>
>
> Cheers!
>
>
> JP.
>
>
>
>
>
>
>
> Cheers,
>  Anders
>
>
> Fra: JP Vasseur [ mailto:[email-masked] ]
> Sendt: on 20-01-2010 17:02
> Til: Anders Brandt
> Emne: Re: [Roll] RPL Simulation
>
>
> Hi Anders,
>
>
> off-line first.
>
>
>
> On Jan 19, 2010, at 4:14 PM, Anders Brandt wrote:
>
>
>
>
> 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.
>
>
>
> Are you saying that RPL is not good enough for P2P  in home and  
> building ? Since I have evidence that it is not the case.
> Do you have data that shows different results ?
> Because as you know it is now in our charter to work on other  
> protocols.
>
>
> Thanks.
>
>
> JP.
>
>
>
>
>
> - Anders
>
>
>
> From: [email-masked] [ mailto:[email-masked] ] On  
> Behalf Of [email-masked]
> 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 < [email-masked] >
>
> 01/13/2010 10:17 AM                  
> To                  Joydeep Tripathi < [email-masked] >
>
> cc                  ROLL WG < [email-masked] >, Jerald P Martocci < 
[email-masked] 
>  >
>
> 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" < [email-masked] >
> To: "Jerald P Martocci" < [email-masked] >
> Cc: "ROLL WG" < [email-masked] >
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

-----Inline Attachment Follows-----

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Joydeep Tripathi <[email-masked]>
Date: Mon, 1 Feb 2010 17:03:12 -0500

Hi Jerry,

Thanks a lot for the information. Currently we are using the same hop
distance distribution for building routing. We will use the informations
while simulating.

Thanks,
Joydeep

On Mon, Feb 1, 2010 at 4:45 PM, <[email-masked]> wrote:

> buildings.  I think it should answer your questions.  It might require a bit
> more explanation to make the data obvious.  Don't hesitate to write or call.
>
> Regards,
>
> Jerry
>
>
>
>
>
>
>
>
>  *Joydeep Tripathi <[email-masked]>*
>
> 01/31/2010 04:55 PM
>   To
> Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in
>   the home
>
>
>
>
>
> Hi Jerry,
>
> making excellent progress on the P2P simulation results which will be posted
> soon in the next revision. Could you just tell us which packet size we
> should be using and the average number of packets? Then we could provide
> with you with actual delay bound for P2P routing.
>
> Thanks,
> Joydeep
>
>  --- On *Tue, 1/26/10, [email-masked]*<[email-masked]>
> * <[email-masked]* <[email-masked]>*>* wrote:
>
> From: [email-masked]* <[email-masked]> <*
> [email-masked]* <[email-masked]>>
> Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation
> in the home
> To: "JP Vasseur" <[email-masked]* <[email-masked]>>
> Cc: "ROLL WG" <[email-masked]* <[email-masked]>>, "Mukul Goyal" <*
> [email-masked]* <[email-masked]>>, [email-masked]*<[email-masked]>
> does not have this requirement for a home, I do have this requirement for a
> building.
>
>  *JP Vasseur <[email-masked]* <[email-masked]>*>*
> Sent by: [email-masked]* <[email-masked]>
>
> 01/26/2010 11:01 AM
>
>   To
> Mukul Goyal <[email-masked]* <[email-masked]>>
> cc
> ROLL WG <[email-masked]* <[email-masked]>>
> Subject
> > From: "JP Vasseur" <[email-masked]* <[email-masked]>>
> > To: "Anders Brandt" <[email-masked]* <[email-masked]>>
> > Cc: "ROLL WG" <[email-masked]* <[email-masked]>>
> > From: JP Vasseur [ mailto:[email-masked]* <[email-masked]> ]
> > From: JP Vasseur [ mailto:[email-masked]* <[email-masked]> ]
> > Fra: JP Vasseur [ mailto:[email-masked]* <[email-masked]> ]
> > From: [email-masked]* <[email-masked]> [ mailto:*
> [email-masked]* <[email-masked]> ] On
> > Behalf Of [email-masked]* <[email-masked]>
> > Mukul Goyal < [email-masked]* <[email-masked]> >
> >
> > 01/13/2010 10:17 AM
> > To                  Joydeep Tripathi < [email-masked]*<[email-masked]>>
> >
> > cc                  ROLL WG < [email-masked]* <[email-masked]> >, Jerald
> P Martocci < [email-masked]* <[email-masked]>
> >  >
> >
> > From: "Joydeep Tripathi" < [email-masked]*<[email-masked]>>
> > To: "Jerald P Martocci" < [email-masked]*<[email-masked]>>
> > Cc: "ROLL WG" < [email-masked]* <[email-masked]> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/roll*<https://www.ietf.org/mailman/listinfo/roll>
> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/roll*<https://www.ietf.org/mailman/listinfo/roll>
> >
> >
> >
> >
> >
> >
> > [email-masked]* <[email-masked]>
> > *https://www.ietf.org/mailman/listinfo/roll*<https://www.ietf.org/mailman/listinfo/roll>
>
> Roll mailing list*
> [email-masked]* <[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/roll*<https://www.ietf.org/mailman/listinfo/roll>
>
>
> Roll mailing list*
> [email-masked]* <http://mc/compose?to=[email-masked]>*
> **https://www.ietf.org/mailman/listinfo/roll*<https://www.ietf.org/mailman/listinfo/roll>
>
>
>