Subject: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?

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

#96: Can the draft recommend how much to wait before a target selects routes to
be sent back in DROs?

 Resolution: This is purely a local decision at the target. The draft
 should not make any recommendation in this regard.

 Discussion:

 p21 :  Example methods include selecting each route that meets the
 specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.

 [Cedric]
 How could we know the time to wait until we get all the RDO ?
 Is there a way to evaluate it according to some parameters related to the
 network (diameter of the network for instance) ?

 [Mukul] This has to be a local decision. Perhaps, the target can look at
 the aggregated values of the routing metrics from the origin and determine
 its distance from the origin. This distance estimate, along with trickle
 parameters, could perhaps give it a better idea of how much to wait. I
 dont think that the draft should talk about this.

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

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

---

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

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de roll issue tracker
Envoyé : jeudi 5 avril 2012 13:03
À : [email-masked]; [email-masked]
Cc : [email-masked]
Objet : [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?

#96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?

 Resolution: This is purely a local decision at the target. The draft  should not make any recommendation in this regard.

 Discussion:

 p21 :  Example methods include selecting each route that meets the  specified routing constraints
   until the desired number have been selected or selecting the best
   routes discovered over a certain time period.

 [Cedric]
 How could we know the time to wait until we get all the RDO ?
 Is there a way to evaluate it according to some parameters related to the  network (diameter of the network for instance) ?

 [Mukul] This has to be a local decision. Perhaps, the target can look at  the aggregated values of the routing metrics from the origin and determine  its distance from the origin. This distance estimate, along with trickle  parameters, could perhaps give it a better idea of how much to wait. I  dont think that the draft should talk about this.

[Cedric2]
OK, let's say it is up to the implementation and should be deterinied according to the specific set of metric/contraints in use.
A target from a DAG based on a latency metric could wait just a few ms after receiving the first RDO  and select the best path according to the latency metric.
A target from a DAG based on a energy metric could wait much more time after receiving the first RDO to be sure to use an energy efficient path, that could be discovered after some time, because of duty cycling nodes for instance.

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

---

From: Mukul Goyal <[email-masked]>
Date: Sun, 8 Apr 2012 17:12:59 -0500 (CDT)

Hi Cedric

Please see inline.

Thanks
Mukul

 Discussion:

 [Cedric]

[Cedric2]

[Mukul2] Choosing the wait time on the basis of specific metrics being used in route discovery could be one option. However, when an origin wants to discover low latency routes, it does not necessarily mean that the latency of the route discovery process has to be low as well. :) So, in general, I think that the time a target waits before sending DROs (which determines to some extent the latency of the route discovery process) is independent of the specific metrics/constraints being used in route discovery process. As I said before, I think the target should decide for itself how much should it wait before sending DRO(s). It may not be wise to make any suggestions in this regard in the P2P-RPL specs beyond what the draft already says - the draft does suggest two sample methods: 1) select routes on FCFS basis 2) choose the best routes discovered over an interval.

---

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

inline,

-----Message d'origine-----
De : Mukul Goyal [mailto:[email-masked]] 
Envoyé : lundi 9 avril 2012 00:13
À : C Chauvenet
Cc : [email-masked]; [email-masked]
Objet : Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?

Hi Cedric

Please see inline.

Thanks
Mukul

 Discussion:

 [Cedric]

[Cedric2]

[Cedric3]
Yes good point. So I think the draft is generic enough regarding this parameter.

---

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

Resolution:
-----------------
 This is purely a local decision at the target. The draft  should not make any recommendation in this regard.

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

 [Cedric]

[Cedric2]

[Cedric3]

---

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

Changes (by jpv@…):

 * component:  applicability-ami => p2p-rpl

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

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

---

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

Changes (by jpv@…):

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

Comment:

 Resolution:
 -----------------
 This is purely a local decision at the target. The draft  should not make
 any recommendation in this regard.

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

 [Cedric]

 [Cedric2]
 OK, let's say it is up to the implementation and should be deterinied
 according to the specific set of metric/contraints in use.
 A target from a DAG based on a latency metric could wait just a few ms
 after receiving the first RDO  and select the best path according to the
 latency metric.
 A target from a DAG based on a energy metric could wait much more time
 after receiving the first RDO to be sure to use an energy efficient path,
 that could be discovered after some time, because of duty cycling nodes
 for instance.

 [Mukul2] Choosing the wait time on the basis of specific metrics being
 used in route discovery could be one option. However, when an origin wants
 to discover low latency routes, it does not necessarily mean that the
 latency of the route discovery process has to be low as well. :) So, in
 general, I think that the time a target waits before sending DROs (which
 determines to some extent the latency of the route discovery process) is
 independent of the specific metrics/constraints being used in route
 discovery process. As I said before, I think the target should decide for
 itself how much should it wait before sending DRO(s). It may not be wise
 to make any suggestions in this regard in the P2P-RPL specs beyond what
 the draft already says - the draft does suggest two sample methods: 1)
 select routes on FCFS basis 2) choose the best routes discovered over an
 interval.

 [Cedric3]
 Yes good point. So I think the draft is generic enough regarding this
 parameter.

-- 
-----------------------------------+----------------------
 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/96#comment:2>
roll <http://tools.ietf.org/wg/roll/>