Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

From: Kris Pister <[email-masked]>
Date: Mon, 03 Nov 2008 12:42:31 -0800

JP Vasseur wrote:
> Hi Phil,
>
>
> On 10/31/08 5:20 PM, "Philip Levis" <[email-masked]> wrote:
>
>   
>> On Oct 31, 2008, at 4:27 AM, JP Vasseur wrote:
>>
>>     
>>> Agree.
>>>
>>> A good time to ask the question to the WG.
>>>
>>> Do you think that we need to specify node latency as a metric ? Note
>>> that this mean: queueuing delays (per link) and processing time (per
>>> node).
>>>
>>> ps: I¹m personally very skeptical about using such varying
>>> metrics ... W/o high risk of routing oscillations, or we need very
>>> carefully designed threshold-based mechanisms certainly no dynamic
>>> metrics reflecting ³real time² values.
>>>       
>> Node latency -- the time that passes between packet reception and
>> packet transmission -- can be important but not for either queueing
>> delay or processing time.
>>     
>
> That depends ... On the type of nodes, traffic type, ... Etc.
>
> Rather, node latency can be important if
>   
>> there is some kind of underlying scheduling. Or would you consider
>> this queueing delay?
>>     
>
> By "underlying scheduling" are you referring to the OS scheduler or the L2
> scheduling ?
>   
I don't think that the OS scheduler or any other computation-related 
delay is likely to cause much trouble.
Most/all existing motes can turn a packet around in milliseconds.
The L2 access is a much bigger challenge.  Unless you have the luxury of 
a powered routing infrastructure, one way or the other you'll be duty 
cycling your receivers.  This will introduce delays of typically 
hundreds of milliseconds (tens of ms up to seconds).
> Note that it can differ greatly depending on
>   
>> which node is the next hop.
>>     
>
> But before we start to look at all components, I think that *the* question
> is whether we want the routing protocol to take into account such highly
> variable node and link metrics ?
>   
I would love to see a routing protocol that can satisfy our requirements 
without taking into account the variable node and link metrics.  If we 
weren't trying to be efficient, then there would be no problem.  But the 
first L implies that we must be efficient, and the second L makes it 
very challenging to do that without paying close attention to what's 
going on at the link level.

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

---

From: "Mischa Dohler" <[email-masked]>
Date: Tue, 4 Nov 2008 11:21:12 +0100

Concerning the delay and partially concerning the node degree, just a few
minor comments ...

- I agree that propagation delay is negligible (and has always been in short
range systems; I am not sure why this keeps popping up but my suspicion is
that this is a legacy of Kleinrock's/Tobagi's papers).

- Also, the processing delay per node will (deterministically) be in the
order of a packet length because we are not using transparent forwarding
techniques but rather entirely decode and re-encode the packet. I agree with
Kris that this will be negligible given other delays.

- As for the queuing delay, assume your node runs on an AA battery, then you
can calculate that you need a duty cycle of around 1% to make it run for
about a decade (taking into account typical battery current leakage models,
a typical PHY and a typical MAC). At MAC level this translates to (fairly
deterministic) sleep-delays at each node. I hence totally agree with Kris
that either this sleep delay is predominant w.r.t. the delay in the
scheduling queue or, if you have a powered infrastructure, you can neglect
these delays entirely. 

- As for the node degree, the duty cycling of the nodes does also allow you
to influence the node degree, which should generally be kept fairly low to
minimize contention (but sufficiently high to guarantee connectivity). Low
node degrees, coupled with low/medium offered traffic which we typically
have in WSNs, guarantees that offered traffic is roughly equivalent to the
throughput traffic at delays in the order of packet durations. 

In summary, I think there won't be so much dynamics associated to the delay
in a WSN as compared to ad hoc networks - so no problem, JP. At the same
time, the path delay (as mentioned by Jonathan), i.e. the aggregation of
delay at each hop from source to sink, can not be neglected and should
explicitly be considered, particularly in the case of duty-cycled MACs for
delay-constrained applications such as industrial plant applications. It
will clearly impact routing solutions since a route with fewer hops might be
delay-optimal, even if not energy-optimal. 

Best regards,
Mischa.

_____________________________

Dr Mischa Dohler
Senior Researcher
CTTC, Barcelona

Tel: +34 93 645 2900
Fax: +34 93 645 2901
Mob: +34 6 7909 4007

www.cttc.es/home/mdohler
_____________________________

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris
Pister
Sent: Monday, November 03, 2008 9:43 PM
To: JP Vasseur
Cc: ROLL WG
Subject: Re: [Roll] ROLL Routing Metrics - WF feed-back needed

JP Vasseur wrote: 
Hi Phil,

Agree.

      

  

I don't think that the OS scheduler or any other computation-related delay
is likely to cause much trouble.
Most/all existing motes can turn a packet around in milliseconds.
The L2 access is a much bigger challenge.  Unless you have the luxury of a
powered routing infrastructure, one way or the other you'll be duty cycling
your receivers.  This will introduce delays of typically hundreds of
milliseconds (tens of ms up to seconds).

  
I would love to see a routing protocol that can satisfy our requirements
without taking into account the variable node and link metrics.  If we
weren't trying to be efficient, then there would be no problem.  But the
first L implies that we must be efficient, and the second L makes it very
challenging to do that without paying close attention to what's going on at
the link level.

ksjp

Thanks.

JP. 

Phil

---

From: JP Vasseur <[email-masked]>
Date: Tue, 04 Nov 2008 12:50:31 +0100

Hi Kris,

On 11/3/08 9:42 PM, "Kris Pister" <[email-masked]> wrote:

> 
> 
> JP Vasseur wrote:
>>  
>> Hi Phil,
>> 
>> 
>> On 10/31/08 5:20 PM, "Philip Levis" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>   
>>  
>>>  
> I don't think that the OS scheduler or any other computation-related delay is
> likely to cause much trouble.
> JP> Makes total sense to me but I wanted to clarify since there are very few
> cases where indeed the node workload may be relevant and may delay packet
> forwarding especially with non preempting OS. My personal take on this is that
> the node workload is not significant enough in most of the cases.
>>  
>> 
> without taking into account the variable node and link metrics.  If we weren't
> trying to be efficient, then there would be no problem.  But the first L
> implies that we must be efficient, and the second L makes it very challenging
> to do that without paying close attention to what's going on at the link
> level.
> 
> JP> This is what I wanted to hear explicitly. Can you look at the proposed
> metrics and spell out the link and node metrics that you think are must-have.
> 
> Thanks.
> 
> JP.
> 
> ksjp
>>  
>> 
>> Thanks.
>> 
>> JP. 
>> 
>>   
>>  
>>>  
>>> Phil
>>>     
>>>  
>>  
>>