Subject: Re: [Roll] Question/clarification about applicability of OF0

From: Ralph Droms <[email-masked]>
Date: Sat, 3 Sep 2011 14:34:49 -0700

On Aug 10, 2011, at 1:03 AM 8/10/11, Pascal Thubert (pthubert) wrote:

> Hi Ralph
> 
>> OF0, when it generates a rank_increase based on hop count, is
> characterized
>> as inappropriate for wireless meshes.  I wonder if "wireless" is
> really the right
>> descriptive term here.  More generally, a hop count metric is
> inappropriate
>> for subnets composed of links in which a route with a higher hop count
> might
>> perform better than a router with a lower hop count.  Such subnets can
> be
>> either wireless or wired; for example, as I understand the technology,
> it's
>> possible for an IEEE1901.2 network to exhibit connectivity and
> transmission
>> quality characteristics for which a route through more higher quality
> hops
>> might be better than a router through fewer lower quality hops.
> 
> [Pascal] You're correct.
> OF0 does not know the type of link it can be applied to so it leaves the
> computation of the step_of_rank to the implementation that knows better.

I'm not sure I made my point clearly.  I think the terms "wireless" and "wired" are inaccurate in describing the two kinds of links; "equal cost" and "variable cost" would be more accurate.  802.11 provides wireless links but, in usual deployments, my understanding is that they are essentially equal cost.  At the same time, wired links - e.g. IEEE1901.2 - can have variable cost.

- Ralph

>> I'm also confused about some of the use cases for RPL.  Is there a use
> case in
>> which RPL would be used in a non-LLN environment in place of other
> routing
>> protocols like RIP, OSPF and ISIS?
> 
> [Pascal] RPL is a DV routing protocol. It has the pros and cons of its
> family. But yes, it could apply in many places. It is a matter of
> network engineering to select the most adapted tool for a given
> situation, knowing that:
> -As opposed to the classical bunch, it does not compute the optimal end
> to end path for all nodes. 
> -RPL does not try to fix any broken situation as soon as it occurs. 
> -RPL requires looking inside the packets for datapath validation, and
> RPL adds a (set of) L3 "VLANs" we call instances
> 
> If you look at it, a spanning tree is not much different, just a lot
> simpler (just a tree, no TTL).
> So in a situation where a (mesh_under) spanning tree is used today a
> (route_over) RPL solution could actually provide a positive replacement.
> Benefits would be:
> - no risk of meltdown (that's TTL for you) thus faster convergence.
> - end to end IP (that's route_over vs. mesh_under)
> - multipath ( that's coming from RPL's DAG)
> - Goal (the root is picked at a sensible place)
> 
> Another example: If you have a number of access points at home, and you
> want to mesh them, then the link quality is asserted by the association
> process so hop count could work. You'll note that with hop count, a cost
> is traditionally associated to link speed and that would apply too since
> WIFI reduces the link speed to maintain the link quality. This is a case
> where RPL could easily replace a proprietary mesh technology, either
> using (hop count, line speed), something a bit fancier, like ETX, or
> something more proprietary if that can provide a market advantage. OF0
> will allow all those to interoperate and you'll get a DAG that reaches
> the goal, if that's possible at all.
> 
> Cheers,
> 
> Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 5 Sep 2011 11:14:14 +0200

Hi Ralph:

I agree with your point. 

We have in one hand the classical links where the cost is usually a
direct and constant relation to the speed. And in the other, links with
properties that vary over time. 
Clearly, most classical wires fall in the first category, and most
wireless fall in the other. Yet they are not an exact match. 

In any case, the distinction between wired and wireless is mostly gone
from the spec; it appears in a snippet that is only an illustration of a
point:
"
   The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not
   be sufficient in every case to strongly distinguish links of
   different types or categories in order to favor, say, powered over
   battery-operated or wired over wireless, within a same DAG.
"
I'll be happy to change that to
"
The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH
may not be sufficient in every case to strongly distinguish links of
different
types or categories in order to favor, say, powered over
battery-operated or high-speed wire
over lower-speed wireless, within a same DAG.
"

What do you think?

Pascal

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]] 
Sent: samedi 3 septembre 2011 23:35
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [Roll] Question/clarification about applicability of OF0

On Aug 10, 2011, at 1:03 AM 8/10/11, Pascal Thubert (pthubert) wrote:

> OF0 does not know the type of link it can be applied to so it leaves 
> the computation of the step_of_rank to the implementation that knows
better.

I'm not sure I made my point clearly.  I think the terms "wireless" and
"wired" are inaccurate in describing the two kinds of links; "equal
cost" and "variable cost" would be more accurate.  802.11 provides
wireless links but, in usual deployments, my understanding is that they
are essentially equal cost.  At the same time, wired links - e.g.
IEEE1901.2 - can have variable cost.

- Ralph

> -As opposed to the classical bunch, it does not compute the optimal 
> end to end path for all nodes.
> Another example: If you have a number of access points at home, and 
> you want to mesh them, then the link quality is asserted by the 
> association process so hop count could work. You'll note that with hop

> count, a cost is traditionally associated to link speed and that would

> apply too since WIFI reduces the link speed to maintain the link 
> quality. This is a case where RPL could easily replace a proprietary 
> mesh technology, either using (hop count, line speed), something a bit

> fancier, like ETX, or something more proprietary if that can provide a

> market advantage. OF0 will allow all those to interoperate and you'll 
> get a DAG that reaches the goal, if that's possible at all.
> 
> Cheers,
> 
> Pascal