Subject: Re: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-00

From: Philip Levis <[email-masked]>
Date: Thu, 13 May 2010 10:48:09 -0700

On Apr 28, 2010, at 10:46 AM, Mukul Goyal wrote:

> Hi all
> 
> The following draft has been submitted for WG's consideration. It describes the additional mechanisms required to support P2P routing in LLNs. The draft first provides a high level description of the mechanisms and then proposes one way of realizing these mechanisms in RPL.
> 
> Regards
> Mukul

Mukul,

I read over p2p-rpl-00. Overall, I think the proposal is sensible. It's clear from the home automation requirements that RPL needs to be able to quickly repair/discover routes. This draft suggests a simple way RPL can support such functionality. The basic mechanism is similar to AODV/DYMO/DSR, which makes sense. The core ideas in all of the protocols are sound, we just need to be careful with the details. I have two major questions:

1) Why are there special measurement packets? This seems to come out of the required functionality section, but I don't understand its original seed. Typically, network and/or route measurement are management concerns and are handled there, rather than inside a routing protocol. This seems like the wrong place to accomplish the goal.

2) The mechanisms for discovering/establishing "good enough" routes are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism, with the caveat that the goal is "good enough" rather than optimal. But, as is always with such things, the devil is in the details. For example, when a node sends a discovery messages, who can forward it? If we say that *any* node can forward it, we're in dangerous territory; if we say that a node must have the sender in its neighbor set, then things look a lot better (it means there are link estimates and we avoid the AODV hopcount problem). Can you be more specific on what the discovery forwarding algorithm is?

Nits:

4.7 says "To facilitate the use of a DIO as the Discovery message, we suggest the creation of a new "Route Discovery" option that each DIO/Discovery message must carry." I assume this means: 

"We suggest the creation of a new "Route Discovery" option that a DIO message may carry. Inclusion of this option allows a DIO to act as a Route Discovery message."

Otherwise every DIO has to have this option?

4.7 seems to suggest that any node forwards a Route Discovery; I think this is problematic (see 2 above).

Phil

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 17 May 2010 09:28:52 +0200

Hi all

The P2P draft has been out for some weeks now.
The team would like to poll the WG for directions whether this is
the right approach.

Phil has indicated some agreement.
What about the rest of the WG?

Others in favour of the work?
Any alternative proposals?

Otherwise the P2P team will conclude that we are on the right track
and go on proposing specific frame format additions/modifications
and mechanisms for RPL.
When the required maturity is reached, those proposed additions/changes
should be adopted by the RPL spec; thus obsoleting this draft.

Thanks,
  Anders

> On Apr 28, 2010, at 7:46 PM, Mukul Goyal wrote:
> 
> > Hi all
> >
> > The following draft has been submitted for WG's consideration. It 
> > describes the additional mechanisms required to support P2P 
> routing in 
> > LLNs. The draft first provides a high level description of the 
> > mechanisms and then proposes one way of realizing these 
> mechanisms in 
> > RPL.
> >
> > Regards
> > Mukul
> >
> > ----- Forwarded Message -----
> > From: "IETF I-D Submission Tool" <[email-masked]>
> > To: [email-masked]
> > Sent: Wednesday, April 28, 2010 12:40:38 PM GMT -06:00 US/Canada 
> > Central
> > Subject: New Version Notification for draft-dt-roll-p2p-rpl-00
> >
> >
> > A new version of I-D, draft-dt-roll-p2p-rpl-00.txt has been 
> > successfully submitted by Mukul Goyal and posted to the IETF 
> > repository.
> >
> > Filename:	 draft-dt-roll-p2p-rpl
> > Revision:	 00
> > Title:		 Mechanisms to Support Point-to-Point 
> Routing in Low Power  
> > and Lossy Networks
> > Creation_date:	 2010-04-28
> > WG ID:		 Independent Submission
> > Number_of_pages: 13
> >
> > Abstract:
> > This draft presents mechanisms to determine the end-to-end 
> cost of an 
> > existing route and to discover/establish "on demand" one or more 
> > routes between two nodes in a low power and lossy network.  
> This draft 
> > also proposes functionality that would enable RPL to 
> provide these P2P 
> > mechanisms.
> >
> >
> >
> > The IETF Secretariat.
> >
> >
> > _______________________________________________
> > 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: "JeongGil Ko (John)" <[email-masked]>
Date: Mon, 17 May 2010 03:32:13 -0400

I also had some concerns and need for clarifications (check previous emails) but I think it's a nice starting point to get a convergence in the ideas.

-John 

>>> also proposes functionality that would enable RPL to 

------
JeongGil Ko (John)
Ph.D. Student
Department of Computer Science
Johns Hopkins University
http://www.cs.jhu.edu/~jgko

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 17 May 2010 10:44:57 +0200

Hi Phil,
thanks for your feedback. Comments below.

On Thu, May 13, 2010 at 7:48 PM, Philip Levis <[email-masked]> wrote:

>
> The mechanisms for discovering/establishing "good enough" routes are a bit
> vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism,
> with the caveat that the goal is "good enough" rather than optimal. But, as
> is always with such things, the devil is in the details. For example, when a
> node sends a discovery messages, who can forward it? If we say that *any*
> node can forward it, we're in dangerous territory; if we say that a node
> must have the sender in its neighbor set, then things look a lot better (it
> means there are link estimates and we avoid the AODV hopcount problem). Can
> you be more specific on what the discovery forwarding algorithm is?
>
>
I'm not sure what you are referring to here, but I suppose you are actually
asking two different questions here:
(1) if any node can forward the discovery messages, how do we make sure that
there are no "broadcast storm" or loops?
(2) if any node can forward the discovery messages, does it mean it could
also be non-related DAGwise (neither parent, nor child)?

For now, the draft is more a high level "declaration of intent" than an
actual spec, so the answer to question (1) is not yet specified. But of
course it will have to be (judging from the amount of experience on this
subject in this WG I'm sure it's going to dealt with soon and fine ;).

For question (2), the answer is yes: we may need to go along links that are
not DAG-related, especially if there is a unique DAG up and running,
pointing towards a single access point or sink. In this context, I think I
see your concern: if the quality of these links/paths are not monitored
properly, how do we now they are good enough? So I agree with you, we need
to think about how to monitor and evaluate the quality of these
links/paths.

This probably means slightly more state maintained in some nodes throughout
the network... Do you have any suggestion on how to do this efficiently? I
remember you were mentioning some related work in the domain, in
Anaheim. Again, the draft is not a spec yet, and just a high level
description of some needed functionalities, so any help or suggestion on how
to achieve these efficiently is welcome.

cheers

Emmanuel

---

From: JP Vasseur <[email-masked]>
Date: Mon, 17 May 2010 15:04:54 +0200

Hi Anders,

Co-chair hat-off.

I think that it goes in right direction.

Few comments for the moment.

1)  o  The constraint to route only along a DAG leading to significantly
       suboptimal P2P routes and traffic congestion near the DAG root.
JP> You may want to soften the statement here since the path computed  
along the DAG
may be sub-optimal .. it all depends on the destination, degree of  
meshing of the DAG, etc ...
I think that the argument of not having to maintain route maintenance  
for some nodes is
more compelling.

2)   Such applications require a mechanism for "reactive route  
discovery"
    and the ability to route "across DAGs".

JP> Why is it required to route across DAGs ? I guess that you meant  
"non DAG" routes ?

3) The mechanisms described in this document are intended to be employed
    as complementary to RPL in specific scenarios that need point-to-
    point (P2P) routes between arbitrary nodes.

JP> More specifically, I think that we agree that it will be part of  
RPL, as an optional mechanism.

4) Section 4.2: objective function

JP> You actually do not need an OF for that. Just use the metrics  
specified in the Routing-metrics ID,
adding a path-cost-bound object (for the "good enough" criteria).

5) 4.6.  Transport of Routing Metrics
    The Metric Container option defined in RPL-07 can be used to carry
    both the aggregated end-to-end and the local values for the routing
    metrics being used to define the routing cost.  Additional metric
    objects may need to be defined to carry the aggregated end-to-end
    routing cost and a source-route unmodified from one node to another;

JP> with regards to the second part of the paragraph I would suggest  
to use the same metrics as defined
in the routing-metric ID.

6) We just need to have a section somewhere indicating that such  
reactive mechanism has a cost too and the resulting
path cost decrease is not known a priori and may end up being close to  
the DAG cost for that destination. I am not
questioning the usefulness of the mechanism, just make sure to  
indicate it.

Thanks.

JP.

---

From: "Anders Brandt" <[email-masked]>
Date: Mon, 17 May 2010 16:18:01 +0200

Hi JP
 
Please find comments inline
 
- Anders

________________________________

	From: JP Vasseur [mailto:[email-masked]] 
	Sent: Monday, May 17, 2010 15:05
	To: Anders Brandt; Mukul Goyal
	Cc: roll
	Subject: Re: [Roll] Fwd: New Version Notification
fordraft-dt-roll-p2p-rpl-00

	Hi Anders, 

	Co-chair hat-off.

	1)  o The constraint to route only along a DAG leading to
significantly
	      suboptimal P2P routes and traffic congestion near the DAG
root.
	
	JP> You may want to soften the statement here since the path
computed along the DAG 
	may be sub-optimal .. it all depends on the destination, degree
of meshing of the DAG, etc ...
	I think that the argument of not having to maintain route
maintenance for some nodes is 
	more compelling. 

What about:
"The constraint to route only along a DAG potentially leading to
significantly
suboptimal P2P routes and traffic congestion near the DAG root."   ?

	JP> Why is it required to route across DAGs ? I guess that you
meant "non DAG" routes ? 

Agreed. What the text should say is:
"across a DAG", "across the branches of a dag" or "along non-DAG routes"
(pick one) 

	3) The mechanisms described in this document are intended to be
employed
	   as complementary to RPL in specific scenarios that need
point-to-
	   point (P2P) routes between arbitrary nodes.

	JP> More specifically, I think that we agree that it will be
part of RPL, as an optional mechanism. 

Negative. 
RPL will never be able to deliver the required performance for home and
building without decent support for battery operation and reactive
self-healing.

	JP> You actually do not need an OF for that. Just use the
metrics specified in the Routing-metrics ID,
	adding a path-cost-bound object (for the "good enough"
criteria). 

Great. This is an example of why it will be valuable for RPL as a whole
if the WG starts discussing
how to achieve the stated goals of the draft.
OF or metrics - I leave it for the experts to decide which is the right
thing. As long as I can ask for a
"good enough" route as result of a reactive discovery. I need the lamp
to turn on with low delay.
Later, I may have time for fine-tuning the route.

	5) 4.6. Transport of Routing Metrics
	   The Metric Container option defined in RPL-07 can be used to
carry
	   both the aggregated end-to-end and the local values for the
routing
	   metrics being used to define the routing cost.  Additional
metric
	   objects may need to be defined to carry the aggregated
end-to-end
	   routing cost and a source-route unmodified from one node to
another;

	JP> with regards to the second part of the paragraph I would
suggest to use the same metrics as defined
	in the routing-metric ID.

	6) We just need to have a section somewhere indicating that such
reactive mechanism has a cost too and the resulting
	path cost decrease is not known a priori and may end up being
close to the DAG cost for that destination. I am not
	questioning the usefulness of the mechanism, just make sure to
indicate it.

	Thanks.

	JP.

		Hi all
		
		The P2P draft has been out for some weeks now.
		The team would like to poll the WG for directions
whether this is
		the right approach.

		
		
		Otherwise the P2P team will conclude that we are on the
right track
		and go on proposing specific frame format
additions/modifications
		and mechanisms for RPL.
		When the required maturity is reached, those proposed
additions/changes
		should be adopted by the RPL spec; thus obsoleting this
draft.
		
		Thanks,
		 Anders

				Hi all

				The following draft has been submitted
for WG's consideration. It 

				describes the additional mechanisms
required to support P2P 

			routing in 

				LLNs. The draft first provides a high
level description of the 

				mechanisms and then proposes one way of
realizing these 

			mechanisms in 

				RPL.

				Regards

				Mukul

				----- Forwarded Message -----

				From: "IETF I-D Submission Tool"
<[email-masked]>

				To: [email-masked]

				Sent: Wednesday, April 28, 2010 12:40:38
PM GMT -06:00 US/Canada 

				Central

				Subject: New Version Notification for
draft-dt-roll-p2p-rpl-00

				A new version of I-D,
draft-dt-roll-p2p-rpl-00.txt has been 

				successfully submitted by Mukul Goyal
and posted to the IETF 

				repository.

				Revision: 00

				Title: Mechanisms to Support
Point-to-Point 

			Routing in Low Power  

				and Lossy Networks

				Number_of_pages: 13

				Abstract:

				This draft presents mechanisms to
determine the end-to-end 

			cost of an 

				existing route and to discover/establish
"on demand" one or more 

				routes between two nodes in a low power
and lossy network.  

			This draft 

				also proposes functionality that would
enable RPL to 

			provide these P2P 

				mechanisms.

				The IETF Secretariat.

				Roll mailing list

				[email-masked]

			Roll mailing list

			[email-masked]

---

From: Philip Levis <[email-masked]>
Date: Mon, 17 May 2010 09:09:46 -0700

On May 17, 2010, at 1:44 AM, Emmanuel Baccelli wrote:

> The mechanisms for discovering/establishing "good enough" routes are a bit vague. 3.2 basically says that nodes use an AODV/DSR/DYMO-like mechanism, with the caveat that the goal is "good enough" rather than optimal. But, as is always with such things, the devil is in the details. For example, when a node sends a discovery messages, who can forward it? If we say that *any* node can forward it, we're in dangerous territory; if we say that a node must have the sender in its neighbor set, then things look a lot better (it means there are link estimates and we avoid the AODV hopcount problem). Can you be more specific on what the discovery forwarding algorithm is?
> 
> 
> I'm not sure what you are referring to here, but I suppose you are actually asking two different questions here: 
> (1) if any node can forward the discovery messages, how do we make sure that there are no "broadcast storm" or loops?
> (2) if any node can forward the discovery messages, does it mean it could also be non-related DAGwise (neither parent, nor child)?
> 
> For now, the draft is more a high level "declaration of intent" than an actual spec, so the answer to question (1) is not yet specified. But of course it will have to be (judging from the amount of experience on this subject in this WG I'm sure it's going to dealt with soon and fine ;).
> 
> For question (2), the answer is yes: we may need to go along links that are not DAG-related, especially if there is a unique DAG up and running, pointing towards a single access point or sink. In this context, I think I see your concern: if the quality of these links/paths are not monitored properly, how do we now they are good enough? So I agree with you, we need to think about how to monitor and evaluate the quality of these links/paths. 
> 
> This probably means slightly more state maintained in some nodes throughout the network... Do you have any suggestion on how to do this efficiently? I remember you were mentioning some related work in the domain, in Anaheim. Again, the draft is not a spec yet, and just a high level description of some needed functionalities, so any help or suggestion on how to achieve these efficiently is welcome.

Actually, it was neither 1 nor 2. :)

1 is a non-starter and there are some known techniques for preventing it, I assume the actual specification will include them. The one caveat is that we want to minimize state requirements and avoid things like sequence number loops (where A > B > C > A for wraparound reasons).

I agree with your comment on 2 -- nodes in a P2P route may need to be neither parents nor children. My concern is a little more subtle. 

One of the dangers of on-demand mechanisms is that routes are established quickly, but detecting good links requires time. Node B receiving a discovery message from node A does not imply that A <-> B can be included in a workable route. If node B does not have a good estimate of AB, it should not forward a discovery message after hearing it from  A. Something as simple as saying that a node MUST NOT forward a discovery message if

  1) the transmitter is outside its neighbor set, or
  2) the link to/from the transmitter has poor properties (realize this needs to be more precise).

might be sufficient.

This is one of those cases where doing the simple and easy thing (just forward!) has terrible implications. I realize that the current statement of intent calls for forwarded discovery messages to include metrics/cost/Rank/etc. What's critical is that receiving a discovery packet be insufficient for determining this value, because in LLNs it is.

Does that make sense?

Phil

---

From: JP Vasseur <[email-masked]>
Date: Wed, 19 May 2010 06:01:57 +0200

Hi Anders,

On May 17, 2010, at 4:18 PM, Anders Brandt wrote:

> Subject: Re: [Roll] Fwd: New Version Notification fordraft-dt-roll- 
> p2p-rpl-00
>
> Hi Anders,
>
> Co-chair hat-off.
>

OK
> "across a DAG", "across the branches of a dag" or "along non-DAG  
> routes"  (pick one)

I would choose "non DAG route"
> building without decent support for battery operation and reactive  

You misunderstood my point. The WG agreed that this was a MUST, I am  
not questioning the usefulness
of it. I just meant to say that all implementations will not need it,  
that's all (thus the term optional).

> Great. This is an example of why it will be valuable for RPL as a  
> whole if the WG starts discussing
> OF or metrics - I leave it for the experts to decide which is the  
> right thing. As long as I can ask for a
> "good enough" route as result of a reactive discovery. I need the  
> lamp to turn on with low delay.

We're in sync.

> path cost decrease is not known a priori and may end up being close  
> to the DAG cost for that destination. I am not
I can help provide some text, if that helps.

Thanks.

JP.