[6tsch] R: simulation for random schedule allocation

"Alfredo Grieco" <alfredo.grieco@gmail.com> Thu, 27 June 2013 08:41 UTC

Return-Path: <alfredo.grieco@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEED21F9635 for <6tsch@ietfa.amsl.com>; Thu, 27 Jun 2013 01:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Se8DW1AL+JFa for <6tsch@ietfa.amsl.com>; Thu, 27 Jun 2013 01:41:36 -0700 (PDT)
Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E5DBF21F9A90 for <6tsch@ietf.org>; Thu, 27 Jun 2013 01:41:27 -0700 (PDT)
Received: by mail-bk0-f46.google.com with SMTP id na10so158778bkb.33 for <6tsch@ietf.org>; Thu, 27 Jun 2013 01:41:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=wE7OUmEqpMjQM6PuSKB4A+FNdZU05IpROaAt7Aen7F0=; b=0tCb//rhUI2rxgoLrr0QCl+epwKH1WEygQeARH/TuFyaeKqzxbJI6LeOeP86QUBfsx 61cX0iVEbzG90GJCzkHXKster3GaG/i8hJsYVpukIe7cx0lVcIrUcVM9/n2DgO8WabaO +9l3gL+mIpeVPBcF6+6CaBjZhk+dUaTwkyR1wu/95kc6cvutyVvU47stmnHPLv/fgI9M 2jrodUFF8VvGScOf4cP5HB21c1R2QZVuFff1jn6U1z6GQBPit3zFYLskNXWbaoIUE8y6 84DNxiQnKy5RCuFloazmZmYYNjOYTVMsAE/lGlkXQhVJyNZUr/2WB5kFJjBhf5+fWaKN vdDg==
X-Received: by 10.205.136.68 with SMTP id ij4mr1055608bkc.109.1372322486962; Thu, 27 Jun 2013 01:41:26 -0700 (PDT)
Received: from GriecoPC (deecom23.poliba.it. [193.204.59.55]) by mx.google.com with ESMTPSA id oe10sm584993bkb.1.2013.06.27.01.41.25 for <6tsch@ietf.org> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 27 Jun 2013 01:41:26 -0700 (PDT)
From: "Alfredo Grieco" <alfredo.grieco@gmail.com>
To: <6tsch@ietf.org>
References: <CALEMV4b27w3=hCkovP1JpQwQnN_jcu98hGPtjT349LhFBPb0XQ@mail.gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B12D2691A@tgxml338.toshiba.local> <CALEMV4Zbqjd66Msot7cr45oFtG60zFFgUkAfPMLCq17zYR+ejw@mail.gmail.com> <674F70E5F2BE564CB06B6901FD3DD78B12D26BDD@tgxml338.toshiba.local>, <CALEMV4a4X4+8k5o1o7HVpjL8xdQ1WiwprP1HD6Vzv-8p4iceKw@mail.gmail.com> <F085911F642A6847987ADA23E611780D1857A510@hoshi.uni.lux>
In-Reply-To: <F085911F642A6847987ADA23E611780D1857A510@hoshi.uni.lux>
Date: Thu, 27 Jun 2013 10:41:23 +0200
Message-ID: <51cbfab6.0a05cd0a.13c9.29bb@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOcdRxiYJgW1s/a0CByo7Q09Y7LZlH7Y2AgAAi7YCAAGs9AIAAGVSAgACazEuAAA58EA==
Content-Language: en-us
Subject: [6tsch] R: simulation for random schedule allocation
X-BeenThere: 6tsch@ietf.org
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Jun 2013 08:41:37 -0000

Hi all,

I guess that the point here is that the simulations of Xavi clearly
highlight that as the load increases the collision probability increases
too. I developed some Binomial expressions for a single hop network and
results are very similar to the ones of Xavi.

Of course the scenarios can be made more and more realistic (as Maria Rita
and Yoshihiro are suggesting) but the indication of these preliminary
outcomes seem to be that nodes with a low rank will experience a pretty high
collision probability (due to a higher load) if they choose cells according
to a pure random technique whereas nodes with a high rank can safely use a
random approach without any problem.

Again, it seems that the rank of a node has to play some role in the
mechanism used to select cells in order to avoid performance degradation. I
believe that this kind of indication should be provided in some of the
drafts in progress. 

Cheers

Alfredo

Da: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] Per conto di
Maria Rita PALATTELLA
Inviato: Thursday, June 27, 2013 10:08 AM
A: xvilajosana@eecs.berkeley.edu; yoshihiro.ohba@toshiba.co.jp
Cc: 6tsch@ietf.org
Oggetto: Re: [6tsch] simulation for random schedule allocation

Hello Xavi,
first of all many thanks for having built the code and run this first set of
simulations for the WG.
I have some questions about the simulations. Please, feel free to ignore my
comments, if they are inappropriate.

1)"Each node requests a link to each of its neighbors."
Is it really what we want? In my point of view, each node will ask a set of
links (i.e., cells) according to the paths along which it will transmit its
own traffic, and forwards the traffic received by other neighbors. In other
words, the number of requested cells per node should be less than what we
are simulating right now. For sure, in the actual scenario, we have higher
probability of collision.

2) " the network is represented by a boolean square matrix of
num_nodes*num_nodes. Two nodes are neighbours if the cell for that two nodes
(indexed by node ids) is true. if X is neighbour of Y the cells (x,y) and
(y,x) will be true."
This way of representing the network can create somehow a bit of confusion
with the TSCH schedule representation, where we have (timeslot,
channeloffset) cells.
Can't we find a different way for representing the network, and defying the
set of neighbors? Moreover, this point 2) is linked with point 1) I guess,
i.e., assuming each node will request a link to each of its neighbors.

3) "Topology: Random, where each node requests a random number of neighbours
between 2 and 10.”
Even though I am in favor of having a random topology, and a random number
of neighbors, maybe, for having a preliminary idea of the network behavior,
we could run a set of simulations, where we fix the number of neighbors
(i.e., having it constant). Basically, my suggestion is to keep some
parameters constant, while we change others, in order to see how each of
them impact the cells allocation.

Thank you!
Maria Rita

 
________________________________________
From: 6tsch-bounces@ietf.org [6tsch-bounces@ietf.org] on behalf of Xavier
Vilajosana Guillen [xvilajosana@eecs.berkeley.edu]
Sent: Thursday, June 27, 2013 2:27 AM
To: yoshihiro.ohba@toshiba.co.jp
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] simulation for random schedule allocation
Hi Yoshihiro,
the network is represented by a boolean square matrix of
num_nodes*num_nodes. Two nodes are neighbours if the cell for that two nodes
(indexed by node ids) is true. if X is neighbour of Y the cells (x,y) and
(y,x) will be true. 
When a node requests a link it always requests a TX link, the counter part
sets it to RX links so a link allocation happens at both sides. In a
particular node Number of allocated links is the accumulation of both TX and
RX allocated in that node.
Regarding your question, if X requests a TX link to Y the schedule of X
allocates a TX link to Y and the schedule of Y allocates a RX link from X.
If Y requests a TX link to X, X allocates a RX link from Y.
A link is not allocated in either side if there is a collision, and then I
increment the collision counter.
The code is here in case someone wants to play. Sorry it is not very clean
but I will clean it as soon as I can. If someone modifies it or improves it,
feel free to commit your changes to the repository so the simulator becomes
better.

https://github.com/xvilajosana/6TSCH
hope this makes things clear.
regards,
X



Xavi

On Wed, Jun 26, 2013 at 3:56 PM, <yoshihiro.ohba@toshiba.co.jp> wrote:
Hi Xavi,
 
Thanks for your explanation.  I have better understanding now.  
 
I have one more question.
 
You mentioned “there might be more than one link to a neighbor”.   Say Node
X selected only one neighbor Node Y and requests one link to Node Y.  The
resulting number of links associated with Node X can be two (2) when Node Y
also selected Node X as its neighbor and requested one link to Node X.  Is
my understanding correct?
 
Yoshihiro Ohba
 
 
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
Xavier Vilajosana Guillen
Sent: Thursday, June 27, 2013 1:33 AM
To: ohba yoshihiro
Cc: 6tsch@ietf.org
Subject: Re: [6tsch] simulation for random schedule allocation
 
Hi Yoshihiro,
you are right, the formulation of the sentence is not correct. Should be:

“Topology: Random, where each node requests a random number of neighbours
between 2 and 10.”
this means that each node when created requests a number of neighbors
between 2 and 10, meaning that other nodes when are created also request
that number of neighbours and therefore a node can have more than 10
neighbours, because other nodes selected it as a neighbour. From the
simulation results I see that nodes have between 5 and 11 neighbours
usually.
However, from the numbers you point, 28 represents the number of allocated
links (number of allocated cells in the schedule) to its neighbours, there
might be more than one link to a neighbour in that case.
regards,
Xavi


Xavi
 
On Wed, Jun 26, 2013 at 7:28 AM, <yoshihiro.ohba@toshiba.co.jp> wrote:
Hi Xavi,
 
Thank you very much for the simulation.
 
I am trying to understand the simulation model from your description and the
result.
 
“Topology: Random, where each node has a random number of neighbors between
2 and 10.”
 
“
************************ requesting 1 links
Node,Allocated Links,Collisions,Percentage
0,28,0,0.0
“
 
In the above result, does Node 0 actually have 28 neighbors?
 
Regards,
Yoshihiro Ohba
 
From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf Of
Xavier Vilajosana Guillen
Sent: Wednesday, June 26, 2013 3:46 AM
To: 6tsch@ietf.org

Subject: [6tsch] simulation for random schedule allocation
 


Hi all,

I prepared a little simulation to see how random schedule allocation
behaves. (I have the code in Java in case someone is interested)

here there are some details (everything can be tuned in case someone wants
to point me to a special case)

Network: 50 nodes

Topology: Random, where each node has a random number of neighbors between 2
and 10.

Each node requests a link to each of its neighbors. This is done from 1 to
10 times (i.e 10 tests, the first requesting 1 link to each neighbour, the
second 2, etc.. up to 10 links to each of the neighbors, can be configured)

The slotframe is 101 slots and 16 channels.

The simulation prints statistics for the test (and the collisions if we are
interested.)
I used pseudo random generator from the java language assuming it provides
uniform or almost uniform distribution.
The allocation counter counts both the number of links allocated as tx and
the number of links allocated as rx due to a neighbour allocating a link to
the actual node. The percentage is the % of collisions w.r.t the allocated
links. 
Worst case is around 11% when allocating 10 links to each neighbour in that
50 node network.
I can play more on it but I wanted to share that initial results.
please see attached file for the results.
regards,
Xavi