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

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Fri, 13 April 2012 13:34 UTC

Return-Path: <trac+roll@trac.tools.ietf.org>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E82121F87A9 for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 06:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.485
X-Spam-Level:
X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QcoXM2xVG0LK for <roll@ietfa.amsl.com>; Fri, 13 Apr 2012 06:33:59 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BD97121F87B6 for <roll@ietf.org>; Fri, 13 Apr 2012 06:33:59 -0700 (PDT)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+roll@trac.tools.ietf.org>) id 1SIgdS-0008Nj-TT; Fri, 13 Apr 2012 09:33:58 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: roll issue tracker <trac+roll@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: mukul@UWM.EDU, jpv@cisco.com
X-Trac-Project: roll
Date: Fri, 13 Apr 2012 13:33:58 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/96#comment:2
Message-ID: <070.699db57ed1dee8d2a22b5d9efba94741@trac.tools.ietf.org>
References: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-Trac-Ticket-ID: 96
In-Reply-To: <055.f7a4657c0332f6393eb09f355b0158eb@trac.tools.ietf.org>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org
X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Cc: roll@ietf.org
Subject: Re: [Roll] [roll] #96: Can the draft recommend how much to wait before a target selects routes to be sent back in DROs?
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Reply-To: roll@ietf.org
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 13:34:00 -0000

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

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:
 -----------------
 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.

 [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/>