Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

"Pascal Thubert (pthubert)" <> Thu, 10 March 2016 23:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C5D812DDF2 for <>; Thu, 10 Mar 2016 15:47:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wge-C-0L0TtH for <>; Thu, 10 Mar 2016 15:47:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CF47C12DCA9 for <>; Thu, 10 Mar 2016 15:46:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=9874; q=dns/txt; s=iport; t=1457653619; x=1458863219; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6qbkIAu07VSwRTjoWvO6chzbZFe5VQzAzhyjeoud+iE=; b=LGk6gjH1Fe1tVxX9kLr+N5b/zFJZzBx6duPo1+7QjAWcuGbS2yhTZPX7 XTG5Rq+fAo1Bf96J0aLQnoQL2QiDO9LEBBdPuP9s78Gyc6m2rmKrYYwDu O2U79m32xvS0SDZVX43A07GGLjQc1s9Yz5bg60ww96VYn6lHZengTVszB U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.24,317,1454976000"; d="scan'208,217"; a="84521203"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 Mar 2016 23:46:58 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u2ANkwwa007977 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 10 Mar 2016 23:46:58 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 10 Mar 2016 17:46:57 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Thu, 10 Mar 2016 17:46:58 -0600
From: "Pascal Thubert (pthubert)" <>
To: "Prof. Diego Dujovne" <>
Thread-Topic: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
Thread-Index: AQHReyQvwbBbqE4NSEOe/B8D7SbA2Z9TV/zx
Date: Thu, 10 Mar 2016 23:46:58 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_48716627C2D1417BBB8CBE7026A205D5ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
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: Thu, 10 Mar 2016 23:47:02 -0000

Correct Diego

And that's a desired effect so that a node gets a lot of bandwidth to complete its join. You better complete a few at a time then have hundreds half way through and none fully done.

We may actually reject a join if the queue is too long, exhausting=sleep well and come back in 10

Take care,


Le 11 mars 2016 ? 00:25, Prof. Diego Dujovne <<>> a ?crit :

          I was thinking of a worst-case condition: all neighbours are
willing to join. A limited pool would satisfy only a part of them, thus
putting the rest of the nodes in a join queue. Am I correct?


2016-03-04 7:55 GMT-03:00 Pascal Thubert (pthubert) <<>>:
Hello Diego:

One suggestion would be that when a node attempts to join, the parent immediately grants a set of cells for the join process from a limited pool (to avoid DDOS). These cells are to be released at the end of the join and are there to boost the bandwidth for that critical phase.



From: 6tisch [<>] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 3 mars 2016 17:12
Subject: [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot

Dear all,
            Although it was discussed, there is no specification
on the 6top behaviour at boot. The discussion point here is if the
6top messages shall be transmitted on minimal cells until
the slotframe 1 (SFR1) has been populated enough to support
the transactions.
          - The use of minimal is optional. In case minimal is used,
the decision on when to switch is out of scope?
          - In case minimal is not used, shall we specify another
mechanism to enable 6top to transmit messages?
                                             Diego Dujovne

Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones
Facultad de Ingenier?a UDP<>
(56 2) 676 8125

Acad?mico Escuela de Ingenier?a en Inform?tica y Telecomunicaciones
Facultad de Ingenier?a UDP<>
(56 2) 676 8125