[6tisch] SF0 - Cell reclamation by RPL parent
"S.V.R.Anand" <anand@ece.iisc.ernet.in> Mon, 07 March 2016 10:37 UTC
Return-Path: <anand@ece.iisc.ernet.in>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75091B3E5A for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 02:37:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.792
X-Spam-Level: *
X-Spam-Status: No, score=1.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkYSzVbdnK8U for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 02:37:09 -0800 (PST)
Received: from relay.iisc.ernet.in (relay.iisc.ernet.in [203.200.35.70]) by ietfa.amsl.com (Postfix) with SMTP id F40F51B3E59 for <6tisch@ietf.org>; Mon, 7 Mar 2016 02:37:08 -0800 (PST)
Received: from ece.iisc.ernet.in (mail.ece.iisc.ernet.in [10.32.1.10]) by relay.iisc.ernet.in (Postfix) with ESMTP id 70031AE18B5; Mon, 7 Mar 2016 16:05:02 +0530 (IST)
Received: from [10.32.14.72] ([10.32.14.72]) by ece.iisc.ernet.in (8.14.7/8.14.7) with ESMTP id u27Ab6Fw010387; Mon, 7 Mar 2016 16:07:09 +0530
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
From: "S.V.R.Anand" <anand@ece.iisc.ernet.in>
Message-ID: <56DD59C8.20403@ece.iisc.ernet.in>
Date: Mon, 07 Mar 2016 16:06:56 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-IISc-MailScanner-Information: Please contact nethelp@serc.iisc.in for more information
X-IISc-MailScanner-ID: 70031AE18B5.A36D2
X-IISc-MailScanner: Found to be clean
X-IISc-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.891, required 6.5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90, NO_RDNS2 0.01, RP_MATCHES_RCVD -0.00)
X-IISc-MailScanner-From: anand@ece.iisc.ernet.in
MailScanner-NULL-Check: 1457951703.76044@ACe8krHqGPkw6btds68B6A
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/sfM4P7bA5ixLFKvJuhuG4778IUI>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: [6tisch] SF0 - Cell reclamation by RPL parent
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Mar 2016 10:37:13 -0000
Hi Diego and others, Since we are discussing about the message transactions in SF0, this mail is with respect to the RPL parent, the cell donor. There are situations where the RPL parent might want to apply a cell reclamation and, depending on the context, a reallocation policy dynamically. This results in one or more cells that have been given to its children are reclaimed by the RPL parent due to various reasons as below. - The child node is out of the network, or child and parent cannot reach each other, after the 6P add cell transaction is complete, thereby delete cell operation is not being transacted. Cell reclamation helps in "cell garbage" collection. - As add cell requests arrive asynchronously from its children, an RPL parent implementing certain fairness objective might re-appropriate the cells that have already alloted its children, especially during a resource crunch. - Referring to the following text in 4.2.5 of the 6tisch architecture document, "...Note that a PCE is expected to have precedence in the allocation, so that an RPL parent would only be able to obtain portions that are not in-use by the PCE." It may be that, an RPL parent might have to relinquish its own cells if needed by PCE any time. In such a scenario, the RPL parent may be forced to reclaim the cells given to its children. While the first case is relatively less complex, the latter two cases are problematic as these cases can lead to (i) potential race conditions, say between PCE and SF0 operations, and (ii) a cascading effect across several RPL parents down the DODAG. Currently, there is no mechanism defined to address this problem. I suppose the above text extends beyond SF0. In light of the above use cases and the associated problems, do you think it is a good idea to include an appropriate message in SF0 for reclaiming the cells by the RPL parent ? or are we inviting new set of problems by doing so ? Will be happy to receive your inputs. Anand -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
- [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand
- Re: [6tisch] SF0 - Cell reclamation by RPL parent Thomas Watteyne
- Re: [6tisch] SF0 - Cell reclamation by RPL parent Prof. Diego Dujovne
- Re: [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand
- Re: [6tisch] SF0 - Cell reclamation by RPL parent S.V.R.Anand