Re: [Roll] [roll] #86: G flag: do we need that text?

"roll issue tracker" <trac+roll@trac.tools.ietf.org> Wed, 11 April 2012 14:16 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 4BC3E21F8584 for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 07:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.475
X-Spam-Level:
X-Spam-Status: No, score=-101.475 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 S6Exx2AMzwjt for <roll@ietfa.amsl.com>; Wed, 11 Apr 2012 07:16:10 -0700 (PDT)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD0A21F8582 for <roll@ietf.org>; Wed, 11 Apr 2012 07:16:09 -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 1SHyL4-0001TP-Nj; Wed, 11 Apr 2012 10:16:03 -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: Wed, 11 Apr 2012 14:16:01 -0000
X-URL: http://tools.ietf.org/wg/roll/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/86#comment:2
Message-ID: <070.9560a9d9aa6ca2442092da51eb376ae2@trac.tools.ietf.org>
References: <055.a0f55ceefb3864b4fcd8d89b549d387c@trac.tools.ietf.org>
X-Trac-Ticket-ID: 86
In-Reply-To: <055.a0f55ceefb3864b4fcd8d89b549d387c@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] #86: G flag: do we need that text?
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: Wed, 11 Apr 2012 14:16:11 -0000

#86: G flag: do we need that text?

Changes (by jpv@…):

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


Comment:

 #86: G flag: do we need that text?

 Problem
 ------------------------------
 Disagreement on the meaning of 'G' bit and imposed setting to 0;

 Proposed resolution
 ---------------------------
 Add the following text to the draft:

 "The origin sets the G flag to indicate the relative importance of the
 route discovery it is initiating. The G flag is set to one if this
 particular route discovery is more important from application's
 perspective than some other route discovery. In other words, the origin
 sets the G flag to one if this particular route discovery helps meet the
 application defined goal \cite{rpl}. Thus, the G flag setting helps an
 intermediate router choose which route discoveries to participate in if it
 cannot participate in all route discoveries. An intermediate router SHOULD
 participate in route discoveries with G flag set to one (in preference to
 ones with G flag set to zero)."

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

 [Pascal]
 " Grounded (G) Flag: MUST be set to zero since this DAG is temporary in
 nature, is created solely for the purpose of P2P-RPL route discovery and
 MUST NOT be used for packet routing."

 On the contrary I'd set it to 1. The goal -being to reach the origin- is
 actually achieved by this DAG.

 [Mukul]
 Actually, the DAG is temporary in nature and vanishes after a short
 while. Even when it exists, it must/should not be used for routing
 packets back to the origin. So, I think the Grounded flag should be
 zero.

 [Pascal2] Please revisit RFC 6650 page 12.
 G means that a goal is achieved. So first you define the goal and then
 the bit becomes obvious. What's your goal?
 Can there be P2P DAGs that achieve the goal and others that make sense
 to build and yet do not achieve the goal?
 If you accept that your operation can actually depend on OF logic, then
 the setting of the goal influences that logic.
 By forcing a value to the goal in the PTP spec, we actually limit the
 applicability of the draft.
 Maybe you can define a default goal and a default setting. But do not
 MUST that it is set to 0...

 [Mukul2]
 When a node joins a temporary P2P DAG, it does not get any additional
 routing information. The DAG is going to disappear after some time,
 should not be used for routing while it exists and which nodes end up
 being on the discovered route is not known until the DRO message comes
 back. So, I think, by default, the G flag has to be zero. However, if
 the setting of G flag may affect how an intermediate node may calculate
 its rank (as per the OF being used), the origin should have the
 flexibility of setting the flag to 1. So, I could modify the text to say
 that "the origin sets the G flag based on its perception of how the
 flag's value would affect the rank calculation under the OF being used.
 By default, the G flag is set to zero given the temporary nature of the
 DAG being created."

 [Pascal3] Why do you feel the need to add anything above what RFC 6550
 says? I do not see any benefit or additional clarity from doing this.

 [Mukul3] RFC 6550 is actually kind of confusing in this regard. On page
 9, it says

 "A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data)."

 This seems to associate the goal with both OF and reachability to
 certain hosts. Later invocations of the term "goal" seem to refer just
 to the connectivity aspect, e.g., on page 18 RFC 6550 says

 "A grounded DODAG offers connectivity to hosts that are
   required for satisfying the application-defined goal."

 So, my understanding so far was that the "goal" defines connectivity to
 a certain hosts. The relation to objective function is not clear at all
 (if one restricts oneself to reading RFC 6550). The temporary DAGs
 created in P2P-RPL route discovery provide no connectivity whatsoever to
 the joining nodes. So, the only reason to set the G flag to 1 would be
 to allow correct use of an OF. So, I think P2P-RPL spec should use the
 text I offered above (and repeat below):

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 What do you think?

 [Pascal4] If you think this adds value, I will not oppose. Let's keep
 that as the proposed resolution

 [Mukul4] Sounds good.

 Proposed resolution text:

 "The origin sets the G flag based on its perception of whether joining
 how the flag's value would affect the rank calculation under the OF
 being used. By default, the G flag is set to zero given the temporary
 nature of the DAG being created."

 [Richard5]
 I disagree with the proposed resolution.  It adds needless confusion.
 The G flag is 0 if and only if the DODAG is floating.
 There is no point to allowing floating DODAGs with a P2P-RDO option.  I
 suggest that the G bit be set to 1 and that routers be explicitly
 prohibited from creating floating DODAGs with a P2P-RDO option.

 [Mukul5]
 The G flag is 0 if and only if the DODAG is floating.

 I think that the G flag is 1 if and only if the DODAG is grounded. The
 temporary DAGs used in P2P-RPL are not grounded, they are temporary. I
 think that all transient/temporary DAGs are floating by their very nature.

 [Michael5]
 I think we need to determine what a grounded DODAG is.
 Does it mean that a node announcing such a thing is attached to the
 Internet? (In which case P2P usage should G=0)
 Or does it mean that a node is attached to the resource named in the DIO?
 (In which case origin P2P should G=1)


 [Phillip5]
 The text in 6550 is pretty clear:

   Goal: The Goal is an application-specific goal that is defined
         outside the scope of RPL.  Any node that roots a DODAG will
         need to know about this Goal to decide whether or not the Goal
         can be satisfied.  A typical Goal is to construct the DODAG
         according to a specific Objective Function and to keep
         connectivity to a set of hosts (e.g., to use an Objective
         Function that minimizes a metric and is connected to a specific
         database host to store the collected data).

   Grounded: A DODAG is grounded when the DODAG root can satisfy the
         Goal.

   Floating: A DODAG is floating if it is not grounded.  A floating
         DODAG is not expected to have the properties required to
         satisfy the goal.  It may, however, provide connectivity to
         other nodes within the DODAG.

 The common case of the Goal is "has connectivity to the Internet" but
 that's not the only case. I think given the Goal for P2P traffic, I agree
 with Pascal and Richard that it should be 1.


 [Pascal6]
 Floating vs. Grounded depends on the goal of the DODAG. I asked you and
 will ask again what is your goal?
 If the goal is to reach the root, then G is 1... If you want to signal
 something to the OF using the G bit, leave it  open.

 [Mukul6]
 If the goal is to reach the root, then G is 1...

 I have told you multiple times that joining a P2P-RPL DAG does not give
 any sort of connectivity to the node.

 [Pascal7]
 I think we disagree because of the definition of goal itself. The goal is
 an abstraction. Same goes for the term Objective in OF. RFC 6550 only
 gives examples of what G could be used for but that is not limiting.
 Certainly the abstraction may for instance mean that external nodes are
 reachable via the root. But it could be something else entirely. For
 instance it could designate a root that can aggregate data.

 In practice, G is used to favor a root that reaches the goal vs. one that
 does not. But that's senseless for local instances that have by definition
 a single root.

 So whatever you set it to does not make a difference for RFC 6550
 operations. I figure it could be used for signaling a "transient goal"
 information to an OF that could use it for a purpose I can't fathom.

 In any case, as I suggested earlier and as Richard also suggest now, G
 SHOULD probably be 1 by default but MAY be set otherwise.

 [Mukul7]
 Richard wants the flag to always be either 0 or 1. He prefers it to be
 always 1 but would settle for it being always zero.

 I think this is not a critical point. I am OK with whatever resolution you
 and Richard arrive at. Kindly provide me the resolution text I should put
 in the draft.

 [Pascal8]
 I suggest a sentence that says that:

 1) For a local instance there can be only one root and one DODAG. G bit
 cannot and is not used for DODAG selection within an instance.
 2) In a given deployment, a goal can be defined that some P2P DODAGs
 achieve and others do not. The roots that achieve that goal will set the G
 bit in their P2P DAGs.
 3) the default goal is to create connectivity between origin and target.
 So by default G should be set to 1.
 4) if an intermediate router does not have enough resources to participate
 to all DODAGs then it should favor DODAGs with the G bit on.

 The exact wording is yours...

 [Mukul8]
 1) For a local instance there can be only one root and one DODAG. G bit
 cannot and is not used for DODAG selection within an instance.

 The statement above seems to be at odds with following two statements

 2) In a given deployment, a goal can be defined that some P2P DODAGs
 achieve and others do not. The roots that achieve that goal will set the G
 bit in their P2P DAGs.
 3) the default goal is to create connectivity between origin and target.
 So by default G should be set to 1.

 As per statement 1, the G flag can never be 1 for P2P-RPL DAGs because
 they use local instance ids.
 As per statement 2/3, the G flag could be 1 and is 1 by default.

 I am OK with setting G flag to 1 always (as you, Richard and Phil seem to
 prefer) but I dont know how to reason this. Do we need to provide a reason
 at all?

 [Pascal9]
 Statement 1 does not say that at all. Can't fathom how you concluded
 that... Let me try to reword: There is only what DODAG for a given local
 instance so there cannot be a selection => G cannot be used for a
 selection that cannot happen.

 As per statement 2/3, the G flag could be 1 and is 1 by default.

 Yes. I added an item to help the device prioritize when it is asker to
 participate to many DODAGs (for many P2P flows that it happens to be on
 the path of). In that case, and if the device cannot particpater to all
 the P2P DODAGs, then the G bit could be use to decide which are the most
 important.

 If you define a default goal that the DODAG fills, then you set G to one.
 For instance, G could mean 'important stuff' like swithing a light on.
 You'd set it for switching lights but not for reporting the hygrometry of
 your orchids, which anyway will be retried in a half hour. As a result, if
 the 2 DAG formations collide, the light on will have precedence...

 [Mukul9]
 How about the following text:

 "The origin sets the G flag to indicate the relative importance of the
 route discovery it is initiating. The G flag is set to one if this
 particular route discovery is more important from application's
 perspective than some other route discovery. In other words, the origin
 sets the G flag to one if this particular route discovery helps meet the
 application defined goal \cite{rpl}. Thus, the G flag setting helps an
 intermediate router choose which route discoveries to participate in if it
 cannot participate in all route discoveries. An intermediate router SHOULD
 participate in route discoveries with G flag set to one (in preference to
 ones with G flag set to zero)."

 [Pascal10]
 As far as I'm concerned you've captured it and I'm happy with this text.

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