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

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 13 May 2009 14:57:13 +0200

JP Vasseur a écrit :
> Hi,
> 
> 
> On 11/10/08 11:52 PM, "Kris Pister" <[email-masked]> wrote:
> 
>> Phil - I agree that the optimal routes are going to be a function of the
>> state of all of the nodes along each route, not just one node
>> advertising that it's fat and happy.
> 
> Right. Bear in mind that we are discussing node metric. Path characteristics
> are locally derived by the computing node !

DEpends whether we consider a path to be the set of links or the set of 
the nodes.

I personally prefer it to be the set of links.  And associate a metric 
to a link, not to a node.

Alex

> 
>> I don't think that I agree that we're assuming that a node must
>> communicate a lot of factors to other nodes.  I can imagine something
>> like AODV, but where each node adds its own hop cost.  Depending on
>> shared network parameters, each node might add e.g. 1/(remaining
>> lifetime) to the total route cost, or it might add it's link-latency to
>> the route cost.  I'm not advocating something AODV-like, just pointing
>> out that we don't necessarily need to be propagating a lot of state
>> information around the network, and potentially complicated (and
>> platform dependent) local computations can still be done without the
>> global algorithm needing to know the details.
> 
> Absolutely.
> 
> JP.
> 
>> ksjp
>>
>> Philip Levis wrote:
>>> On Nov 10, 2008, at 7:55 AM, Anders Brandt wrote:
>>>
>>>> Jerry touches a point I forgot to mention in relation to Kris'
>>>> previous postings.
>>>>
>>>> I fully support the idea of preferred routers running on battery.
>>>> We definitely also see this application in the home control domain.
>>>>
>>>>> ...let's say I have a battery powered repeater installed in a
>>>> sparse portion of the mesh.  This device has no other meaning in
>>>>> life but to route messages. Rerouting around this device saves the
>>>> energy on a device that has no reason to save energy.
>>>>>  Also, remember this repeater was strategically placed to 'fill-in'
>>>> the mesh.
>>>>
>>>> In order to attract interest from the routing protocol, such a node
>>>> should be able to signal "mains powered" or even better:
>>>> "I have plenty of battery".
>>>> Obviously, it should lower that indication to normal
>>>> "battery-powered" if running close to low; ending with "battery low".
>>>> br. Anders
>>>>
>>>>
>>>>
>>> I'm confused by this line of logic. Whether a node advertises itself
>>> as having lots of energy is less important than the available energy
>>> along a route. I.e., if the next hop, node A, has lots of energy but
>>> its next hop, node B, is very limited, the fact that A has lots of
>>> energy is not particularly useful.
>>>
>>> So far, this discussion has assumed that a node must communicate a lot
>>> of factors to other nodes, so they can apply their own algorithms to
>>> decide which next hop to take. The issue here is that it assumes the
>>> optimization criteria are the same; even though the router-to-be wants
>>> to save energy, the sender wants to optimize latency and so ignores
>>> energy constraints. Another approach is that each node applies its own
>>> algorithm to determine its willingness/cost, which other nodes then
>>> take into account. That is, nodes advertise how good a router they
>>> think they are, and senders take this into consideration. Otherwise,
>>> especially in a distributed and dynamic system, senders can be making
>>> decisions based on out-of-date information which is hard to detect
>>> inconsistencies on without expensive periodic state exchanges.
>>>
>>> E.g., one simple way to articulate energy, rather than "I have X" is
>>> "How expensive I consider sending a packet." This takes into
>>> consideration a lot more useful information, and is much more flexible
>>> to compute and consider.
>>>
>>> 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: JP Vasseur <[email-masked]>
Date: Thu, 14 May 2009 11:34:48 +0200

On May 13, 2009, at 2:57 PM, Alexandru Petrescu wrote:

> DEpends whether we consider a path to be the set of links or the set  
> of the nodes.
>
> I personally prefer it to be the set of links.  And associate a  
> metric to a link, not to a node.

A path is *always* is a set of links and nodes, which I agree does not  
require to set metric for nodes.
We could have metrics and constraints for the links and node  
constraints for the node. This is going
to be clarified in the routing protocol ID, to be discussed in the WG  
of course.

JP.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 May 2009 11:57:20 +0200

JP Vasseur a écrit :
>>> Hi, On 11/10/08 11:52 PM, "Kris Pister" 
>>> <[email-masked]> wrote:
>>>> Phil - I agree that the optimal routes are going to be a 
>>>> function of the state of all of the nodes along each route, not
>>>>  just one node advertising that it's fat and happy.
>>> Right. Bear in mind that we are discussing node metric. Path 
>>> characteristics are locally derived by the computing node !
>> 
>> DEpends whether we consider a path to be the set of links or the 
>> set of the nodes.
>> 
> A path is *always* is a set of links and nodes, which I agree does 
> not require to set metric for nodes. We could have metrics and 
> constraints for the links and node constraints for the node.

Just to say I agree...

> This is going to be clarified in the routing protocol ID, to be
> discussed in the WG of course.

Ok, looking forward, thanks,

Alex

>>>>  communicate a lot of factors to other nodes.  I can imagine 
>>>> something like AODV, but where each node adds its own hop cost.
>>>>  Depending on shared network parameters, each node might add 
>>>> e.g. 1/(remaining lifetime) to the total route cost, or it 
>>>> might add it's link-latency to the route cost.  I'm not 
>>>> advocating something AODV-like, just pointing out that we don't
>>>>  necessarily need to be propagating a lot of state information 
>>>> around the network, and potentially complicated (and platform 
>>>> dependent) local computations can still be done without the 
>>> Absolutely. JP.
>>>>>> Jerry touches a point I forgot to mention in relation to 
>>>>>> Kris' previous postings.
>>>>>> 
>>>>>> I fully support the idea of preferred routers running on 
>>>>>> battery. We definitely also see this application in the 
>>>>>> home control domain.
>>>>>> 
>>>>>> In order to attract interest from the routing protocol, 
>>>>>> such a node should be able to signal "mains powered" or 
>>>>>> even better: "I have plenty of battery". Obviously, it 
>>>>>> should lower that indication to normal "battery-powered" if
>>>>>>  running close to low; ending with "battery low". br.
>>>>>> Anders
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> I'm confused by this line of logic. Whether a node advertises
>>>>>  itself as having lots of energy is less important than the 
>>>>> available energy along a route. I.e., if the next hop, node 
>>>>> A, has lots of energy but its next hop, node B, is very 
>>>>> limited, the fact that A has lots of energy is not 
>>>>> particularly useful.
>>>>> 
>>>>> So far, this discussion has assumed that a node must 
>>>>> communicate a lot of factors to other nodes, so they can 
>>>>> apply their own algorithms to decide which next hop to take. 
>>>>> The issue here is that it assumes the optimization criteria 
>>>>> are the same; even though the router-to-be wants to save 
>>>>> energy, the sender wants to optimize latency and so ignores 
>>>>> energy constraints. Another approach is that each node 
>>>>> applies its own algorithm to determine its willingness/cost, 
>>>>> which other nodes then take into account. That is, nodes 
>>>>> advertise how good a router they think they are, and senders 
>>>>> take this into consideration. Otherwise, especially in a 
>>>>> distributed and dynamic system, senders can be making 
>>>>> decisions based on out-of-date information which is hard to 
>>>>> detect inconsistencies on without expensive periodic state 
>>>>> exchanges.
>>>>> 
>>>>> E.g., one simple way to articulate energy, rather than "I 
>>>>> have X" is "How expensive I consider sending a packet." This 
>>>>> takes into consideration a lot more useful information, and 
>>>>> is much more flexible to compute and consider.
>>>>> 
>>>>> 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
>> 
>> 
> 
>