Re: [6tsch] On the fly scheduling

Maria Rita PALATTELLA <> Fri, 04 October 2013 07:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8367421F963F for <>; Fri, 4 Oct 2013 00:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5d6pgFy2-NW3 for <>; Fri, 4 Oct 2013 00:19:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0061121F9AD8 for <>; Fri, 4 Oct 2013 00:19:00 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="4.90,1031,1371074400"; d="scan'208,217"; a="27030876"
Received: from unknown (HELO Travis.uni.lux) ([]) by with ESMTP; 04 Oct 2013 09:18:58 +0200
Received: from HOSHI.uni.lux ([fe80::499:a33:4e68:4af9]) by Travis.uni.lux ([fe80::653b:7b8e:4641:a750%10]) with mapi id 14.03.0158.001; Fri, 4 Oct 2013 09:18:57 +0200
From: Maria Rita PALATTELLA <>
To: Thomas Watteyne <>, 6TSCH <>
Thread-Topic: [6tsch] On the fly scheduling
Thread-Index: AQHOwCKrpPrMfeNaM0uqc9rueyxhVpni2+UAgAAGvgCAAD2gov//7dGAgAAu5gCAAAqmgIAA2b5g
Date: Fri, 4 Oct 2013 07:18:56 +0000
Message-ID: <F085911F642A6847987ADA23E611780D185A39B6@hoshi.uni.lux>
References: <> <> <> <F085911F642A6847987ADA23E611780D1859FA68@hoshi.uni.lux> <> <> <>
In-Reply-To: <>
Accept-Language: en-US, en-GB
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_F085911F642A6847987ADA23E611780D185A39B6hoshiunilux_"
MIME-Version: 1.0
Subject: Re: [6tsch] On the fly scheduling
X-Mailman-Version: 2.1.12
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, 04 Oct 2013 07:19:54 -0000

+1 for me too.

For sure, according to the specific requirements of the applications, different algorithms may be used for building the schedule. But the functionalities offers by 6top (i.e., collect statist. Info, send commands for scheduling cells) will be still the same (no matter which algorithm is used).

The statistics needed could change because different algorithms may use different input as parameters.  So, we will have to include a set of statistic information, or anyway, make sure it is possible to extend them.

Maria Rita

From: [] On Behalf Of Thomas Watteyne
Sent: Thursday, October 03, 2013 10:11 PM
Subject: Re: [6tsch] On the fly scheduling

That would indeed be clean.

On Thu, Oct 3, 2013 at 12:33 PM, Qin Wang <<>> wrote:
Hi all,

+1 for the proposal.

Regarding to how to approach, I agree with Thomas. There is an entity running on top of 6top, which reads queue information and other statistics information from 6top, sends instruction like create/delete softcells to 6top. I think we can use the design methodology of Objective Function in RPL, i.e. define the statistics information and the interface to/from 6top, and leave the specific algorithm open.

What do you think?


On Fri, Oct 4, 2013 at 12:45 AM, Thomas Watteyne <<>> wrote:
+1 for the proposal.

I believe it could be a very simple and powerful approach. Diego, would you agree that this can be considered a distributed mechanism sitting on top of 6top?

That is, 6top provides:

  *   commands to modify the number of soft cells in a bundle
  *   commands to retrieve usage statistics of the cells/bundles
The way I see it, your proposal consists of an algorithm which feeds from the usage statistics and triggers changes in the number of soft cells in a bundle. Correct?

The questions to answer for now is whether 6top provides the right statistics.

Maria Rita, one big difference with TASA is that OTF scheduling is distributed.


On Thu, Oct 3, 2013 at 9:11 AM, Maria Rita PALATTELLA <<>> wrote:
Diego,( all)

what you are suggesting (i.e., reserve cells based on queue size, delay) is actually the main idea behind TASA (Traffic Aware Scheduling Algorithm).

TASA builds the schedule based on the local (number of pkt generated by the node) and global queue level ( i.e., local + pkt to be forwarded, generated by children). It gives priority to nodes with longer queues and it aims to reduce the latency for delivering the pkt. At the same time while building the schedule it minimizes the number of scheduled cells in order to reduce the network duty cycle.
TASA is centralized and thus it assumes that the PCE has all the info needed for setting up the schedule. in other words, it knows the traffic generated by each nodes, and the paths followed by each pkt.
With a "on the fly solution", we will not need to know all this info a priori. but we will use 6top monitoring functions and the control flows message for scheduling the cells.

Btw, I agree with all the points raised up by Xavi.  We will have to address his questions.

And I support Pascal's suggestions about how to deal with bundle.

Maria Rita

From:<> [<>] on behalf of Pascal Thubert (pthubert) [<>]
Sent: Thursday, October 03, 2013 4:09 PM
To:<>; Prof. Diego Dujovne

Subject: Re: [6tsch] On the fly scheduling

+1 too.

I think that the queue size matters at enqueue but the latency is really what we care for at dequeue, that is how long did this device keep this message in queue (even if we are far from
buffer bloat conditions in such a device). If one of the 2 conditions (size at enqueue, latency at dequeue) is reached then the bundle should be increased.

I agree with Xavi that we want to avoid changing the bundle size all the time. We discussed that with Qin and others earlier on the ML. One way of increasing the bundle dynamically at a very low cost (not even a hysteresis)  is to have it large amount of cells from the start but used like 10% by default (xmit/listen happens only once in 10 time slots). A bit in the frame indicates whether the next (normally unused) slot will indeed be used. The bit can be present in the data and acked in the ack. This can also implicitly be triggered for retries.

Please keep us tuned!


PS Note that Cisco has IPR on chaining time slots and flagging whether the next is used or not. We already declared our IPR against the architecture draft and provided terms.


From:<> [<>] On Behalf Of Xavier Vilajosana Guillen
Sent: jeudi 3 octobre 2013 15:46
To: Prof. Diego Dujovne
Subject: Re: [6tsch] On the fly scheduling


it seems to a me a very interesting idea to explore. Maybe we can start putting some rules of this mechanism on the table and prepare a simulation. I am completely in with that idea.
Some questions arise:
1-how fast do you react to changes on the queue size to avoid hysteresis -- i.e how do you maintain certain stability in the schedule (so you don't start installing and removing links very often)
2-how you map queue size (only one or if more than one queue) to actual link requirements
3-how you recover from link collisions in case of multiple nodes schedule the same cells.
4-how to decide to who (what neighbor) install more links according to queue size?


On Thu, Oct 3, 2013 at 3:23 AM, Prof. Diego Dujovne <<>> wrote:
Dear all,
            I've been looking into the idea of "on the fly scheduling",
presented on the Sept 27th webex call as "on-the-fly decentralized reservation".
The basic mechanism would be based on analysing the queue size
on a node and dynamically adapt the number of reserved
cells to satisfy queue size, delay and/or power
consumption thresholds.
            This mechanism would work inside 6top, between pairs of nodes.
As a first approach, it would be based on the minimal draft.
What do you think on this starting point?
I (gladly) receive comments to add or modify this proposal.


Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP<>
(56 2) 676 8125<tel:%2856%202%29%20676%208125>
6tsch mailing list<>

6tsch mailing list<>

6tsch mailing list<>