[Roll] Closure text for ticket #96

Mukul Goyal <mukul@uwm.edu> Wed, 11 April 2012 23:21 UTC

Return-Path: <prvs=441eb7f02=mukul@uwm.edu>
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 3590311E8109 for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 16:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fQJBjWVu68dE for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 16:21:20 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 711E211E8102 for <roll@ietf.org>; Wed, 11 Apr 2012 16:21:19 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAAYRhk9/AAAB/2dsb2JhbABEhWa3DSNWNQINGQJZBoghp3uJe4kJgS+PLoEYBIhajRKQNoMF
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id B51C5E6A8D; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-y0nSbdvCYq; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 80904E6A72; Wed, 11 Apr 2012 18:18:55 -0500 (CDT)
Date: Wed, 11 Apr 2012 18:18:55 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: C Chauvenet <c.chauvenet@watteco.com>
Message-ID: <1197036182.1902018.1334186335455.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D0221AE9F@AMXPRD0510MB390.eurprd05.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [129.89.7.91]
X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - IE8 (Win)/6.0.13_GA_2918)
X-Authenticated-User: mukul@uwm.edu
Cc: roll@ietf.org
Subject: [Roll] Closure text for ticket #96
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 11 Apr 2012 23:21:25 -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.

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