Subject: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

From: "roll issue tracker" <[email-masked]>
Date: Thu, 05 Apr 2012 11:02:21 -0000

#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate
completion of route discovery?

 Resolution: No because multiple DROs would be generated if multiple source
 routes are being discovered.

 Discussion:

 p15 :  Stop (S): This flag, when set to one by a target, indicates that
 the P2P-RPL route discovery is over.

 [Cedric]
 Is this bit really usefull ? My guess is that it will be always set to 1.
 If you hear a DRO, this indeed means that the RDO has reached the target,
 so you could just stop processing RDO when you hear a DRO.
 Do we really need a flag to stop RDO processing or the hearing of a DRO
 type message could do the job ?

 [Mukul]
 A P2P-RPL invocation might involve discovery of multiple source routes. In
 that case, receipt of a DRO does not mean route discovery is over. Only
 when the target sets the stop flag in the DRO, a node could be sure that
 the route discovery is over.

-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/95>
roll <http://tools.ietf.org/wg/roll/>

---

From: C Chauvenet <[email-masked]>
Date: Thu, 5 Apr 2012 14:38:31 +0000

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de roll issue tracker
Envoyé : jeudi 5 avril 2012 13:02
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

#95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

 Resolution: No because multiple DROs would be generated if multiple source  routes are being discovered.

 Discussion:

 p15 :  Stop (S): This flag, when set to one by a target, indicates that  the P2P-RPL route discovery is over.

 [Cedric]
 Is this bit really usefull ? My guess is that it will be always set to 1.
 If you hear a DRO, this indeed means that the RDO has reached the target,  so you could just stop processing RDO when you hear a DRO.
 Do we really need a flag to stop RDO processing or the hearing of a DRO  type message could do the job ?

 [Mukul]
 A P2P-RPL invocation might involve discovery of multiple source routes. In  that case, receipt of a DRO does not mean route discovery is over. Only  when the target sets the stop flag in the DRO, a node could be sure that  the route discovery is over.

[Cedric2]
OK fo multiple discovery.
But if I want to discover a route to a multicast group of target. I set a multicast adress in the target field of the RDO. Then, do I received as many DRO message as the number of target reached ? In that case, would the first DRO with a "S" flag stop the RDO propagation to reach all the target included in the multicast group ?
-- 
-----------------------------------+---------------------
 Reporter:  jpv@…                  |      Owner:  mukul@…
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:
Component:  p2p-rpl                |    Version:
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+---------------------

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 8 Apr 2012 16:38:26 -0500 (CDT)

Hi Cedric

Please see the response inline.

Thanks
Mukul

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2]

[Mukul2]
A target cannot set the S flag to one in the DRO if the target address in the P2P-RDO specified a multicast address. See the following text at the end of page 21 in P2P-RPL-9:

"The target MAY set the stop flag inside the DRO message to one if

Goyal, et al.           Expires September 7, 2012              [Page 21]
 
Internet-Draft         draft-ietf-roll-p2p-rpl-09             March 2012

   o  this router is the only target specified in the corresponding DIO,
      i.e., the corresponding DIO specified a unicast address of the
      router as the Target inside the P2P-RDO with no additional targets
      specified via RPL Target Options; and

"

---

From: C Chauvenet <[email-masked]>
Date: Tue, 10 Apr 2012 16:32:07 +0000

Inline,

-----Message d'origine-----
De : Mukul Goyal [mailto:[email-masked]] 
Envoyé : dimanche 8 avril 2012 23:38
À : C Chauvenet
Cc : [email-masked]; [email-masked]
Objet : Re: [Roll] [roll] #95: Why need stop flag? Is the receipt of DRO not sufficient to indicate completion of route discovery?

Hi Cedric

Thanks
Mukul

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2]

[Mukul2]

 

" 

[Cedric3] 
So how do you stop the RDO flooding when the target adress is mulicast ?

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 05:23:46 -0500 (CDT)

Please see inline

Thanks
Mukul

 Discussion:

 [Cedric]

 [Mukul]

[Cedric2]

[Mukul2]

 

" 

[Cedric3] 

[Mukul3]

Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would hopefully avoid unnecessary message generation. Note that the draft recommends a very small value for the redundancy constant.

---

From: C Chauvenet <[email-masked]>
Date: Wed, 11 Apr 2012 12:02:17 +0000

inline,

> Stop flag cannot be used when the target address is multicast or when multiple unicast targets are there. The DIO generation will stop when the DAG dies. In the meanwhile, trickle algorithm would h…

[Cedric4]
So in this case, the RDO (I guess this is what you mean when you mentioned "DIO" in you previous message) generation to discover the route is never ending until the temporary DAG dies ?
I guess the RDO flooding would stop according to the MaxRank/NH field  of the P2P-RDO message.
But if this field is set to 0 (meaning infinity according to section 7.1), we should find a mechanism to stop the discovery mechanism.
What do you think ?

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 07:23:57 -0500 (CDT)

Please see inline.

Thanks
Mukul

[Cedric4]

[Mukul4] Never ending wont be the correct description. The temporary DAG lasts for a few seconds only. Plus, the trickle algorithm would prevent the generation of many DIOs.

[Cedric4]

[Mukul4]
Yes, it would. MaxRank and other routing constraints would always limit the scope of route discovery. Note that there are two separate things:
1) scope of discovery: how far the discovery message (P2P-RDO inside the DIO) travels. This is controlled by the routing constraints and the maxRank field inside the P2P-RDO.
2) How many discovery messages are generated by the nodes that join the DAG: this is controlled by trickle timer and ultimately by the DAG life time. The stop flag in the DRO is an optimization that allows DIO generation to stop in the nodes that can hear the stop flag.

[Cedric4]

[Mukul4]
To tell the truth, MaxRank is basically a way to avoid putting a metric container in the DIO (when a limit on rank is the only constraint you want to specify). The scope of discovery is limited by both MaxRank as well as the routing constraints in the metric container.

---

From: C Chauvenet <[email-masked]>
Date: Wed, 11 Apr 2012 14:04:53 +0000

Hi, 

See inline, 

> 2) How many discovery messages are generated by the nodes that join the DAG: this is controlled by trickle timer and ultimately by the DAG life time. The stop flag in the DRO is an optimization tha…

[Cedric5]
Actually, the problem for stopping the discovery process without the "S" flag is also present with unicast addresses, because not all nodes will hear the DRO (Only the nodes in the neighborhood of DRO forwarders).
So we ended with some nodes forming and maintaining a temporary DAG even is they are not included in the discovered path, until the temporary DAG dies.
As you mentioned, the maxRank field, routing constraints, and trickle or DAG lifetime limit this overhead.
The section 9.2 of this draft give useful guidelines for trickle operation using the P2P RPL mechanism, and limit the flooding of RDO messages.
The only improvement we could add is to avoid the maintenance of some part of the temporary DAG that don't hear the DRO with the S flag.
This nodes will still send out some DIO when the trickle timer fires. Though, thank's to the trickle's operation described in section 9.2, they won't be propagated.
One possibility could be to state that : "if a DRO has not been heard within a certain period of time, then their node is not considered as a part of the discovered path and should leave the temporary DAG".
This "certain period of time" could be determined according to the network topology, the application, or the network diameter for instance and let to the implementation.
I see a benefit in the case of a discovery process to a unicast target in a very large and sparse network. Here, a lot of nodes will maintain unnecessary states if they are not part of the discovered path.
With the current spec, they will send periodic and unnessecary DIO. The handling of a "DRO timeout reception" could save packets, thus battery, bandwidth etc...

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 11 Apr 2012 12:32:07 -0500 (CDT)

Please see inline.

Thanks
Mukul

[Cedric5]

[Mukul5]
Two problems:
1) An intermediate router has no idea how long the target wants to wait before generating DRO.
2) If an intermediate router leaves the DAG early (ie before the DAG's lifetime is over), it might end up rejoining the DAG when it hears the DAG's DIO again.

[Cedric5] 

[Mukul5]
It would be much easier if the origin could choose a small (yet reasonable) lifetime for the DAG.

[Cedric5]

[Mukul5]
I am not sure this will work as I explained above.

---

From: C Chauvenet <[email-masked]>
Date: Thu, 12 Apr 2012 12:18:15 +0000

inline,

> 1) An intermediate router has no idea how long the target wants to wait before generating DRO.

[Cedric6]
Correct.

> 2) If an intermediate router leaves the DAG early (ie before the DAG's lifetime is over), it might end up rejoining the DAG when it hears the DAG's DIO again.

[Cedric6]
Yes. So if I understand correctly, even if a mechanism enable nodes that are not along the discovered path to leave the temporary DAG, they will join it at some point due to the temporary DAG maintenance messages (DIOs).
So in the end, the benefit I saw (Saving power, packets, state maintenance), is not there.
Then if there is no benefit, there is no reason to change the spec.
So if what I wrote above is correct, I'm OK to close the ticket and don't change anything about the "S" flag behavior.

> It would be much easier if the origin could choose a small (yet reasonable) lifetime for the DAG.

[Cedric6]
I agree that this parameters will greatly impact on the RPL P2P cost.

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 12 Apr 2012 07:59:57 -0500 (CDT)

Resolution:
------------

 No because multiple DROs would be generated if multiple source  routes are being discovered.

Discussion:
--------------

[Cedric]

[Mukul]

[Cedric2]
 
[Mukul2]

 

 " 
 
[Cedric3] 
 
[Mukul3]

[Cedric4]

[Cedric4]
 
[Mukul4]
 
[Cedric4]
 
[Mukul4]
 
[Cedric5]
 
[Mukul5]
Two problems:

[Cedric6]
Correct.

[Mukul5]

[Cedric6]

[Cedric5] 
 
[Mukul5]

[Cedric6]

[Cedric5]
 
[Mukul5]

---

From: "roll issue tracker" <[email-masked]>
Date: Fri, 13 Apr 2012 13:32:52 -0000

Changes (by jpv@…):

 * status:  new => closed
 * resolution:   => fixed

Comment:

 Resolution:
 ------------

 No because multiple DROs would be generated if multiple source  routes are
 being discovered.

 Discussion:
 --------------

 [Cedric]

 [Mukul]

 [Cedric2]
 OK fo multiple discovery.
 But if I want to discover a route to a multicast group of target. I set a
 multicast adress in the target field of the RDO. Then, do I received as
 many DRO message as the number of target reached ? In that case, would the
 first DRO with a "S" flag stop the RDO propagation to reach all the target
 included in the multicast group ?

 [Mukul2]
 A target cannot set the S flag to one in the DRO if the target address in
 the P2P-RDO specified a multicast address. See the following text at the
 end of page 21 in P2P-RPL-9:

 "

 [Cedric3]

 [Mukul3]

 Stop flag cannot be used when the target address is multicast or when
 multiple unicast targets are there. The DIO generation will stop when the
 DAG dies. In the meanwhile, trickle algorithm would hopefully avoid
 unnecessary message generation. Note that the draft recommends a very
 small value for the redundancy constant.

 [Cedric4]
 So in this case, the RDO (I guess this is what you mean when you mentioned
 "DIO" in you previous message) generation to discover the route is never
 ending until the temporary DAG dies ?

 [Mukul4] Never ending wont be the correct description. The temporary DAG
 lasts for a few seconds only. Plus, the trickle algorithm would prevent
 the generation of many DIOs.

 [Cedric4]
 I guess the RDO flooding would stop according to the MaxRank/NH field  of
 the P2P-RDO message.

 [Mukul4]
 Yes, it would. MaxRank and other routing constraints would always limit
 the scope of route discovery. Note that there are two separate things:
 1) scope of discovery: how far the discovery message (P2P-RDO inside the
 DIO) travels. This is controlled by the routing constraints and the
 maxRank field inside the P2P-RDO.
 2) How many discovery messages are generated by the nodes that join the
 DAG: this is controlled by trickle timer and ultimately by the DAG life
 time. The stop flag in the DRO is an optimization that allows DIO
 generation to stop in the nodes that can hear the stop flag.

 [Cedric4]
 But if this field is set to 0 (meaning infinity according to section 7.1),
 we should find a mechanism to stop the discovery mechanism.
 What do you think ?

 [Mukul4]
 To tell the truth, MaxRank is basically a way to avoid putting a metric
 container in the DIO (when a limit on rank is the only constraint you want
 to specify). The scope of discovery is limited by both MaxRank as well as
 the routing constraints in the metric container.

 [Cedric5]
 Actually, the problem for stopping the discovery process without the "S"
 flag is also present with unicast addresses, because not all nodes will
 hear the DRO (Only the nodes in the neighborhood of DRO forwarders).
 So we ended with some nodes forming and maintaining a temporary DAG even
 is they are not included in the discovered path, until the temporary DAG
 dies.
 As you mentioned, the maxRank field, routing constraints, and trickle or
 DAG lifetime limit this overhead.
 The section 9.2 of this draft give useful guidelines for trickle operation
 using the P2P RPL mechanism, and limit the flooding of RDO messages.
 The only improvement we could add is to avoid the maintenance of some part
 of the temporary DAG that don't hear the DRO with the S flag.
 This nodes will still send out some DIO when the trickle timer fires.
 Though, thank's to the trickle's operation described in section 9.2, they
 won't be propagated.
 One possibility could be to state that : "if a DRO has not been heard
 within a certain period of time, then their node is not considered as a
 part of the discovered path and should leave the temporary DAG".

 [Mukul5]
 Two problems:
 1) An intermediate router has no idea how long the target wants to wait
 before generating DRO.

 [Cedric6]
 Correct.

 [Mukul5]
 2) If an intermediate router leaves the DAG early (ie before the DAG's
 lifetime is over), it might end up rejoining the DAG when it hears the
 DAG's DIO again.

 [Cedric6]
 Yes. So if I understand correctly, even if a mechanism enable nodes that
 are not along the discovered path to leave the temporary DAG, they will
 join it at some point due to the temporary DAG maintenance messages
 (DIOs).
 So in the end, the benefit I saw (Saving power, packets, state
 maintenance), is not there.
 Then if there is no benefit, there is no reason to change the spec.
 So if what I wrote above is correct, I'm OK to close the ticket and don't
 change anything about the "S" flag behavior.

 [Cedric5]
 This "certain period of time" could be determined according to the network
 topology, the application, or the network diameter for instance and let to
 the implementation.

 [Mukul5]
 It would be much easier if the origin could choose a small (yet
 reasonable) lifetime for the DAG.

 [Cedric6]

 [Cedric5]
 I see a benefit in the case of a discovery process to a unicast target in
 a very large and sparse network. Here, a lot of nodes will maintain
 unnecessary states if they are not part of the discovered path.
 With the current spec, they will send periodic and unnessecary DIO. The
 handling of a "DRO timeout reception" could save packets, thus battery,
 bandwidth etc...

 [Mukul5]

-- 
-----------------------------------+----------------------
 Reporter:  jpv@…                  |       Owner:  mukul@…
     Type:  defect                 |      Status:  closed
 Priority:  major                  |   Milestone:
Component:  p2p-rpl                |     Version:
 Severity:  Submitted WG Document  |  Resolution:  fixed
 Keywords:                         |
-----------------------------------+----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/95#comment:1>
roll <http://tools.ietf.org/wg/roll/>