Subject: Re: [Roll] RPL Simulation

From: Mukul Goyal <[email-masked]>
Date: Wed, 13 Jan 2010 10:17:09 -0600 (CST)

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

---

From: [email-masked]
Date: Thu, 14 Jan 2010 12:10:38 -0600

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

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,

Thanks,
Joydeep

---

From: Emmanuel Baccelli <[email-masked]>
Date: Fri, 15 Jan 2010 14:39:19 +0100

Hi Joydeep,

I concur with Jerry and Mukul. More studies, in particular on route stretch
and delays with the use of RPL as it stands for now, are  needed in order to
validate the current design with respect to the goals RPL attempts at
achieving.

Regards,

Emmanuel

On Thu, Jan 14, 2010 at 7:10 PM, <[email-masked]> wrote:

> 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.
>
> 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.
>
>  *Mukul Goyal <[email-masked]>*
>
> 01/13/2010 10:17 AM
>   To
> 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:

---

From: Joydeep Tripathi <[email-masked]>
Date: Fri, 15 Jan 2010 18:25:32 -0500

Hi,

Thanks a ton for your feedback. We will look into simulating the specific
routing scenarios and coming up with latency result and path stretch.

Thanks,
Joydeep

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 19 Jan 2010 16:14:48 +0100

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: [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 

01/13/2010 10:17 AM 

To

Joydeep

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

Hi,

Thanks,
Joydeep

---

From: JP Vasseur <[email-masked]>
Date: Tue, 26 Jan 2010 15:18:48 +0100

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  
>>>>> As far as I am informed some reactive discovery mechanism is  
>>>>> still needed for all the reasons that you list below.
>>>>> By utilizing the fact that source routing is already used to  
>>>>> jump between RPL-capable routers AND the fact that the (time  
>>>>> critical)
>>>> 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]
>>>>> 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  
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ROLL WG <[email-masked]>, Jerald P Martocci <[email-masked] 
>>>>> >
>>>>> Subject
>>>>> 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:
>>>>> 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

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 26 Jan 2010 16:08:22 +0100

Hi JP
 
I see two assumptions which I would like to discuss:
 
1) "...as soon as it becomes operational, A can send a DAO ..."
   The point is that A has been operational all the time. RF conditions
just changed
   so that A cannot be reached via R3. Therefore A is not even aware
that it is missing
   a parent => it may not send a DAO for the next many minutes
 
2) "..If you are using a reactive mechanism instead of  proactive, this
is not a magic solution either ..."
   Sure. We agree in this. As discussed on the RPL editor list recently,
using the flooding trick is
   a backup option which should only be used if you are in a hurry -
which users turning on light are always.
   Also, the scope of that flooding does not need to be more than a
diameter of 5 hops. This would suffice
   for home as well as for building applications.
   I do not argue for flooding the entire Internet!
 
Cheers,
  Anders 

From: JP Vasseur [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 15:19
To: Anders Brandt
Cc: ROLL WG
Subject: Re: SV: [Roll] RPL Simulation in the home

Anders>

		Anyway,
		 
		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.

So you raise the issue of convergence time, fair. It all depends on how
you tune RPL and A

Thanks.

JP.

		Thanks,
		  Anders

		Hi Anders, 

			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?

			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

			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.

				
				 
				> 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
				
				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 

				

01/13/2010 10:17 AM 

To

				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

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 26 Jan 2010 10:30:12 -0600 (CST)

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.

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

Anders> 

Anyway, 
  
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. 

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, 

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? 

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, 

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. 

  
> 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? 

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. 

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 

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, 

Thanks, 
Joydeep

---

From: JP Vasseur <[email-masked]>
Date: Tue, 26 Jan 2010 18:01:12 +0100

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.

> If the DAG can re-establish contact within 250ms to an operational  
> node that was just lost in a routing table,
> point-to-point communication is limited to 5 hops or less, some TTL- 
> aware, source-route-based AODV hybrid may not cause so
> 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.
>
> 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
>
>
>
>
>
> cc 	ROLL WG < [email-masked] >, Jerald P Martocci < [email-masked] 
>  >
>
> 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:
> b) randomly selected source and destinations (in n*(n-1) case, from  
> each possible source node to each possible destination node).
>
> loads as well as packet loss/delay along the DAG links. Compare  
> these values against values with ideal P2P routing.
>
> Thanks
> Mukul

---

From: [email-masked]
Date: Tue, 26 Jan 2010 11:20:20 -0600

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,

Several answers here:

Makes sense ?

Thanks.

JP.

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 09:47:03 -0800

Hi Jerry,

I think the note below correctly reflects building automation requirements.
Having 1000 devices on a building floor would not be a surprise.

The trouble with reactive route discovery is many of the existing MANET
protocols like AODV scale with the number of devices in the network (so have
to be tailored by deployment).   For example, route table size is an example
of a scaling resource in AODV.  I think in cases where there is a needed
reactive route discovery, we need to identify how to avoid making the
solution scale with deployment while still supporting low latency messaging.

Don

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, January 26, 2010 9:20 AM
To: JP Vasseur
Cc: ROLL WG; Mukul Goyal; [email-masked]
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation
in the home

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. 

Regards, 

Jerry 

01/26/2010 11:01 AM 

To

cc

ROLL WG <[email-masked]> 

Subject

		

Hi Mukul,

Several answers here:

Makes sense ?

Thanks.

JP.

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 26 Jan 2010 12:19:21 -0600 (CST)

Just to add to the 2nd point Jerry raised: I am not sure how prefix aggregation is going to work in 6lowpan/ROLL networks. Neither were most of people I talked to in this regard. So, there is a need for a document (or a section in RPL draft) explaining in detail how this would be done.

Thanks
Mukul
 
----- Original Message -----
From: "Jerald P Martocci" <[email-masked]>
To: "JP Vasseur" <[email-masked]>
Cc: "Mukul Goyal" <[email-masked]>, "ROLL WG" <[email-masked]>, [email-masked]
Sent: Tuesday, January 26, 2010 11:20:20 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation	in the home

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 

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, 

Several answers here: 

Makes sense ? 

Thanks. 

JP. 

>  >

---

From: [email-masked]
Date: Tue, 26 Jan 2010 13:20:39 -0600

Hey Don,

I guess I miss your point.  If we use the proactive model then for a 1000 
node LLN, each node will have to define and maintain routes to 999 other 
nodes on the oft chance that a message needs to be sent to any random node 
on the LLN.  This seems way less scalable than keeping a 'least recently 
used' list of links that the node has needed to communicate to in the 
recent past.

Also, I am not sure why you think AODV overhead is a function of node 
count.  If my room controller needs to talk to its temperature, occupancy 
and humidity sensor, it doesn't really care if there are 10 other nodes in 
the LLN or 1000 other nodes.  To me, scalability has to do with the 
application requirements, not the LLN size.

Jerry

"Don Sturek" <[email-masked]> 
01/26/2010 11:47 AM
Please respond to
<[email-masked]>

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

Hi Jerry,
 
I think the note below correctly reflects building automation 
requirements.   Having 1000 devices on a building floor would not be a 
surprise.
 
The trouble with reactive route discovery is many of the existing MANET 
protocols like AODV scale with the number of devices in the network (so 
have to be tailored by deployment).   For example, route table size is an 
example of a scaling resource in AODV.  I think in cases where there is a 
needed reactive route discovery, we need to identify how to avoid making 
the solution scale with deployment while still supporting low latency 
messaging.
 
Don

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

Hi JP, 

My $.02 on your answers: 

Regards, 

Jerry 

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,

Several answers here:

Makes sense ?

Thanks.

JP.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Jan 2010 20:25:11 +0100

> used' list of links that the node has needed to communicate to in the
1000 Nodes is no problem with proactive protocolls. I have yet to see 
experiments with 10000 nodes how well AODV does scale (experiments, not just 
simulations).

Henning Rogge

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 26 Jan 2010 13:57:30 -0600 (CST)

Henning,

We clearly do not want a route discovery based on immediate network-wide broadcast of route request messages (as in AODV). But we could still come up with a reactive approach that suits the needs of LLNs.

Thanks
Mukul

----- Original Message -----
From: "Henning Rogge" <[email-masked]>
To: [email-masked]
Cc: "Jerald P Martocci" <[email-masked]>, "d sturek" <[email-masked]>, "Mukul Goyal" <[email-masked]>, [email-masked]
Sent: Tuesday, January 26, 2010 1:25:11 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL  Simulation	in the home

Henning Rogge

---

From: "Anders Brandt" <[email-masked]>
Date: Tue, 26 Jan 2010 21:31:01 +0100

Henning,
 
The trick is that we can limit the scope.
We do not want to scan the entire Internet.
 
For home and building, a TTL limiting the discovery to 4 repeater nodes would do the work.
Combine this with a dampening function which prevents repeaters from forwarding discovery messages if n other repeaters within direct reach already forwarded the same message and your broadcast storm is converted to a controlled wavefront forming a circle outwards.
Piggyback the "Light on" command on the discovery message and your latency is drastically reduced.
Finally, let the Discovery result message kill all pending discovery messages scheduled for later transmission.
 
As Jerry said, cache the discovered route and use it the next time.
 
Individually very simple mechanisms. Together, extremely efficient.
 
I may add that this runs in the real world.
 
Cheers,
  Anders.

Fra: [email-masked] på vegne af Henning Rogge
Sendt: ti 26-01-2010 20:25
Til: [email-masked]
Cc: [email-masked]
Emne: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home

Henning Rogge

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 12:25:22 -0800

Hi Jerry,

The issue with AODV is you need a route table in each router to indicate the
next hop in the path.  The more next hop options you have for a given router
(as in a large network) the more table entries you need.  Additionally, AODV
uses flooding to establish routes so you also have to accommodate route
discovery entries that grow with the number of devices in the network (maybe
not "order n" but will definitely grow)

A network of size 6 would have very different AODV resource requirements
than a network of size 1000 since the route table and route discovery tables
would be very different in size.  For a device manufacturer, there must be
planning in advance based on expected network topology to size the AODV
resources correctly.  

Don

From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 11:21 AM
To: [email-masked]
Cc: 'JP Vasseur'; 'Mukul Goyal'; 'ROLL WG'; [email-masked]
Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPL Simulation
in the home

Hey Don, 

used' list of links that the node has needed to communicate to in the recent
past. 

Also, I am not sure why you think AODV overhead is a function of node count.
If my room controller needs to talk to its temperature, occupancy and
humidity sensor, it doesn't really care if there are 10 other nodes in the
LLN or 1000 other nodes.  To me, scalability has to do with the application
requirements, not the LLN size. 

Jerry 

01/26/2010 11:47 AM 

Please respond to
<[email-masked]>

To

cc

Subject

		

Hi Jerry, 

Don 

Hi JP, 

My $.02 on your answers: 

Regards, 

Jerry 

01/26/2010 11:01 AM 

To

cc

ROLL WG <[email-masked]> 

Subject

  

Hi Mukul,

Several answers here:

Makes sense ?

Thanks.

JP.

---

From: Philip Levis <[email-masked]>
Date: Tue, 26 Jan 2010 12:45:37 -0800

> We clearly do not want a route discovery based on immediate network-wide broadcast of route request messages (as in AODV). But we could still come up with a reactive approach that suits the needs o…

Mukul,

The goal here isn't to invent a new algorithm: that's the province of the IRTF and the research community. Our goal is to build on existing practice and define a standard.

Phil

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 12:52:35 -0800

Hi Henning,

I think 1000 nodes in AODV is no problem if you know in advance you are
dealing with a 1000 node deployment.

The trouble comes when you size for something significantly different from
1000.....

This is why I really liked the DAG in ROLL RPL.  No matter how many devices
are part of the network, the resource requirements are the same.  The trick
is to figure out how to deal with routing failures in the DAG now such that
we don't lose low latency for applications like building automation.

Don

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 11:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

Am Dienstag 26 Januar 2010 20:20:39 schrieb [email-masked]:
> Hey Don,
> 
> I guess I miss your point.  If we use the proactive model then for a 
> 1000 node LLN, each node will have to define and maintain routes to 
> 999 other nodes on the oft chance that a message needs to be sent to 
> any random node on the LLN.  This seems way less scalable than keeping 
> a 'least recently used' list of links that the node has needed to 
> communicate to in the recent past.

Henning Rogge

---

From: "Skip Ashton" <[email-masked]>
Date: Tue, 26 Jan 2010 16:07:23 -0500

While the DAG may not care how many devices are in the network - that is
because it is only setting up one direction of the connection needed.
The DIO messages then do require resources on devices in the network or
in the edge routers.  

This is where we have seen very efficient implementations of source
routing and record route in 15.4 networks so bi-directional routes can
be maintained and be reactive without the overhead of these DIO
messages.

Skip 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Sturek
Sent: Tuesday, January 26, 2010 3:53 PM
To: 'Henning Rogge'; [email-masked]
Cc: [email-masked]
Subject: Re: [Roll] Reactive versus Proactive approaches Re:
RPLSimulation in the home

Hi Henning,

The trouble comes when you size for something significantly different
from 1000.....

This is why I really liked the DAG in ROLL RPL.  No matter how many
devices are part of the network, the resource requirements are the same.
The trick is to figure out how to deal with routing failures in the DAG
now such that we don't lose low latency for applications like building
automation.

Don

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 11:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

1000 Nodes is no problem with proactive protocolls. I have yet to see
experiments with 10000 nodes how well AODV does scale (experiments, not
just simulations).

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 26 Jan 2010 22:13:06 +0100

> we don't lose low latency for applications like building automation.
I'm not sure I understand Ripple completely, but infinite meshs (any size) 
with only constant memory requirements (and network requirements) sound a 
little bit overoptimistic.

Henning Rogge

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 13:29:33 -0800

Hi Henning,

I think what we need is not infinite mesh sizes with a constant memory size
but the ability to deploy devices that don't have to be configured or
optimized based on the deployment size.   

Ideally if a device manufacturer could put out devices that could address a
range of deployment topologies and network sizes without customization that
would be great.

Don

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 1:13 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

Am Dienstag 26 Januar 2010 21:52:35 schrieb Don Sturek:
> Hi Henning,
> 
> I think 1000 nodes in AODV is no problem if you know in advance you 
> are dealing with a 1000 node deployment.
> 
> devices are part of the network, the resource requirements are the 
> same.  The trick is to figure out how to deal with routing failures in 
> the DAG now such that we don't lose low latency for applications like
building automation.

Henning Rogge

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 26 Jan 2010 15:38:33 -0600 (CST)

Don,

>are part of the network, the resource requirements are the same. 

Not sure about this. For bidirectional communication, there is a need to store southbound reachability information for all the destinations in the network, which is clearly not constant cost in terms of memory.

Thanks
Mukul

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 11:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

Henning Rogge

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 26 Jan 2010 15:44:50 -0600 (CST)

Hi Don,

>optimized based on the deployment size.   

RPL devices would need to be configured and optimized based on the deployment size and scenario. The need for southbound communication means that memory requirements are not constant irrespective of deployment size. The need for low latency means that protocol delays would need careful configuration. 

>range of deployment topologies and network sizes without customization that

Not sure if RPL meets this goal. (I guess it would be difficult for any protocol to meet this goal.)

Thanks
Mukul

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 1:13 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

building automation.

Henning Rogge

---

From: "Don Sturek" <[email-masked]>
Date: Tue, 26 Jan 2010 13:35:59 -0800

Hi Skip,

I agree there are some optimizations needed around DIO messages.  Source
routing, route record and bi-directional link establishment/asymmetric link
elimination are all very sound strategies.

What is missing right now is recovery for the DAG where routing fails while
maintaining latency.  Hopefully, we can find solutions on this like those
you identified for DIO messages.

Don

-----Original Message-----
From: Skip Ashton [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 1:07 PM
To: [email-masked]; Henning Rogge; [email-masked]
Cc: [email-masked]
Subject: RE: [Roll] Reactive versus Proactive approaches Re: RPLSimulation
in the home

Skip 

-----Original Message-----

Hi Henning,

Don

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 11:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]

Henning Rogge

---

From: [email-masked]
Date: Tue, 26 Jan 2010 16:30:24 -0600

HI Don,

The resource requirements might be the same for northbound only 
applications (e.g. collection networks); however for North/Southbound 
applications (e.g. P2P) source route data must be maintained to every node 
in the DAG since any node might send a message to any other node.

Jerry

01/26/2010 02:52 PM
Please respond to
<[email-masked]>

To
"'Henning Rogge'" <[email-masked]>, <[email-masked]>
cc
<[email-masked]>, "'Mukul Goyal'" <[email-masked]>, 
<[email-masked]>
Subject
RE: [Roll] Reactive versus Proactive approaches Re: RPL  Simulation     in 
the home

Hi Henning,

This is why I really liked the DAG in ROLL RPL.  No matter how many 
devices
are part of the network, the resource requirements are the same.  The 
trick
is to figure out how to deal with routing failures in the DAG now such 
that
we don't lose low latency for applications like building automation.

Don

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: Tuesday, January 26, 2010 11:25 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; 'Mukul Goyal';
[email-masked]
Simulation
in the home

just
simulations).

Henning Rogge

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jan 2010 18:12:16 +0100

Hi Jerry,

On Jan 26, 2010, at 8:20 PM, [email-masked] wrote:

> any random node on the LLN.  This seems way less scalable than  
> keeping a 'least recently used' list of links that the node has  
> needed to communicate to in the recent past.
>

If (1) you do not do any sort of aggregation (look at the Internet, we  
do not keep host routes in routing tables !)
and (2) there is a cost in "flooding" the network each time you need a  
route to a host that is not yet present in
the routing tables.

> Also, I am not sure why you think AODV overhead is a function of  
> node count.  If my room controller needs to talk to its temperature,  
> occupancy and humidity sensor, it doesn't really care if there are  
> 10 other nodes in the LLN or 1000 other nodes.  To me, scalability  
> has to do with the application requirements, not the LLN size.
>
> Jerry
>
>
>
>
>
> "'ROLL WG'" <[email-masked]>, "'Mukul Goyal'" <[email-masked]>, <[email-masked] 
> >
> Subject
> RE: [Roll] Reactive versus Proactive approaches Re: RPL  
> Simulation        in the home
>
>
>
>
>
> Hi Jerry,
>
> requirements.   Having 1000 devices on a building floor would not be  
> a surprise.
>
> The trouble with reactive route discovery is many of the existing  
> MANET protocols like AODV scale with the number of devices in the  
> network (so have to be tailored by deployment).   For example, route  
> table size is an example of a scaling resource in AODV.  I think in  
> cases where there is a needed reactive route discovery, we need to  
> identify how to avoid making the solution scale with deployment  
> while still supporting low latency messaging.
>
> Don
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of [email-masked]
> 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.
>
> Re: [Roll] Reactive versus Proactive approaches Re: RPL  
> Simulation        in the home
>
>
>
>
>
>
>
>
>
> Hi Mukul,
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jan 2010 18:21:25 +0100

Hi Skip,

> be maintained and be reactive without the overhead of these DIO

Let's just bear in mind that RPL is the mechanisms adopted by the WG.
We are chartered to produce one routing protocol that meet the  
requirements
spelled out in the requirements documents.

Thanks.

JP.

> Of
> same.
>> keeping

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jan 2010 18:18:07 +0100

Hi Anders,

Co-chair "hat on", there are many ways to solve an issue. As a WG I  
would just
suggest to first make some analysis on whether the current solution  
does address
your requirements, which it has to, this is why we have requirements  
documents,
without jumping to additional mechanisms/protocols.

Cheers.

JP.

On Jan 26, 2010, at 9:31 PM, Anders Brandt wrote:

> Combine this with a dampening function which prevents repeaters from  
> forwarding discovery messages if n other repeaters within direct  
> reach already forwarded the same message and your broadcast storm is  
> converted to a controlled wavefront forming a circle outwards.
> Finally, let the Discovery result message kill all pending discovery  
> messages scheduled for later transmission.
>

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jan 2010 18:19:16 +0100

On Jan 26, 2010, at 9:52 PM, Don Sturek wrote:

> The trick

Precisely. This is why we will have applicability statements.

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Wed, 27 Jan 2010 18:13:26 +0100

On Jan 26, 2010, at 8:57 PM, Mukul Goyal wrote:

> Henning,
>
> We clearly do not want a route discovery based on immediate network- 
> wide broadcast of route request messages (as in AODV). But we could  
> still come up with a reactive approach that suits the needs of LLNs.

but again let's see where we can get with existing mechanisms before  
jumping to other ones.
Makes sense ?

Thanks.

JP.

> Cc: "Jerald P Martocci" <[email-masked]>, "d sturek" <[email-masked] 
> >, "Mukul Goyal" <[email-masked]>, [email-masked]

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 28 Jan 2010 09:16:18 +0100

Hi JP
 
I am still waiting eagerly for the convincing explanation on how RPL in its current form can guarantee
contact to a node within a not only finite but very well-defined short period of time - a time which is
significantly shorter than any reasonable route update interval.
Yes, I know you think route diversity is the answer. This in itself leads to two new questions:
 
1. Will you use link-layer acks to determine that an IP packet was not delivered?
    If not - how will you then determine the need for using another route?
    If yes - well, then I am happy - I just did not understand that before now.
 
2. How many routes will you try?
   Each new routing attempt takes time and still you have no guarantee that you actually reach the
   node with the information you have (chosen to have - remember: we cannot store all neighbors)
   in your routing tables.
 
Given the issues above, I definitely see the need for a reactive mechanism as a last resort.
I fully agree that it would be nice if trickle-timed updates could do everything for us everytime.
Unfortunately, reality is not always working our way. Home and building requirements clearly state the
need for timely delivery of packets.
 
The notion of a node re-attaching to the DAG is wrong. The node has never realized that it has lost contact.
This sad fact is discovered the very moment when a user presses a button on a lighting switch. This is not
the time to start waiting for DIOs, DAOs and what not. Light has to turn on deterministically quickly after the
button press. Thus the need for the reactive last resort.
Simulations are not needed to understand this situation.
 
It is true that reactive mechanisms tend to flood the network. BUT:
I described a reactive discovery mechanism in a previous mail. The intent is to show you that very simple
tricks can be used to limit the amount of noise distributed in a network.
It can be scaled. It works with a finite response time. If a working node is out there, it is found.
This is what we need for home & building. A last resort to kick in where proactiveness cannot deliver.
 
Thanks,
  Anders

From: JP Vasseur [mailto:[email-masked]] 
Sent: Wednesday, January 27, 2010 18:18
To: Anders Brandt
Cc: Henning Rogge; [email-masked]; [email-masked]
Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL Simulation in the home

Hi Anders, 

Co-chair "hat on", there are many ways to solve an issue. As a WG I would just 
suggest to first make some analysis on whether the current solution does address
your requirements, which it has to, this is why we have requirements documents,
without jumping to additional mechanisms/protocols.

Cheers.

JP.

	Henning,

	 

	 
	Cheers,
	  Anders.

	
	Henning Rogge