[Roll] Closure text for ticket #86

Mukul Goyal <mukul@uwm.edu> Wed, 11 April 2012 02:51 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 037E321F8692 for <roll@ietfa.amsl.com>; Tue, 10 Apr 2012 19:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.108
X-Spam-Level:
X-Spam-Status: No, score=-5.108 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 FldjpWa3uQMN for <roll@ietfa.amsl.com>; Tue, 10 Apr 2012 19:51:29 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2951F21F8688 for <roll@ietf.org>; Tue, 10 Apr 2012 19:51:27 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApwEAHrwhE9/AAAB/2dsb2JhbABDhXO2byNPBzUCDRkCWQaIIatqihCBIYEviW+FCIEYBIhajRKQNoMFgTYBFg
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 623FE12E3BE; Tue, 10 Apr 2012 21:51:26 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu
Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpoN7sU3QAQK; Tue, 10 Apr 2012 21:51:25 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D6B6812E3BD; Tue, 10 Apr 2012 21:51:25 -0500 (CDT)
Date: Tue, 10 Apr 2012 21:51:25 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: JP Vasseur <jpv@cisco.com>
Message-ID: <723690941.1887908.1334112685750.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <2058618921.1887387.1334108747023.JavaMail.root@mail17.pantherlink.uwm.edu>
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 <roll@ietf.org>, Michael Richardson <mcr@sandelman.ca>
Subject: [Roll] Closure text for ticket #86
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 02:51:31 -0000

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