Re: [6tisch] SF0 - Cell reclamation by RPL parent

"Prof. Diego Dujovne" <> Fri, 11 March 2016 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 680D612D68C for <>; Fri, 11 Mar 2016 06:09:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0YGsyP2o5nLY for <>; Fri, 11 Mar 2016 06:09:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 456EC12D6FE for <>; Fri, 11 Mar 2016 06:09:39 -0800 (PST)
Received: by with SMTP id l68so19097763wml.1 for <>; Fri, 11 Mar 2016 06:09:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/VTc7PI6M5okqAgKCCpgaoHrW8Rg0KiY1cms+UZW5uo=; b=g+O8w3RWRwqKOh4lZB+t+vrSX4BQ+EBjPYSWagMCs5/hMx77zmD3+pPTu5EHI6RdGC UFxk2A6Aw2XDMkbUYpMXvPDFbY462/olkpSq8uMtfPcjGh5UAo0IfFdSv5M7ctrKGHhd GHWduyxX2peibzJAUv71d4Kp+txAsNUwdXX2jPzMqlHsC/R6tcb/mT9mKwduOEZkeLEi 7ZnsXpTfBHLSm6tEfSv4sEK6pIH6bm+2Kq9WDASGvyrhorgEIGOc2bzRp3TqLC9X1w7a CJAFPPEbofShqYWsIalI1c0Bu/cXxrBg766R81VWB2jkbEl74p6O0kLCVtp0cNtwJbnI BYeQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/VTc7PI6M5okqAgKCCpgaoHrW8Rg0KiY1cms+UZW5uo=; b=W+S+4+tdbCVCCJ9Tbq1M63sVltRb9TxWN/oS19SeBmFacZrgcUK5jnIHpUmi1f+QhM MhptKL5d06wNLEl6UekRoBYebFk4RVGk4GBFZWNz8mmw7lS3aELO7VI9HyMwtThh1m8R 3agpZaeELTNtuEJS4EAtLGW++fqSKDayXzHeiK8Zoj9h0Sk3uzVrcvJHSonyYgYIQGTi 7HZ3n9sKc2IUqvgiTWmGatiZHwbXRTCYnKgTmQaCmgJ2TewzG5v4wujaKz2ocxD5vCGI KmEB6kpw8cdRRjbkywXt6fxxJognFlCbbgsfalduQ2pv9PLlGXE6MmM62cv+iXAXafVU TLig==
X-Gm-Message-State: AD7BkJKAaomThHTX90JYlWMH5PPzLNiPxo4dRZVlLVuJahG3IDjKRmv0RlhprKVABPX/Y+y7rrYr9lLSYZccAQ==
MIME-Version: 1.0
X-Received: by with SMTP id y186mr2988097wmc.79.1457705377568; Fri, 11 Mar 2016 06:09:37 -0800 (PST)
Received: by with HTTP; Fri, 11 Mar 2016 06:09:37 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 11 Mar 2016 11:09:37 -0300
Message-ID: <>
From: "Prof. Diego Dujovne" <>
To: "S.V.R.Anand" <>
Content-Type: multipart/alternative; boundary="001a1141d0aa37a922052dc67b39"
Archived-At: <>
Cc: "" <>
Subject: Re: [6tisch] SF0 - Cell reclamation by RPL parent
X-Mailman-Version: 2.1.17
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Mar 2016 14:09:48 -0000

           Let me comment inline below.


2016-03-07 7:36 GMT-03:00 S.V.R.Anand <>:

> 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.
I was thinking on the neighbour list management. If a neighbour is deleted,
all the cells
belonging to the link with that neighbour shall be deleted too. Is there a
specification on
which entity maintains the neighbour list?

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

Bandwidth requests are managed by SFs; an SF running on a Parent can
a deletion event as needed. The starving applications on the top layer
react accordingly. The problem here is that the SFs react given certain
and events, but there is no current connection with other modules which may
reclaim cells.
This raises another point: The cell list should be kept and maintained at
6P level, or at the SF? Do we allow for multiple SFs on the same node?
Do we allow only different SFs in a per-neighbour basis (so each link is
by only one SF)?

> - 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
> parents down the DODAG. Currently, there is no mechanism defined to address
> this problem.
> I suppose the above text extends beyond SF0.

As far as I know, we are using chunks allocated to the RPL Parents by the
PCE to
schedule cells requested by SFs. The main assumption here is that the PCE
distribute chunks among the RPL Parents and not reclaim them back. However,
it is only an assumption. As I noticed above, cell list maintenance should
be transferred
to 6P if another module can add/delete cells concurrently.

> 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 ?
My question here is: Who is going to send this message? RPL? PCE through
Can we leave this to Chunk negotiation, which is currently out of scope of
this draft?

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

Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
(56 2) 676 8125