Subject: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

From: [email-masked]
Date: Wed, 08 Dec 2010 03:00:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF.

	Title           : RPL Objective Function 0
	Author(s)       : P. Thubert
	Filename        : draft-ietf-roll-of0-04.txt
	Pages           : 9
	Date            : 2010-12-08

The Routing Protocol for Low Power and Lossy Networks (RPL) defines a
generic Distance Vector protocol for Low Power and Lossy Networks
(LLNs).  RPL is instantiated to honor a particular routing objective/
constraint by the adding a specific Objective Function (OF) that is
designed to solve that problem.  This specification defines a basic
OF, OF0, that uses only the abstract properties exposed in RPL
messages to maximize connectivity.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-04.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Philip Levis <[email-masked]>
Date: Thu, 9 Dec 2010 09:57:06 -0800

> messages to maximize connectivity.

Pascal,

Is this intended to be the version that responds to all of the comments given in last call?

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Dec 2010 10:40:43 +0100

Hi Phil:

This answers all the comments I've received so far. 
I have not seen that the last call was complete but I thought I owed the
group this refresher.

Pascal
http://www.xtranormal.com/watch/7011357/

> -----Original Message-----
> From: Philip Levis [mailto:[email-masked]]
> Sent: Thursday, December 09, 2010 6:57 PM
> To: Pascal Thubert (pthubert)
> Cc: ROLL WG
> Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt
> 
> Is this intended to be the version that responds to all of the
comments given
> in last call?

---

From: Philip Levis <[email-masked]>
Date: Fri, 10 Dec 2010 11:49:50 -0800

> I have not seen that the last call was complete but I thought I  

Can you describe how it addresses my comments? I don't feel it does,  
but I may just be missing it.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Dec 2010 09:18:47 +0100

Hi Phil:

Apparently I missed a mail. OF 04 fails to address your concerns. So I
digged into the WG list and found this:

"
My major concern with OF0 is actually quite different: it does not say
how to compute Rank from metrics. Back in the discussions on MRHOF, this
emerged as a requirement for an OF, when we separated OFs from metrics.
Right now, it seems like I could have an OF0 that computes Rank from
latency, or throughput. Since the computation of Rank is very poorly
defined, it seems very easy to have two incompatible OF0 implementations
that work at cross purposes.

For OF0 to be ready to be an RFC, it must actually provide some details
on how metrics are converted to Rank. Take a look at the April
discussion entitled "Decoupling Metrics and OF."
"

OF0 does not use say how to metrics. It is a weighted hop count for use
in wire and wire emulation. I agree that the weight could be static or
dynamic, but the design point is specifically not to discuss the
computation of dynamic weights in OF0. This would be opening the Pandora
box of the general RPL metrics and OF discussion, which is addressed
elsewhere and in lot more text than needed here. So if we take the
weight as a given, hopefully stable enough scalar, then the rank
computation is the most classical addition of weighted hops.

Could you please be more specific in what you'd add to the spec?

Pascal

> Sent: Friday, December 10, 2010 8:50 PM
> > I have not seen that the last call was complete but I thought I owed
> > the group this refresher.
> 
but I
> may just be missing it.

---

From: Philip Levis <[email-masked]>
Date: Tue, 14 Dec 2010 10:34:12 -0800

> computation is the most classical addition of weighted hops.

But the consensus, when discussing MRHOF, is that an objective function specification needs to say how to handle and use metrics. It seems strange that OF0 doesn't. Or does OF0 have a special status, that it does not have to follow the requirements laid out for objective function specifications?

Otherwise you can have independent implementations which are incompatible and cause problems: this was due to JP's insistence that objective functions remain metric-independent. What worries me about this is that it seems to just blindly repeat mistakes that LLN protocols have learned from. E.g., modern OLSR deployments do not adhere to the OLSR specification because it requires hopcount and hopcount does not work very well. You're right, there's lots of experience using hopcount as a metric. In the context of LLNs, however, that experience has been negative.

> Could you please be more specific in what you'd add to the spec?

I would add a specification of how OF0 translates metrics into Rank. E.g., an ETX between 1 and 3 adds 1 to Rank, etc.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 15 Dec 2010 12:06:00 +0100

Hi Phil:

> learned from. E.g., modern OLSR deployments do not adhere to the OLSR
> specification because it requires hopcount and hopcount does not work
very
> well. You're right, there's lots of experience using hopcount as a
metric. In
> the context of LLNs, however, that experience has been negative.

We're in a loop here. This need that you describe mostly comes from
propagation issues encountered in wireless networks.
The whole point is that not all LLNs are wireless. Administrative cost
is both usual and proven on wires.

Also there are wireless emulations around that provide an acceptable
service and heavily deployed service, both P2P like military and
satellite radios and transit, the most common being WIFI. 
This is clearly not your world, but the fact is that we have had happy
customers  for over 10 years, using Spanning Tree or similar over
wireless bridges.

I'd assert that RPL provides a lot more than STP, if only because:
- we have the IPv6 hop limit and the RPL reactive loop detection thus no
risk of meltdown
- we build DAGs as opposed to trees

If we can't converge on that, let's keep the discussion at wired links
for a minute. In that case, RPL can often be used the way any other IGP
is used today, can't it?
Then again, we can derive from RPL's properties that it can actually be
preferable over existing protocols at least for certain applications,
because it can be both simpler and faster to set up.
Such applications include:

- corporate VPN (with branch and SOHO, typical recursive )
- ad hoc networks (quickly deployable ad hoc base camps)
- dynamic overlays (meshes of tunnels serving small groups with short
term purposes)

> I would add a specification of how OF0 translates metrics into Rank.
E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.

For OF0, the expected metric is an administrative cost that is trivially
added up along a path; the most usual thing.
OF 0 was designed to be that simple.  This said, I can see 2 ways for
moving forward with your suggestion:

1) We describe that the metric is a static (admin) cost range 1..16 and
that it is placed in the most significant octet of the rank.

2) We decide to add support for a dynamic metric. In that case, we enter
the discussion on stability, statistical dampening, and hysteresis.

And obviously option 3 being both.

I can easily accommodate 1) and republish. Text on 2) would have to be
very vague, like a set of recommendation.  

I do not mind either way, both are probably useful. What does the group
think?

On the side, if you dig patent 7,567,577 at USPTO, you'll find that I'd
rather expose the statistical aspect of  a metric than resort to
hysteresis.
For all I know, this is also something that was successfully tried on
OLSR, but that is not available in the RPL metrics draft.

:  )
Pascal

> Sent: Tuesday, December 14, 2010 7:34 PM
> > how to compute Rank from metrics. Back in the discussions on MRHOF,
> > this emerged as a requirement for an OF, when we separated OFs from
> metrics.
> > defined, it seems very easy to have two incompatible OF0
> > implementations that work at cross purposes.
> >
> > For OF0 to be ready to be an RFC, it must actually provide some
> > details on how metrics are converted to Rank. Take a look at the
April
> > OF0 does not use say how to metrics. It is a weighted hop count for
> > use in wire and wire emulation. I agree that the weight could be
> > static or dynamic, but the design point is specifically not to
discuss
> > the computation of dynamic weights in OF0. This would be opening the
> > Pandora box of the general RPL metrics and OF discussion, which is
> > addressed elsewhere and in lot more text than needed here. So if we
> > take the weight as a given, hopefully stable enough scalar, then the
> > rank computation is the most classical addition of weighted hops.
> 
> But the consensus, when discussing MRHOF, is that an objective
function
> specification needs to say how to handle and use metrics. It seems
strange
> that OF0 doesn't. Or does OF0 have a special status, that it does not
have to
> follow the requirements laid out for objective function
specifications?
> 
> Otherwise you can have independent implementations which are
> incompatible and cause problems: this was due to JP's insistence that
> objective functions remain metric-independent. What worries me about
this
> is that it seems to just blindly repeat mistakes that LLN protocols
have
> learned from. E.g., modern OLSR deployments do not adhere to the OLSR
> specification because it requires hopcount and hopcount does not work
very
> well. You're right, there's lots of experience using hopcount as a
metric. In
> the context of LLNs, however, that experience has been negative.
> 
> I would add a specification of how OF0 translates metrics into Rank.
E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.
> 
> Phil

---

From: Don Sturek <[email-masked]>
Date: Wed, 15 Dec 2010 08:53:22 -0800 (PST)

I have never quite understood the use for RPL in wired networks.  All of the PLC 
solutions I have looked at would not benefit at all by RPL.  The main use case 
is wireless where asymmetric links are a major problem.  It is difficult to 
understand the logic below in light of this inconsistency.

Don

________________________________
From: Pascal Thubert (pthubert) <[email-masked]>
To: Philip Levis <[email-masked]>
Cc: ROLL WG <[email-masked]>
Sent: Wed, December 15, 2010 3:06:00 AM
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an
> ETX between 1 and 3 adds 1 to Rank, etc.
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Dec 2010 15:53:21 +0100

Don:

I listed a number of examples and none of them is PLC actually. 

RPL is a routing protocol. There is no point in preventing its usage on
wired lines.

Pascal

From: Don Sturek [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 5:53 PM
To: Pascal Thubert (pthubert); Philip Levis
Cc: ROLL WG
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

I have never quite understood the use for RPL in wired networks.  All of
the PLC solutions I have looked at would not benefit at all by RPL.  The
main use case is wireless where asymmetric links are a major problem.
It is difficult to understand the logic below in light of this
inconsistency.

Don

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 16 Dec 2010 06:56:37 -0800

Hi Pascal,

Correct, there  is no point in preventing the use of RPL in wired networks.

That said, when the default OF uses a metric that is known not to work in
wireless networks (where I will claim RPL is more likely to be deployed)
then citing the successful deployment of the same OF in wired networks does
not help the cause.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 6:53 AM
To: Don Sturek; Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don:

Pascal

I have never quite understood the use for RPL in wired networks.  All of the
PLC solutions I have looked at would not benefit at all by RPL.  The main
use case is wireless where asymmetric links are a major problem.  It is
difficult to understand the logic below in light of this inconsistency.

Don

  _____  

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Dec 2010 16:05:15 +0100

Don:

I think that the disconnect is your assumption that OF 0 is the default.
There is no default OF in RPL. That was discussed at length and that's
why OF 0 was split from RPL at some point. Please let us know if there's
any claim (left?) that OF0 is the default OF for RPL...

I'll abstain to make any prediction as of where RPL will be most used
(or useful). We got rid of having to make that assumption by allowing OF
to extend the base protocol in the first place. This was actually a key
design point. I'll just try my best to make sure that it can be used
where it's needed.

Pascal

From: Don Sturek [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 3:57 PM
To: Pascal Thubert (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Pascal,

Correct, there  is no point in preventing the use of RPL in wired
networks.

That said, when the default OF uses a metric that is known not to work
in wireless networks (where I will claim RPL is more likely to be
deployed) then citing the successful deployment of the same OF in wired
networks does not help the cause.

Don

Don:

Pascal

Don

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 16 Dec 2010 07:40:35 -0800

I think we are missing something other than OF0 to use.  Maybe we just need
a draft on this.

Let me see if we can't generate something in our ZigBee IP testing.  For
sure we won't be using OF0 and we need to specify something anyway.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 7:05 AM
To: [email-masked]; Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don:

I think that the disconnect is your assumption that OF 0 is the default.
There is no default OF in RPL. That was discussed at length and that's why
OF 0 was split from RPL at some point. Please let us know if there's any
claim (left?) that OF0 is the default OF for RPL.

I'll abstain to make any prediction as of where RPL will be most used (or
useful). We got rid of having to make that assumption by allowing OF to
extend the base protocol in the first place. This was actually a key design
point. I'll just try my best to make sure that it can be used where it's
needed.

Pascal

Hi Pascal,

Don

Don:

Pascal

Don

  _____  

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 16 Dec 2010 16:50:36 +0100

Did you consider draft-ietf-roll-minrank-hysteresis-of ?

Pascal

From: Don Sturek [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 4:41 PM
To: Pascal Thubert (pthubert); 'Philip Levis'
Cc: 'ROLL WG'
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

I think we are missing something other than OF0 to use.  Maybe we just
need a draft on this.

Don

Don:

Pascal

Hi Pascal,

Don

Don:

Pascal

Don

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 16 Dec 2010 08:00:40 -0800

I think we are looking at how to handle asymmetric links.  We had a way to
do this in previous deployments so will likely contribute a new OF that
covers that function.

Don

From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 7:51 AM
To: [email-masked]; Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Pascal

Don

Don:

Pascal

Hi Pascal,

Don

Don:

Pascal

Don

  _____  

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 16 Dec 2010 18:46:56 +0200

Hi all,

For the record - let me shed some light on the PLC case from our experience.

PLC links can definitely be asymmetric. This is due to the fact that the
main factors affecting reception are noise at the Rx side (different at both
ends), and load at Tx side (again different at both ends).

So from both ends, there can easily be asymmetry.

Without getting into the details of how this is done, I agree that RPL must
provide mechanism(s) enabling to cope with asymmetric links as a non-rare
case (isn’t it one of the requirements of RPL?)

Now getting into the details – can the WG at least provide some feedback on
whether such mechanisms are supported by RPL in all major modes and
topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)?

Best regards,

Yoav

*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Don
Sturek
*Sent:* Thursday, December 16, 2010 6:01 PM
*To:* 'Pascal Thubert (pthubert)'; 'Philip Levis'
*Cc:* 'ROLL WG'
*Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don

*From:* Pascal Thubert (pthubert) [mailto:[email-masked]]
*Sent:* Thursday, December 16, 2010 7:51 AM
*To:* [email-masked]; Philip Levis
*Cc:* ROLL WG
*Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Pascal

*From:* Don Sturek [mailto:[email-masked]]
*Sent:* Thursday, December 16, 2010 4:41 PM
*To:* Pascal Thubert (pthubert); 'Philip Levis'
*Cc:* 'ROLL WG'
*Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Let me see if we can’t generate something in our ZigBee IP testing.  For
sure we won’t be using OF0 and we need to specify something anyway.

Don

*From:* Pascal Thubert (pthubert) [mailto:[email-masked]]
*Sent:* Thursday, December 16, 2010 7:05 AM
*To:* [email-masked]; Philip Levis
*Cc:* ROLL WG
*Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don:

I think that the disconnect is your assumption that OF 0 is the default.
There is no default OF in RPL. That was discussed at length and that’s why
OF 0 was split from RPL at some point. Please let us know if there’s any
claim (left?) that OF0 is the default OF for RPL…

I’ll abstain to make any prediction as of where RPL will be most used (or
useful). We got rid of having to make that assumption by allowing OF to
extend the base protocol in the first place. This was actually a key design
point. I’ll just try my best to make sure that it can be used where it’s
needed.

Pascal

*From:* Don Sturek [mailto:[email-masked]]
*Sent:* Thursday, December 16, 2010 3:57 PM
*To:* Pascal Thubert (pthubert); 'Philip Levis'
*Cc:* 'ROLL WG'
*Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Pascal,

Don

*From:* Pascal Thubert (pthubert) [mailto:[email-masked]]
*Sent:* Thursday, December 16, 2010 6:53 AM
*To:* Don Sturek; Philip Levis
*Cc:* ROLL WG
*Subject:* RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don:

Pascal

*From:* Don Sturek [mailto:[email-masked]]
*Sent:* Wednesday, December 15, 2010 5:53 PM
*To:* Pascal Thubert (pthubert); Philip Levis
*Cc:* ROLL WG
*Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Don

 ------------------------------

*From:* Pascal Thubert (pthubert) <[email-masked]>
*To:* Philip Levis <[email-masked]>
*Cc:* ROLL WG <[email-masked]>
*Sent:* Wed, December 15, 2010 3:06:00 AM
*Subject:* Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Dec 2010 10:48:17 +0100

Hi Yoav.

Most certainly. This was actually debated at length on the very ML.

For what I remember, there were 2 options:

-          Make RPL more complex to handle a different set of parents
for up and down. This includes metrics descriptor that qualify a metric
as UP or DOWN

-          Use 2 instances, one for traffic up (no need for DAO) and one
for traffic down.

My intuition is that the latter is the simpler. If by definition an OF
is an UP OF, then it will process and relay metrics that cover the UP
diecrtion.

What do you think?

Pascal

From: Yoav Ben-Yehezkel [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 5:47 PM
To: [email-masked]; Pascal Thubert (pthubert); Philip Levis
Cc: ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi all,

For the record - let me shed some light on the PLC case from our
experience.

PLC links can definitely be asymmetric. This is due to the fact that the
main factors affecting reception are noise at the Rx side (different at
both ends), and load at Tx side (again different at both ends). 

Without getting into the details of how this is done, I agree that RPL
must provide mechanism(s) enabling to cope with asymmetric links as a
non-rare case (isn't it one of the requirements of RPL?)

Now getting into the details - can the WG at least provide some feedback
on whether such mechanisms are supported by RPL in all major modes and
topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)?

Best regards,

Yoav

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Sturek
Sent: Thursday, December 16, 2010 6:01 PM
To: 'Pascal Thubert (pthubert)'; 'Philip Levis'
Cc: 'ROLL WG'
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

I think we are looking at how to handle asymmetric links.  We had a way
to do this in previous deployments so will likely contribute a new OF
that covers that function.

Don

Pascal

Don

Don:

Pascal

Hi Pascal,

Don

Don:

Pascal

Don

very
metric. In

E.g., an

:  )
Pascal

April
discuss
function
strange
have to
specifications?
this
have
very
metric. In
E.g., an

---

From: Philip Levis <[email-masked]>
Date: Fri, 17 Dec 2010 13:30:53 -0800

> is both usual and proven on wires.

I'm confused -- ROLL is chartered to work on low-power and lossy networks. What you're describing seems to be outside that scope?

> satellite radios and transit, the most common being WIFI. 

Wait -- are you asserting that WiFi has reliability and behavior equivalent to a wired network?

> customers  for over 10 years, using Spanning Tree or similar over

Can you point me at some concrete examples? I'm not sure I understand the logic: because hopcount has been OK for wireless bridges, we can ignore the fact that it's been a problem in LLNs? I thought RPL is for LLNs.

> I do not mind either way, both are probably useful. What does the group

I feel like you're ignoring the original comment. Let's try to separate my two concerns. The first is that the OF0 draft does not follow the guidelines the WG agreed on for objective functions: this is a process issue. The second is what I believe is a technical issue, that OF0 seems like it does not meet a standard of technical excellence.

For the first issue -- when MRHOF came up for discussion, we (as a WG) agreed that objective functions should be metric-independent. To ensure interoperability of different OF implementations, this means an OF needs to specify with reasonable (but not complete) detail how it processes a metric container. It sounds like your answer is that OF0 ignores a metric container. This seems like a completely reasonable specification in terms of process, given the expectations laid out for OFs. 

The second issue I guess we can disagree on. Maybe it would be helpful if you could sketch a concrete RPL scenario -- maybe from one of the application drafts -- where OF0 would be a good solution? That might help ground this discussion.

Phil

---

From: Philip Levis <[email-masked]>
Date: Fri, 17 Dec 2010 13:32:13 -0800

On Dec 16, 2010, at 6:53 AM, Pascal Thubert (pthubert) wrote:

> RPL is a routing protocol. There is no point in preventing its usage on wired lines.
> 

https://datatracker.ietf.org/wg/roll/charter/:

The Working Group is focused on routing issues for LLN.

Can you give me an example of a wired network that's an LLN where OF0 is useful?

Phil

---

From: Chauvenet Cédric <[email-masked]>
Date: Fri, 17 Dec 2010 10:09:50 +0100

Hi all, 

Our PLC experience also highlight the nature of asymmetric links in PLC networks.

PLC in general cannot be considered as a broadcast media like ethernet.

RPL enable to face routing challenges for LLNs, which are not a wireless monoploly, and asymmetric links are definitely a part of it.

I remember a previous mail thread about this topic on this ML, but can't find back if there were a conclusion on it.

Best,
Cédric

Le 16 déc. 2010 à 17:46, Yoav Ben-Yehezkel a écrit :

> PLC links can definitely be asymmetric. This is due to the fact that the main factors affecting reception are noise at the Rx side (different at both ends), and load at Tx side (again different at both ends).
> Without getting into the details of how this is done, I agree that RPL must provide mechanism(s) enabling to cope with asymmetric links as a non-rare case (isn’t it one of the requirements of RPL?)
>  
> Now getting into the details – can the WG at least provide some feedback on whether such mechanisms are supported by RPL in all major modes and topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)?
>  
> Best regards,
> Yoav
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Don Sturek
> I think we are looking at how to handle asymmetric links.  We had a way to do this in previous deployments so will likely contribute a new OF that covers that function.
>  
> Don
>  
>  
> I think we are missing something other than OF0 to use.  Maybe we just need a draft on this.
>  
> Let me see if we can’t generate something in our ZigBee IP testing.  For sure we won’t be using OF0 and we need to specify something anyway.
> 
> Don
>  
>  
> I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and that’s why OF 0 was split from RPL at some point. Please let us know if there’s any claim (left?) that OF0 is the default OF for RPL…
>  
> I’ll abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. I’ll just try my best to make sure that it can be used where it’s needed.
>  
> Pascal
> That said, when the default OF uses a metric that is known not to work in wireless networks (where I will claim RPL is more likely to be deployed) then citing the successful deployment of the same OF in wired networks does not help the cause.
> 
> Don
>  
>  
> I have never quite understood the use for RPL in wired networks.  All of the PLC solutions I have looked at would not benefit at all by RPL.  The main use case is wireless where asymmetric links are a major problem.  It is difficult to understand the logic below in light of this inconsistency.
> 
> Don
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 18 Dec 2010 13:38:51 +0100

Again you've got your logic reversed. RPL was designed for LLNs, does
not mean that it has to be limited to anything as long as it works fine
there too. 

Second you'll find more and more low power  / constrained devices in
both wired and wireless space, because as a trend we are controlling
more and wasting less.

Third, RPL by construction is a good routing protocol for certain
topologies that are inherently based on hub and spoke. I listed a number
in this thread already. Think dynamic overlays like VPNs  for one.

Finally, OF0 may apply to asymmetric links if people are willing to run
2 DAGs, one for the traffic up and one for the traffic down. Mixing
problems is a source of confusion.
 
Pascal

> Sent: Friday, December 17, 2010 10:32 PM
> Cc: Don Sturek; ROLL WG
> > RPL is a routing protocol. There is no point in preventing its usage
on wired
> lines.
> Can you give me an example of a wired network that's an LLN where OF0
is
> useful?

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Sat, 18 Dec 2010 07:04:31 -0600

All, if you think of a potential new WG item, let' discus it during our interim WG meeting on Monday. JP 
Sent from Smart Phone 

JP Vasseur - Cisco

From: Chauvenet Cédric [mailto:[email-masked]] 
Sent: Friday, December 17, 2010 03:09 AM
To: Yoav Ben-Yehezkel <[email-masked]> 
Cc: ROLL WG <[email-masked]> 
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt 

Hi all, 

Best,
Cédric

	
	Hi all,

	Without getting into the details of how this is done, I agree that RPL must provide mechanism(s) enabling to cope with asymmetric links as a non-rare case (isnt it one of the requirements of RPL?)

	Now getting into the details  can the WG at least provide some feedback on whether such mechanisms are supported by RPL in all major modes and topologies (i.e. storing/non storing modes and P2MP/MP2P topologies)?

	Best regards,
	Yoav

	Don

	Pascal

	Let me see if we cant generate something in our ZigBee IP testing.  For sure we wont be using OF0 and we need to specify something anyway.
	
	Don

	Don:

	I think that the disconnect is your assumption that OF 0 is the default. There is no default OF in RPL. That was discussed at length and thats why OF 0 was split from RPL at some point. Please let us know if theres any claim (left?) that OF0 is the default OF for RPL

	Ill abstain to make any prediction as of where RPL will be most used (or useful). We got rid of having to make that assumption by allowing OF to extend the base protocol in the first place. This was actually a key design point. Ill just try my best to make sure that it can be used where its needed.

	Pascal

	Hi Pascal,

	
	Don

	Don:

	Pascal

	
	Don

	

	very
	metric. In

	

	
	E.g., an

	

	

	:  )
	Pascal

	April
	discuss
	function
	strange
	have to
	specifications?
	this
	have
	very
	metric. In
	E.g., an

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 18 Dec 2010 14:24:54 +0100

> Wait -- are you asserting that WiFi has reliability and behavior
equivalent to a
> wired network?

[Pascal] 
802.11 infrastructure mode is inherently an emulation of Ethernet. 
The service must be good enough considering its degree of adoption.
Please refrain for rewording my sentences. 

> Can you point me at some concrete examples? I'm not sure I understand
the
> logic: because hopcount has been OK for wireless bridges, we can
ignore the
> fact that it's been a problem in LLNs? I thought RPL is for LLNs.

[Pascal] 
RPL is more economical and will converge faster than spanning tree,
because in the first it does not have to prevent meltdown at all cost.
At some point, route over may supplant mesh under in a number of
applications, including the most classical switching world.
Now that we have RPL on the works, the main issue is not the lack of
routing protocol but the lack of a vlan-equivalent tagging in the IPv6
header.

> > For OF0, the expected metric is an administrative cost that is
> > trivially added up along a path; the most usual thing.
> > 1) We describe that the metric is a static (admin) cost range 1..16
> > and that it is placed in the most significant octet of the rank.
> >
> > 2) We decide to add support for a dynamic metric. In that case, we
> > enter the discussion on stability, statistical dampening, and
hysteresis.
> > I do not mind either way, both are probably useful. What does the
> > group think?
> 
> I feel like you're ignoring the original comment. Let's try to
separate my two
> concerns. The first is that the OF0 draft does not follow the
guidelines the
> WG agreed on for objective functions: this is a process issue. The
second is
> what I believe is a technical issue, that OF0 seems like it does not
meet a
> standard of technical excellence.
> 
> For the first issue -- when MRHOF came up for discussion, we (as a WG)
> agreed that objective functions should be metric-independent. To
ensure
> interoperability of different OF implementations, this means an OF
needs to
> specify with reasonable (but not complete) detail how it processes a
metric
> container. It sounds like your answer is that OF0 ignores a metric
container.
> This seems like a completely reasonable specification in terms of
process,
> given the expectations laid out for OFs.
> 
[Pascal] I'll propose some words along this line. Your summary is good.
OF0 does not expect a metric container, and if there is one, it will
ignore it.
The result is that OF0 works when the link metric we care is additive
and for can be transformed in a scalar 1..16. The simplest example is an
administrative cost.
The question to the group is whether we want to enter the discussion
about dynamic metrics hysteresis and so on, or if we leave it at an
assumption that the link metric is rather stable.

> The second issue I guess we can disagree on. Maybe it would be helpful
if
> you could sketch a concrete RPL scenario -- maybe from one of the
> application drafts -- where OF0 would be a good solution? That might
help
> ground this discussion.
[Pascal] This is probably an interesting discussion. Then again, RPL
does not have to be limited to what it was envisioned for. By design,
OF0 leave a lot of liberty to the deployment as to which information is
turn into the scalar hop cost, thus opens a wide scope of applications,
not all in typical LLN environments.
An example could be found in industrial, where we have the concept of a
backbone, such as being studied at ISA100.15. The most common approaches
for solve the backbone problem is a WIFI (.11a usually) mesh. At the
moment, the WIFI mesh is by force 'mesh under' and the end-to-end path
will suffer unless we teach RPL to the Mesh APs at the same time as we
connect the RPL network to the mesh backbone.

Pascal

---

From: Don Sturek <[email-masked]>
Date: Sat, 18 Dec 2010 06:18:48 -0800

Hi pascal,

What you wrote below in the last paragraph is wrong.  In fact, it is not 2 Dags that must be created but an order n number of Dags to cover any of the return paths to any of the nodes which could have generated a request.

Don

Sent from my iPad

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Sat, 18 Dec 2010 16:25:54 +0200

My understanding WRT a solution to the asymmetric links was that that RPL
can settle with just one DAG by use of DAO messages that allows a
bi-directional downwards route creation.

Can that be considered a legit solution to asymmetric links a well?

Regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Don Sturek
Sent: Saturday, December 18, 2010 4:19 PM
To: Pascal Thubert (pthubert)
Cc: ROLL WG
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi pascal,

What you wrote below in the last paragraph is wrong.  In fact, it is not 2
Dags that must be created but an order n number of Dags to cover any of
the return paths to any of the nodes which could have generated a request.

Don

Sent from my iPad

---

From: Don Sturek <[email-masked]>
Date: Sat, 18 Dec 2010 07:46:51 -0800

Hi yoav,

True, however then you need some OF to handle asymmetric links.   I think pascal proposes separate DAGs to handle that.

Don

Sent from my iPad

---

From: Michael Richardson <[email-masked]>
Date: Sat, 18 Dec 2010 13:13:21 -0500

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Third, RPL by construction is a good routing protocol for
    Pascal> certain topologies that are inherently based on hub and
    Pascal> spoke. I listed a number in this thread already. Think
    Pascal> dynamic overlays like VPNs for one.

And let me tell you... VPNs are often really lossy, because they often
break...

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Matteo Paris <[email-masked]>
Date: Sun, 19 Dec 2010 23:45:38 -0500

My understanding is that asymmetric links have to be detected by the 
link layer.  Then the asymmetry can be reflected in the routing 
metric.  Any OF that uses a bidirectional metric (like ETX) will do.

If the link layer does not detect unidirectional links, and metric 
values are based on one-way information only (eg, receipt of DIOs), 
it is easy for RPL to get wedged.  No number of upward or downward 
DAGs will help.

Matteo

At 7:46 AM -0800 12/18/10, Don Sturek wrote:
>Hi yoav,
>
>True, however then you need some OF to handle asymmetric links.   I 
>think pascal proposes separate DAGs to handle that.
>
>Don
>
>Sent from my iPad
>

---

From: Philip Levis <[email-masked]>
Date: Mon, 20 Dec 2010 08:21:32 -0800

> Please refrain for rewording my sentences.

I apologize if I reworded; I was trying to understand what you were  
saying. When you say "wireless emulations that provide an acceptable  
service," what do you mean? It's well understood that a multihop  
wireless network and a single-hop wireless access network behave very  
differently. It's also well understood that wireless networks in  
unlicensed spectra (e.g., WiFi) behave very differently than those in  
licensed spectra (satellite, military).

> routing protocol but the lack of a vlan-equivalent tagging in the IPv6

I'm sorry, I again still don't understand. I was asking for  
references for technologies that build spanning trees over wireless  
bridges. I was assuming by "wireless bridge" you mean "repeater?"  
Given standard WiFi association algorithms, building a spanning tree  
that includes wireless APs is not particularly difficult, nor does it  
encounter the challenges of wireless.

> assumption that the link metric is rather stable.

I feel like we've come around full circle. I originally argued  
against the Rank/Metric distinction (as did many others), feeling  
like one of the two was sufficient for >90% of uses. You argued  
strongly that having both was critical. But now you're proposing an  
objective function that ignores metrics?

> does not have to be limited to what it was envisioned for.

Correct. But *we* are limited to what we're chartered for. Given that  
OF0, as described, seems like it is not useful in LLNs, I don't  
understand why it's being discussed. To repeat my question -- can you  
please sketch a concrete RPL scenario, from one of the application  
drafts, where one would use OF0? Otherwise this seems like we're  
getting way ahead of ourselves: the first objective function is one  
that's useless for the domain RPL was designed for.

One more concrete suggestion: given the confusion over whether OF0 is  
the "default" objective function, I suggest that it have a different  
name, such as OFNM, for Objective Function No Metrics.

Phil

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Dec 2010 13:04:09 +0100

Hi Don:

You lost me. What is n? Why do you need many DAGs?

Pascal

> Sent: Saturday, December 18, 2010 3:19 PM
> Cc: Philip Levis; ROLL WG
> What you wrote below in the last paragraph is wrong.  In fact, it is
not 2 Dags
> that must be created but an order n number of Dags to cover any of the
> return paths to any of the nodes which could have generated a request.
> 
> Don
> 
> 
> Sent from my iPad
> 
> > not mean that it has to be limited to anything as long as it works
> > fine there too.
> >
> > topologies that are inherently based on hub and spoke. I listed a
> > number in this thread already. Think dynamic overlays like VPNs  for
one.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Dec 2010 13:39:26 +0100

> I apologize if I reworded; I was trying to understand what you were
saying.
> When you say "wireless emulations that provide an acceptable service,"
> what do you mean? It's well understood that a multihop wireless
network
> and a single-hop wireless access network behave very differently. It's
also
> well understood that wireless networks in unlicensed spectra (e.g.,
WiFi)
> behave very differently than those in licensed spectra (satellite,
military).
[Pascal] I think we agree there. 
This discussion has wandered in the field of RPL's applicability. Maybe
that piece should be separated from the finalization of the OF0 draft.
I am trying to attract your attention on the mixed wireless and wired
backbone networks, on which spanning tree is being utilized.
I think that RPL could be an interesting alternate in a number of cases.

> I'm sorry, I again still don't understand. I was asking for references
for
> technologies that build spanning trees over wireless bridges. I was
assuming
> by "wireless bridge" you mean "repeater?"
[Pascal] 
[Pascal] Hum, no. Google would be your friend here. A wireless bridge is
actually a split bridge using wireless to connect 2 wired segments. Like
a good old aironet 350.
But then again we're straying. The point I want to make is that there
are some real and deployed networks were a radio is designed to connect
to another radio. 
In such an network, the end points are positioned optimally to obtain an
acceptable service. For a network administrator, this link is equivalent
to a wire.

> Given standard WiFi association algorithms, building a spanning tree
that
> includes wireless APs is not particularly difficult, nor does it
encounter the
> challenges of wireless.

<snip>
 
> I feel like we've come around full circle. I originally argued against
the
> Rank/Metric distinction (as did many others), feeling like one of the
two was
> sufficient for >90% of uses. You argued strongly that having both was
critical.
> But now you're proposing an objective function that ignores metrics?
> 
[Pascal] Fun isn't it. But no we have NOT switched sides : )

I still think that separating the metrics and the rank is a fundamental
design point in RPL and I'll defend it to the end.

At the same time, people (including you) came asking for something
simpler:
- What if I do not have metrics that my various implementations all
understand?
- What if propagating all those metrics is too costly?
- What if my case is so simple that propagating those metrics is
overkill (eg wire)

OF 0 serves that need. It will work if the hop metric can be changed in
a stable additive integer between 1 and 16.

> Correct. But *we* are limited to what we're chartered for. Given that
OF0, as
> described, seems like it is not useful in LLNs, I don't understand why
it's being
> discussed. To repeat my question -- can you please sketch a concrete
RPL
> scenario, from one of the application drafts, where one would use OF0?
> Otherwise this seems like we're getting way ahead of ourselves: the
first
> objective function is one that's useless for the domain RPL was
designed for.
the
> "default" objective function, I suggest that it have a different name,
such as
> OFNM, for Objective Function No Metrics.
> 
[Pascal] 
OF 0 is not the default OF (there none). But is it the last resort, when
nothing else is either available or needed.
The 0 indicates the absolute minimalistic aspect of that OF. Like a 0 in
a soda name as opposed to  a default.
I'll glad to add words from this discussion and be very specific about
this.

Now, people have been used to that name and changing might increase the
confusion, wouldn't you think?
Let's see what other people say. If we decide to change, I tend to favor
LROF (Last Resort OF).

Pascal

---

From: "Don Sturek" <[email-masked]>
Date: Wed, 22 Dec 2010 05:26:55 -0800

Hi Pascal,

I think my point below is we cannot set up separate DAGs to overcome the
issue of not having a way of dealing with asymmetric links (which will
occur).  I believe we need a meaningful OF to deal with filtering out
asymmetric links within a single DAG.

Don

-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2010 4:04 AM
To: Don Sturek
Cc: Philip Levis; ROLL WG
Subject: RE: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Don:

Pascal

not 2 Dags
one.

---

From: Matteo Paris <[email-masked]>
Date: Wed, 22 Dec 2010 11:14:31 -0500

Hi Don and Pascal,

As RPL is currently designed, asymmetric links are a link layer 
issue, not a RPL issue.

Any DIO received on a unidirectional link should be dropped and not 
processed further by the OF.  If a link is highly asymmetric (one 
direction is poor), then that link will provide poor performance 
regardless of which direction traffic is flowing.  The link layer 
will take this into account by assigning it a poor metric value.  The 
OF doesn't need to take any special action.  Whether a link has a 
poor metric value because it is asymmetric or because it is a bad 
link in both directions, the result is the same and the metric will 
see to it that it is avoided if there are better routes available.

There is no other existing mechanism in RPL for handling asymmetric 
links.  It can't be done by building multiple DAGs and it can't be 
done by the OF.

Matteo

---

From: "Don Sturek" <[email-masked]>
Date: Wed, 22 Dec 2010 08:26:54 -0800

Hi Matteo,

I think OF0 needs to be beefed up to use something more than just hop count.
I agree that the exchange of hop metrics is lower layer than RPL but there
is no reason that other IETF protocols cannot be used to establish the hop
metrics (MANET NHDP for example, NS/NA, etc.).

I don't think there is any activity in IEEE 802.15.4 (task group 4e) to deal
with hop metrics.

Don

-----Original Message-----
From: Matteo Paris [mailto:[email-masked]] 
Sent: Wednesday, December 22, 2010 8:15 AM
To: [email-masked]; 'Pascal Thubert (pthubert)'
Cc: 'ROLL WG'
Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt

Hi Don and Pascal,

Matteo

---

From: Matteo Paris <[email-masked]>
Date: Wed, 22 Dec 2010 12:00:11 -0500

Hi Don, we're in agreement then.  But rather than trying to beef up 
the "Last Resort OF" OF0, why not just start with MRHOF, which does 
not assume hop count and is much more suitable for use over 802.15.4?

Matteo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 24 Dec 2010 13:14:56 +0100

Hi Don:

My proposal is 2 set up 2 DAGS, one DIO only for upward traffic, and one
DIO+DAO for downward traffic. 
The first DAG would be established using metrics that describe the
upward direction of the link, while the other would be established with
downwards metrics.
The resulting topology is roughly equivalent to having a single DAG with
an OF that could read metrics for both directions. In any case, you end
up with 2 sets of parents.

>From your response, it is quite probable that you misunderstood that
proposal, and quite probable that you interpreted my words as a DAG per
destination.
If so, please reconsider...

Merry Xmas yall!

Pascal

> Sent: Saturday, December 18, 2010 4:47 PM
> To: Yoav Ben-Yehezkel
> Cc: Pascal Thubert (pthubert); ROLL WG
think
> pascal proposes separate DAGs to handle that.
> 
> Don
> 
> Sent from my iPad
> 
> > My understanding WRT a solution to the asymmetric links was that
that
> > RPL can settle with just one DAG by use of DAO messages that allows
a
> > not 2 Dags that must be created but an order n number of Dags to
cover
> > any of the return paths to any of the nodes which could have
generated a
> request.
> >> number in this thread already. Think dynamic overlays like VPNs
for one.

---

From: Skip Ashton <[email-masked]>
Date: Fri, 24 Dec 2010 22:11:50 -0500

We have discussed this before and it does not work properly.  The DAG
represents the metric back to the root and in this case we need to know the
link quality between two adjacent devices.  Knowing the aggregate cost to
the root does not give you enough information on if this link is suitable.

Skip