Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL

From: "Reddy, Joseph" <[email-masked]>
Date: Thu, 28 Jan 2010 11:30:57 -0600

Hi JP,

I agree that proactive routing does not necessarily mean larger delays in setting up a route.  However, it usually has a larger delay in "detecting" a route failure. 

In most situations, a link failure is usually detected first on the sender side. So I think having a discovery/recovery mechansim that can be initiated by the source device is necessary to meet the latency requirements for the more demanding applications ( like lighting etc. )

-Regards, Joseph

>>Message: 2
>>Date: Wed, 27 Jan 2010 18:09:46 +0100
>>From: JP Vasseur <[email-masked]>
>>Subject: Re: [Roll] Reactive versus Proactive approaches Re: RPL
>>	Simulation	in the home
>>To: Mukul Goyal <[email-masked]>
>>Cc: ROLL WG <[email-masked]>
>>Message-ID: <[email-masked]>
>>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>>Hi Mukul,
>>
>>On Jan 26, 2010, at 7:23 PM, Mukul Goyal wrote:
>>
>>> Don,
>>>
>>> I think it would be possible to find ways to avoid scaling problems 
>>> with reactive route discovery. I suggested one possibility in the 
>>> following draft:
>>>
>>> http://tools.ietf.org/html/draft-goyal-roll-dv-01
>>>
>>> Lets first agree that we do need source-initiated route discovery.
>>>
>>
>>Again, co-chair hat off. You're right that we first need to 
>>agree that there is a need for a reactive mechanism.
>>
>>Pro-active routing does not imply high delays to discover how 
>>to reach a node after a topology change (node moving, 
>>failures, ...). What we need to explore is how RPL can be 
>>used to achieve the target in term of performance in light of 
>>the numbers spelled out in the requirement documents.
>>Few possibilities are:
>>	o Tune the RPL parameters to join the DAG faster, 
>>and/or increase the degree of meshing (so as to get diverse path)
>>	    to quickly recover connectivity
>>	o Trigger quick DAO refresh after connectivity loss to 
>>refresh the states (need to be discussed once the DAO mechanisms
>>	   will have been stabilized. It is a sort of 
>>"reactive" mechanisms to speed up the whole process.
>>In all cases, this means more control messages (regardless of the
>>protocols) and must be well understood according to the context.
>>
>>Thanks.
>>
>>JP.
>>
>>> Thanks
>>> Mukul
>>>

---

From: JP Vasseur <[email-masked]>
Date: Thu, 28 Jan 2010 19:12:00 +0100

Hi Joseph,

On Jan 28, 2010, at 6:30 PM, Reddy, Joseph wrote:

>
> Hi JP,
>
> I agree that proactive routing does not necessarily mean larger  
> delays in setting up a route.  However, it usually has a larger  
> delay in "detecting" a route failure.
>

Well one can show tons of situations where it is in fact the opposite.  
In these networks you could even repair the route
before you even need it, thus avoiding to find a new path when you  
need it and loose time (=> increased delays).

> In most situations, a link failure is usually detected first on the  
> sender side. So I think having a discovery/recovery mechansim that  
> can be initiated by the source device is necessary to meet the  
> latency requirements for the more demanding applications ( like  
> lighting etc. )
>

This is what we need to show, which should not be too difficult using  
few representative examples.
Note that we *may* need to tune RPL, add some reactiveness if/where  
needed of course.

Cheers.

JP.

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

---

From: Henning Rogge <[email-masked]>
Date: Thu, 28 Jan 2010 19:18:05 +0100

Am Donnerstag 28 Januar 2010 18:30:57 schrieb Reddy, Joseph:
> Hi JP,
> 
> I agree that proactive routing does not necessarily mean larger delays in
>  setting up a route.  However, it usually has a larger delay in "detecting"
>  a route failure.
I think you got it the wrong way.

A reactive protocol does not recognize a route failure (or a bad route) until 
traffic is sent over this route. A proactive protocol can (as the name says) 
detect this on it's own and repair the situation before traffic is lost.

Typically reactive protocolls have a HUGE delay for the first traffic to a 
destination because they have to discover the route first. Proactive protocols 
don't have this problem.

Henning Rogge