From nobody Mon May 1 14:22:04 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD9B12EB0D for <6tisch@ietfa.amsl.com>; Mon, 1 May 2017 14:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.009 X-Spam-Level: *** X-Spam-Status: No, score=3.009 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 j5d6LajSidmX for <6tisch@ietfa.amsl.com>; Mon, 1 May 2017 14:22:01 -0700 (PDT) Received: from sonic327-11.consmr.mail.ne1.yahoo.com (sonic327-11.consmr.mail.ne1.yahoo.com [66.163.188.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51D63129462 for <6tisch@ietf.org>; Mon, 1 May 2017 14:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1493673522; bh=gf9ILuk6LKMeK5ON/N25zvDyMJ86EuSiR14Ow9tQ+kc=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=ZLWtAa3SQmY67gmVbKEs1nYssyTnjqJXte9PLyazfgqHCr/DZozcN/7OCTjqXn6VIdJ/bWlUW76Bf+jYB7Vml8etVlbNlkM1LslyWxWc3QD+2MOGiiNtK/3ibdFWvy3VZFZFWh5OsM5bao/+xwXTRLpMRKWrfScZxTX8WOKy6GpWL744nTeKKLXVPmSa2vujvENUXLAmjE0fVkWLZszR3k8kewmJnf0tY1MVmE1NCDsfWEIixUwlLc2e6v+B8bywFMRF49WLFGZxQDOeyAq8ucXiITjlHpii6mECv03BIO+ZXUQh2WG1PkmB7v8+DKAUQ8LEx7muETHp4xmoTvMTOg== X-YMail-OSG: vRaSilkVM1mQO61.rgW8UKlPGZ0NmN4IFf1B5DmYsOjtmZOKJRpi0yFAqF8Fh93 dCC6_Clr3csjODYSTjdSO8FluXhrXXpgcGzcq8GiW9mDBJ09ze7RhhhlbJhGUzBq0MzDAXtMp2I. sIMFsVh8fzLfslVnKUTKiDrdxRWkD9a2FHDz3Nz__VPKmxZpdD8ZmEyymxcBdxEwy5rxBa8So3af uJaAlRaq6sB.iXOuOw_UgImedlFosnMHd0j5cYilKMDx7lXxDGQqYVEPTB0fcj.RDYsLsUktkAQ3 tdXwspraVoj3AOCqvE5zFfz7l6I.Vk9MOXsGWLqDZw5t7DCsEabGMphojoQtPxaV3b8WeyFDESi2 DgcEzltGgQD8u_qu.jvPqB.6DkuM2d9eJ6SsmewdmJGsD44tVi0b9_A2yBSvk.T6duoVdPr4GXN0 r0tqgNfpt.lddHvwxxcO3OlutbvfKTl4fzuBeZ9NaPG2hd3WRTbkWaSzpQ.R72HSZp1cb3mkR4no hrH._iEO7ieL497x0M.UHSetRHs.JIPvkes0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic327.consmr.mail.ne1.yahoo.com with HTTP; Mon, 1 May 2017 21:18:42 +0000 Date: Mon, 1 May 2017 21:16:39 +0000 (UTC) From: Qin Wang Reply-To: Qin Wang To: Tisch <6tisch@ietf.org> Message-ID: <1164799634.59709.1493673399955@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_59708_715287448.1493673399952" References: <1164799634.59709.1493673399955.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9539 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: [6tisch] Qin comments on SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 May 2017 21:22:03 -0000 ------=_Part_59708_715287448.1493673399952 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear authors, I read through SF0 (v4). The following is my comments. 2. Introduction=20 =C3=BC=C2=A0 =C2=A0=E2=80=9CThe Scheduling Algorithmcollects the cell alloc= ation/deletionrequests from the=C2=A0=C2=A0 neighbors and thenumber of cell= s which are currently under usage.=E2=80=9D =3D=3D> addition/deletion? allo= cation/deallocation? =C2=A04.=C2=A0SF0 Triggering Events =C3=BC=C2=A0 What is =E2=80=9Ccell allocation/deallocation process with the= neighbor=E2=80=9D?The trigger event is not clear. =C2=A05.=C2=A0SF0 Cell Estimation Algorithm =C3=BC=C2=A0 What is incoming cells and outgoing cells? Are they Rx cells a= nd Txcells, respectively? =C3=BC=C2=A0 What is =E2=80=9Cused cells=E2=80=9D? Is it same as =E2=80=9Cs= cheduled cells=E2=80=9D? If not, howto count used cells. =C2=A06.=C2=A0SF0 Allocation Policy =C3=BC=C2=A0 =E2=80=9CThe number of cells to be scheduled/deleted=E2=80=9D= =3D=3D> =E2=80=9Cadded/deleted=E2=80=9D? =C3=BC=C2=A0 =E2=80=9C3. If SCHEDULEDCELLS<=3DREQUIREDCELLS,add one or more= cells.=E2=80=9D =3D=3D> =E2=80=9C3. If SCHEDULEDCELLS =E2=80=9Cverifying that the slotoffset is not occupied and choose chan= nelOffset randomly for each cell=E2=80=9D =C2=A010.=C2=A0Node Behavior at Boot =C3=BC=C2=A0 Should the initialization of SCHEDULEDCELLS happen at boot? =C2=A0If you have any question regarding it, please feel free to contact me= . ThanksQin ------=_Part_59708_715287448.1493673399952 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear authors,=

I read through SF0 (v4). The fol= lowing is my comments.

2. Introduction
=C3=BC  =  =E2=80=9CThe Scheduling Algorithm collects the cell allocatio= n/deletion requests from the   neighbors and the number of cells which are currently under usage.=E2=80=9D =3D=3D> additi= on/deletion? allocation/deallocation?
&nb= sp;
4.  SF0 Triggering Events
=C3=BC  What is =E2=80=9Ccell allocation/deallocation = process with the neighbor=E2=80=9D? The trigger event is not clear.
=  
5.  SF0 Cell Estimation Algorithm
= =C3=BC  What is incoming cells and outgoing ce= lls? Are they Rx cells and Tx cells, respectively?
=C3=BC  What is =E2=80=9Cused cells=E2=80=9D? Is it sam= e as =E2=80=9Cscheduled cells=E2=80=9D? If not, how to count used cells.
 
=
6.  SF0 Allocation Policy
=C3=BC  =E2=80=9CThe number of cells to be scheduled/deleted=E2=80=9D =3D=3D> =E2=80=9Cadded/deleted=E2=80=9D?
=C3=BC  =E2=80=9C3. If SCHEDULED= CELLS<=3DREQUIREDCEL= LS, add one or more cells.=E2=80=9D =3D=3D> =E2=80=9C3. If SCHEDULEDCELLS<= ;REQUIREDCELLS, add one or more cells.=E2=80=9D
=C3=BC  When and how the initial value of SCHEDULEDC= ELLS will be set? The initialization should include not only setting SCHDULEDCELLS equal to SOFTH= RESH, but also adding SOFTHRESH cells into schedule for starting the state machin= e described in Fig.1.
 
7.  Rules for CellList<= /span>
=C3=BC=   =E2=80=9Cverifying that the slot offset and chann= el offset are not occupied and choose channelOffset randomly for each cell=E2=80=9D =3D=3D> =E2=80=9Cve= rifying that the slot offset is not occupied and choose channelOffset randomly for each cell=E2= =80=9D
=
 
10.  Node Behavior at Boot
=C3=BC  Should the initialization of SCHEDULEDCELLS ha= ppen at boot?
 
If you have any que= stion regarding it, please feel free to contact me.
Thanks
Qin
------=_Part_59708_715287448.1493673399952-- From nobody Wed May 3 06:10:21 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331D9124217 for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 TzN_7IhrjdPD for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:10:18 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D59B3129B1A for <6tisch@ietf.org>; Wed, 3 May 2017 06:07:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222304549" Received: from mail-yw0-f179.google.com ([209.85.161.179]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 15:07:18 +0200 Received: by mail-yw0-f179.google.com with SMTP id k11so84265849ywb.1 for <6tisch@ietf.org>; Wed, 03 May 2017 06:07:18 -0700 (PDT) X-Gm-Message-State: AN3rC/6HoPSGhjZDBuce9GGXFCk/IBoDuWCkQs0/WZWN/fZv6nmh76qc Za1Bxt7PYTIAGUjfGUNBThJu7iaH2g== X-Received: by 10.129.182.35 with SMTP id u35mr28837289ywh.314.1493816837637; Wed, 03 May 2017 06:07:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.67 with HTTP; Wed, 3 May 2017 06:06:57 -0700 (PDT) From: Remy Leone Date: Wed, 3 May 2017 15:06:57 +0200 X-Gmail-Original-Message-ID: Message-ID: To: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c1cc10af78f4c054e9e5530 Archived-At: Subject: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:10:20 -0000 --94eb2c1cc10af78f4c054e9e5530 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I've just pushed a first version of the 6TiSCH test description in the following repository: https://bitbucket.org/6tisch/td-6tisch I've used the content present in the test description document provided by ETSI during 6TiSCH plugtest events. Using a git-based workflow to change those test descriptions will I think help a great deal in the implementation of automated conformance and interoperability testing. Feel free to start opening pull requests with new tests or corrections of existing ones for the upcoming plugtest event. I would also appreciate if you could help me to distinguish between obsolete and relevant tests. From what I understood, some tests needs to be updated or removed. Also, it would help to change the reference those tests are based upon (minimal-11, minimal-14, minimal-15). Best regards R=C3=A9my --94eb2c1cc10af78f4c054e9e5530 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I've just pushed a first ver= sion of the 6TiSCH test description in the following repository:
=

I've use= d the content present in the test description document provided by ETSI dur= ing 6TiSCH plugtest events.

Using a git-based work= flow to change those test descriptions will I think help a great deal in th= e implementation of automated conformance and interoperability testing.

Feel free to start opening pull requests with new tes= ts or corrections of existing ones for the upcoming plugtest=C2=A0event.

I would also appreciate if you could help me to dist= inguish between obsolete and relevant tests. From what I understood, some t= ests needs to be updated or removed.=C2=A0
Also, it would help to= change the reference those tests are based upon (minimal-11, minimal-14, m= inimal-15).

Best regards

= R=C3=A9my
--94eb2c1cc10af78f4c054e9e5530-- From nobody Wed May 3 06:22:53 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0995D12943C for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 9atqnBHrtisr for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:22:50 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49C041294A8 for <6tisch@ietf.org>; Wed, 3 May 2017 06:18:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222307011" Received: from mail-ua0-f173.google.com ([209.85.217.173]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 15:18:56 +0200 Received: by mail-ua0-f173.google.com with SMTP id g49so41047473uaa.1 for <6tisch@ietf.org>; Wed, 03 May 2017 06:18:56 -0700 (PDT) X-Gm-Message-State: AN3rC/5SDPWKAkwCkWrRKUCXaxt9TUY5s+YSlqQVsEfcXLSAtiEMxUCr fEo7EEUVjYRx1gi3qzmTwdRADBWcbg== X-Received: by 10.176.70.98 with SMTP id z34mr16269988uab.3.1493817535024; Wed, 03 May 2017 06:18:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.92.17 with HTTP; Wed, 3 May 2017 06:18:34 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 3 May 2017 15:18:34 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Remy Leone Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=f403045e1af688d7a1054e9e7f51 Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:22:52 -0000 --f403045e1af688d7a1054e9e7f51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is great! I assume there are plenty of tools which will turn the yml files into e.g. a PDF version of the TD? On Wed, May 3, 2017 at 3:06 PM, Remy Leone wrote: > Hello, > > I've just pushed a first version of the 6TiSCH test description in the > following repository: > > https://bitbucket.org/6tisch/td-6tisch > > I've used the content present in the test description document provided b= y > ETSI during 6TiSCH plugtest events. > > Using a git-based workflow to change those test descriptions will I think > help a great deal in the implementation of automated conformance and > interoperability testing. > > Feel free to start opening pull requests with new tests or corrections of > existing ones for the upcoming plugtest event. > > I would also appreciate if you could help me to distinguish between > obsolete and relevant tests. From what I understood, some tests needs to = be > updated or removed. > Also, it would help to change the reference those tests are based upon > (minimal-11, minimal-14, minimal-15). > > Best regards > > R=C3=A9my > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403045e1af688d7a1054e9e7f51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is great! I assume there are plenty of tools which wi= ll turn the yml files into e.g. a PDF version of the TD?

On Wed, May 3, 2017 at 3:06 PM= , Remy Leone <remy.leone@inria.fr> wrote:
Hello,

I've just = pushed a first version of the 6TiSCH test description in the following repo= sitory:


I've used the content present in the test = description document provided by ETSI during 6TiSCH plugtest events.
<= div>
Using a git-based workflow to change those test descript= ions will I think help a great deal in the implementation of automated conf= ormance and interoperability testing.

Feel free to= start opening pull requests with new tests or corrections of existing ones= for the upcoming plugtest=C2=A0event.

I would als= o appreciate if you could help me to distinguish between obsolete and relev= ant tests. From what I understood, some tests needs to be updated or remove= d.=C2=A0
Also, it would help to change the reference those tests = are based upon (minimal-11, minimal-14, minimal-15).

Best regards

R=C3=A9my

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
_______________________________________

=
Thomas W= atteyne, PhD
Research Scientist & Innovator, Inria
Sr Networkin= g Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN

______________________= _________________
--f403045e1af688d7a1054e9e7f51-- From nobody Wed May 3 06:26:27 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752B4129442 for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 jPNG8DINMPWY for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 06:26:24 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 037DA129B5D for <6tisch@ietf.org>; Wed, 3 May 2017 06:22:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="271503895" Received: from mail-yw0-f174.google.com ([209.85.161.174]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 15:22:10 +0200 Received: by mail-yw0-f174.google.com with SMTP id k11so84490198ywb.1 for <6tisch@ietf.org>; Wed, 03 May 2017 06:22:10 -0700 (PDT) X-Gm-Message-State: AN3rC/76GiYUU2HarUIsqKaHiFAQVUXgREiEhlZC/iSZmg55vnBqHvhl ExziD9iayJly/6gaBQWi1V09kr1yHA== X-Received: by 10.129.182.35 with SMTP id u35mr28910307ywh.314.1493817729295; Wed, 03 May 2017 06:22:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remy Leone Date: Wed, 03 May 2017 13:21:58 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Watteyne Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c1cc10a1d4222054e9e8b12 Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 13:26:26 -0000 --94eb2c1cc10a1d4222054e9e8b12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would like to use the one that Carsten used. I've sent him an email asking for this tool but I'm still waiting for the answer. Le mer. 3 mai 2017 =C3=A0 15:18, Thomas Watteyne = a =C3=A9crit : > This is great! I assume there are plenty of tools which will turn the yml > files into e.g. a PDF version of the TD? > > On Wed, May 3, 2017 at 3:06 PM, Remy Leone wrote: > >> Hello, >> >> I've just pushed a first version of the 6TiSCH test description in the >> following repository: >> >> https://bitbucket.org/6tisch/td-6tisch >> >> I've used the content present in the test description document provided >> by ETSI during 6TiSCH plugtest events. >> >> Using a git-based workflow to change those test descriptions will I thin= k >> help a great deal in the implementation of automated conformance and >> interoperability testing. >> >> Feel free to start opening pull requests with new tests or corrections o= f >> existing ones for the upcoming plugtest event. >> >> I would also appreciate if you could help me to distinguish between >> obsolete and relevant tests. From what I understood, some tests needs to= be >> updated or removed. >> Also, it would help to change the reference those tests are based upon >> (minimal-11, minimal-14, minimal-15). >> >> Best regards >> >> R=C3=A9my >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > _______________________________________ > --94eb2c1cc10a1d4222054e9e8b12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would like to use the one that Carsten used. I've se= nt him an email asking for this tool but I'm still waiting for the answ= er.

Le=C2=A0mer. 3 mai 2= 017 =C3=A0=C2=A015:18, Thomas Watteyne <thomas.watteyne@inria.fr> a =C3=A9crit=C2=A0:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
This is great! I assume ther= e are plenty of tools which will turn the yml files into e.g. a PDF version= of the TD?

=
On Wed, M= ay 3, 2017 at 3:06 PM, Remy Leone <remy.leone@inria.fr> wr= ote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hello,

I&= #39;ve just pushed a first version of the 6TiSCH test description in the fo= llowing repository:


I've used the content present in th= e test description document provided by ETSI during 6TiSCH plugtest events.=

Using a git-based workflow to change those test d= escriptions will I think help a great deal in the implementation of automat= ed conformance and interoperability testing.

Feel = free to start opening pull requests with new tests or corrections of existi= ng ones for the upcoming plugtest=C2=A0event.

I wo= uld also appreciate if you could help me to distinguish between obsolete an= d relevant tests. From what I understood, some tests needs to be updated or= removed.=C2=A0
Also, it would help to change the reference those= tests are based upon (minimal-11, minimal-14, minimal-15).

<= /div>
Best regards

R=C3=A9my

____________________________________= ___________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch




--
_______= ________________________________

Thomas Watteyne, PhD
Rese= arch Scientist & Innovator, Inria
Sr Networking Design Eng, Linear = Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6Ti= SCH

_______________________________________
--94eb2c1cc10a1d4222054e9e8b12-- From nobody Wed May 3 07:15:39 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B441A129B35 for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 gHSuTLZsJnqW for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:15:35 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F9C9129BAE for <6tisch@ietf.org>; Wed, 3 May 2017 07:12:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222316562" Received: from mail-vk0-f51.google.com ([209.85.213.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 16:12:52 +0200 Received: by mail-vk0-f51.google.com with SMTP id y190so10150907vkc.1 for <6tisch@ietf.org>; Wed, 03 May 2017 07:12:52 -0700 (PDT) X-Gm-Message-State: AN3rC/6k8aqTst60jtGORHMCj4RY2TjdswItuozjTWknpQeorpSMby79 o1ODiAcPhI0+mRm+2o6tA+yzQxxLeA== X-Received: by 10.31.176.135 with SMTP id z129mr7339735vke.89.1493820771187; Wed, 03 May 2017 07:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.92.17 with HTTP; Wed, 3 May 2017 07:12:30 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 3 May 2017 16:12:30 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Remy Leone Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a11439b466cc406054e9f401c Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:15:38 -0000 --001a11439b466cc406054e9f401c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That sounds great. Having a CI keeping an up-to-date version of the PDF version at all times seems like the best of all worlds. Thanks for doing the conversion exercise! On Wed, May 3, 2017 at 3:21 PM, Remy Leone wrote: > I would like to use the one that Carsten used. I've sent him an email > asking for this tool but I'm still waiting for the answer. > > > Le mer. 3 mai 2017 =C3=A0 15:18, Thomas Watteyne a > =C3=A9crit : > >> This is great! I assume there are plenty of tools which will turn the ym= l >> files into e.g. a PDF version of the TD? >> >> On Wed, May 3, 2017 at 3:06 PM, Remy Leone wrote: >> >>> Hello, >>> >>> I've just pushed a first version of the 6TiSCH test description in the >>> following repository: >>> >>> https://bitbucket.org/6tisch/td-6tisch >>> >>> I've used the content present in the test description document provided >>> by ETSI during 6TiSCH plugtest events. >>> >>> Using a git-based workflow to change those test descriptions will I >>> think help a great deal in the implementation of automated conformance = and >>> interoperability testing. >>> >>> Feel free to start opening pull requests with new tests or corrections >>> of existing ones for the upcoming plugtest event. >>> >>> I would also appreciate if you could help me to distinguish between >>> obsolete and relevant tests. From what I understood, some tests needs t= o be >>> updated or removed. >>> Also, it would help to change the reference those tests are based upon >>> (minimal-11, minimal-14, minimal-15). >>> >>> Best regards >>> >>> R=C3=A9my >>> >>> _______________________________________________ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >> >> -- >> _______________________________________ >> >> Thomas Watteyne, PhD >> Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Linear Tech >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> >> www.thomaswatteyne.com >> _______________________________________ >> > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a11439b466cc406054e9f401c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That sounds great. Having a CI keeping an up-to-date versi= on of the PDF version at all times seems like the best of all worlds. Thank= s for doing the conversion exercise!

On Wed, May 3, 2017 at 3:21 PM, Remy Leone <rem= y.leone@inria.fr> wrote:
I would like to use the one that Carsten used. I've sent= him an email asking for this tool but I'm still waiting for the answer= .


Le=C2=A0mer. 3 mai 2017 =C3=A0=C2=A015:18, Thomas Watteyne <thomas.watteyne@inria.fr= > a =C3=A9crit=C2=A0:
This is great! I assume there are plenty of tools which will tur= n the yml files into e.g. a PDF version of the TD?

On Wed, May 3, 2017 at 3:06 PM, Remy Leone <remy.leone@inria.fr> wrote:
Hello,

I've just pushed a first version o= f the 6TiSCH test description in the following repository:


=
I've used the content present in the test description document pro= vided by ETSI during 6TiSCH plugtest events.

Using= a git-based workflow to change those test descriptions will I think help a= great deal in the implementation of automated conformance and interoperabi= lity testing.

Feel free to start opening pull requ= ests with new tests or corrections of existing ones for the upcoming plugte= st=C2=A0event.

I would also appreciate if you coul= d help me to distinguish between obsolete and relevant tests. From what I u= nderstood, some tests needs to be updated or removed.=C2=A0
Also,= it would help to change the reference those tests are based upon (minimal-= 11, minimal-14, minimal-15).

Best regards

R=C3=A9my

_______________________________= ________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
_______________________________________

Thoma= s Watteyne, PhD
Research Scientist & Innovator, Inria
<= div style=3D"font-size:small">Sr Networ= king Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN=
Co-chair, IETF 6TiSCH

__________________= _____________________



--
_______________________________________

<= div style=3D"font-size:small">Thomas Wa= tteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking= Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________= ________________
--001a11439b466cc406054e9f401c-- From nobody Wed May 3 07:21:28 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B71F8129B35 for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 9Dx4I1EhScFj for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:21:23 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CEBC1293F9 for <6tisch@ietf.org>; Wed, 3 May 2017 07:18:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222317773" Received: from mail-yw0-f175.google.com ([209.85.161.175]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 16:18:43 +0200 Received: by mail-yw0-f175.google.com with SMTP id k11so85400726ywb.1 for <6tisch@ietf.org>; Wed, 03 May 2017 07:18:43 -0700 (PDT) X-Gm-Message-State: AN3rC/61IXg/JjtVU+AXuBxUT0oQVlN2TNnOgupyKv0lerjdvxyd9Q1v +ALSHasAQgLJTRGpMbjPmakcLNiW+A== X-Received: by 10.129.182.35 with SMTP id u35mr29164288ywh.314.1493821122244; Wed, 03 May 2017 07:18:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remy Leone Date: Wed, 03 May 2017 14:18:31 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Watteyne Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=94eb2c1cc10a59a305054e9f5595 Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:21:27 -0000 --94eb2c1cc10a59a305054e9f5595 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable No problem. I've activated the issue tracking and added a couple of issues: https://bitbucket.org/6tisch/td-6tisch/issues?status=3Dnew&status=3Dopen Let me know if I should move the issues somewhere else. R=C3=A9my Le mer. 3 mai 2017 =C3=A0 16:12, Thomas Watteyne = a =C3=A9crit : > That sounds great. Having a CI keeping an up-to-date version of the PDF > version at all times seems like the best of all worlds. Thanks for doing > the conversion exercise! > > On Wed, May 3, 2017 at 3:21 PM, Remy Leone wrote: > >> I would like to use the one that Carsten used. I've sent him an email >> asking for this tool but I'm still waiting for the answer. >> >> >> Le mer. 3 mai 2017 =C3=A0 15:18, Thomas Watteyne a >> =C3=A9crit : >> >>> This is great! I assume there are plenty of tools which will turn the >>> yml files into e.g. a PDF version of the TD? >>> >>> On Wed, May 3, 2017 at 3:06 PM, Remy Leone wrote: >>> >>>> Hello, >>>> >>>> I've just pushed a first version of the 6TiSCH test description in the >>>> following repository: >>>> >>>> https://bitbucket.org/6tisch/td-6tisch >>>> >>>> I've used the content present in the test description document provide= d >>>> by ETSI during 6TiSCH plugtest events. >>>> >>>> Using a git-based workflow to change those test descriptions will I >>>> think help a great deal in the implementation of automated conformance= and >>>> interoperability testing. >>>> >>>> Feel free to start opening pull requests with new tests or corrections >>>> of existing ones for the upcoming plugtest event. >>>> >>>> I would also appreciate if you could help me to distinguish between >>>> obsolete and relevant tests. From what I understood, some tests needs = to be >>>> updated or removed. >>>> Also, it would help to change the reference those tests are based upon >>>> (minimal-11, minimal-14, minimal-15). >>>> >>>> Best regards >>>> >>>> R=C3=A9my >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> 6tisch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> >>> -- >>> _______________________________________ >>> >>> Thomas Watteyne, PhD >>> Research Scientist & Innovator, Inria >>> Sr Networking Design Eng, Linear Tech >>> Founder & co-lead, UC Berkeley OpenWSN >>> Co-chair, IETF 6TiSCH >>> >>> www.thomaswatteyne.com >>> _______________________________________ >>> >> > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > _______________________________________ > --94eb2c1cc10a59a305054e9f5595 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No problem.
I've activated the issue=C2=A0tracking= and added a couple of issues:
https://bitbucket.or= g/6tisch/td-6tisch/issues?status=3Dnew&status=3Dopen=C2=A0

Let me know if I should move the issues somewhere else= .

R=C3=A9my

Le=C2=A0mer. 3 mai 2017 =C3=A0=C2=A016:12, Thomas Watt= eyne <thomas.watteyne@inria.= fr> a =C3=A9crit=C2=A0:
That sounds great. Having a CI keeping an up-to-date version o= f the PDF version at all times seems like the best of all worlds. Thanks fo= r doing the conversion exercise!

On Wed, May 3, 2017 at 3:21 PM, Remy Leone <remy.= leone@inria.fr> wrote:
I would like to use the one that Carsten used. I've sent h= im an email asking for this tool but I'm still waiting for the answer.<= div>


Le=C2=A0mer. 3 mai 2017 =C3=A0=C2=A015:18, Thomas Watte= yne <thoma= s.watteyne@inria.fr> a =C3=A9crit=C2=A0:
This is great! I assume there are plenty of = tools which will turn the yml files into e.g. a PDF version of the TD?

On Wed, May 3, 2017 at 3:= 06 PM, Remy Leone <remy.leone@inria.fr> wrote:
Hello,

I've just push= ed a first version of the 6TiSCH test description in the following reposito= ry:

=

I've used the content present in the test descripti= on document provided by ETSI during 6TiSCH plugtest events.

<= /div>
Using a git-based workflow to change those test descriptions will= I think help a great deal in the implementation of automated conformance a= nd interoperability testing.

Feel free to start op= ening pull requests with new tests or corrections of existing ones for the = upcoming plugtest=C2=A0event.

I would also appreci= ate if you could help me to distinguish between obsolete and relevant tests= . From what I understood, some tests needs to be updated or removed.=C2=A0<= /div>
Also, it would help to change the reference those tests are based= upon (minimal-11, minimal-14, minimal-15).

Best r= egards

R=C3=A9my

____________________________________= ___________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch




--
_______________________________________
Thomas Watteyne, PhD
= Research Scientist & Innovator, Inr= ia
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC = Berkeley OpenWSN
Co-chair, IETF 6TiSCH

__= _____________________________________



--
_______________________________________
Thomas Watteyne, PhD
= Research Scientist & Innovator, Inr= ia
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC = Berkeley OpenWSN
Co-chair, IETF 6TiSCH

__= _____________________________________
--94eb2c1cc10a59a305054e9f5595-- From nobody Wed May 3 07:25:05 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D6E1124B0A for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 dG1KR_2HL7a1 for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:25:02 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D18129A9F for <6tisch@ietf.org>; Wed, 3 May 2017 07:22:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222318439" Received: from mail-vk0-f53.google.com ([209.85.213.53]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 16:22:22 +0200 Received: by mail-vk0-f53.google.com with SMTP id y190so10327512vkc.1 for <6tisch@ietf.org>; Wed, 03 May 2017 07:22:22 -0700 (PDT) X-Gm-Message-State: AN3rC/4dSy//NFUTh3FT1Eq5qM6hoUBtvUsDzd4jtvwhYUKmmIHe2hcy cxr3yI/8KYfI0mhytnpK3CO74hfxkg== X-Received: by 10.31.142.146 with SMTP id q140mr14999811vkd.131.1493821341008; Wed, 03 May 2017 07:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.92.17 with HTTP; Wed, 3 May 2017 07:22:00 -0700 (PDT) In-Reply-To: References: From: Thomas Watteyne Date: Wed, 3 May 2017 16:22:00 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Remy Leone Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a1142f7f663b69d054e9f6201 Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:25:04 -0000 --001a1142f7f663b69d054e9f6201 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Remy, This looks great. I propose that we discuss particular issues directly through the tracker rather than the ML, but would very much appreciate if you could keep the WG updated with major developments. Thomas On Wed, May 3, 2017 at 4:18 PM, Remy Leone wrote: > No problem. > I've activated the issue tracking and added a couple of issues: > https://bitbucket.org/6tisch/td-6tisch/issues?status=3Dnew&status=3Dopen > > Let me know if I should move the issues somewhere else. > > R=C3=A9my > > Le mer. 3 mai 2017 =C3=A0 16:12, Thomas Watteyne a > =C3=A9crit : > >> That sounds great. Having a CI keeping an up-to-date version of the PDF >> version at all times seems like the best of all worlds. Thanks for doing >> the conversion exercise! >> >> On Wed, May 3, 2017 at 3:21 PM, Remy Leone wrote: >> >>> I would like to use the one that Carsten used. I've sent him an email >>> asking for this tool but I'm still waiting for the answer. >>> >>> >>> Le mer. 3 mai 2017 =C3=A0 15:18, Thomas Watteyne >>> a =C3=A9crit : >>> >>>> This is great! I assume there are plenty of tools which will turn the >>>> yml files into e.g. a PDF version of the TD? >>>> >>>> On Wed, May 3, 2017 at 3:06 PM, Remy Leone wrote= : >>>> >>>>> Hello, >>>>> >>>>> I've just pushed a first version of the 6TiSCH test description in th= e >>>>> following repository: >>>>> >>>>> https://bitbucket.org/6tisch/td-6tisch >>>>> >>>>> I've used the content present in the test description document >>>>> provided by ETSI during 6TiSCH plugtest events. >>>>> >>>>> Using a git-based workflow to change those test descriptions will I >>>>> think help a great deal in the implementation of automated conformanc= e and >>>>> interoperability testing. >>>>> >>>>> Feel free to start opening pull requests with new tests or correction= s >>>>> of existing ones for the upcoming plugtest event. >>>>> >>>>> I would also appreciate if you could help me to distinguish between >>>>> obsolete and relevant tests. From what I understood, some tests needs= to be >>>>> updated or removed. >>>>> Also, it would help to change the reference those tests are based upo= n >>>>> (minimal-11, minimal-14, minimal-15). >>>>> >>>>> Best regards >>>>> >>>>> R=C3=A9my >>>>> >>>>> _______________________________________________ >>>>> 6tisch mailing list >>>>> 6tisch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>>> >>>> -- >>>> _______________________________________ >>>> >>>> Thomas Watteyne, PhD >>>> Research Scientist & Innovator, Inria >>>> Sr Networking Design Eng, Linear Tech >>>> Founder & co-lead, UC Berkeley OpenWSN >>>> Co-chair, IETF 6TiSCH >>>> >>>> www.thomaswatteyne.com >>>> _______________________________________ >>>> >>> >> >> >> -- >> _______________________________________ >> >> Thomas Watteyne, PhD >> Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Linear Tech >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> >> www.thomaswatteyne.com >> _______________________________________ >> > --=20 _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --001a1142f7f663b69d054e9f6201 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Remy,
This looks great. I propose that we discuss part= icular issues directly through the tracker rather than the ML, but would ve= ry much appreciate if you could keep the WG updated with major developments= .
Thomas

On Wed, May 3, 2017 at 4:18 PM, Remy Leone &= lt;remy.leone@inri= a.fr> wrote:
No problem.
I've activated the issue=C2=A0tracking and added a c= ouple of issues:

Let me know if I should move the issues= somewhere else.

R=C3=A9my

Le=C2=A0mer. 3 mai 2017 =C3=A0=C2=A016:12, Thomas Watteyne <thomas.watteyne@inri= a.fr> a =C3=A9crit=C2=A0:
That sounds great. Having a CI keeping an up-to-date version= of the PDF version at all times seems like the best of all worlds. Thanks = for doing the conversion exercise!

On Wed, May 3, 2017 at 3:21 PM, Remy Leone <remy.= leone@inria.fr> wrote:
I would like to use the one that Carsten used. I've sent h= im an email asking for this tool but I'm still waiting for the answer.<= div>


Le=C2=A0mer. 3 mai 2017 =C3=A0=C2= =A015:18, Thomas Watteyne <thomas.watteyne@inria.fr> a =C3=A9crit=C2=A0:
This is great! I assume= there are plenty of tools which will turn the yml files into e.g. a PDF ve= rsion of the TD?

On W= ed, May 3, 2017 at 3:06 PM, Remy Leone <remy.leone@inria.fr> wrote:
Hello,

I've just pushed a first version of the 6TiSCH test description in t= he following repository:


I've used the content pre= sent in the test description document provided by ETSI during 6TiSCH plugte= st events.

Using a git-based workflow to change th= ose test descriptions will I think help a great deal in the implementation = of automated conformance and interoperability testing.

=
Feel free to start opening pull requests with new tests or corrections= of existing ones for the upcoming plugtest=C2=A0event.

I would also appreciate if you could help me to distinguish between o= bsolete and relevant tests. From what I understood, some tests needs to be = updated or removed.=C2=A0
Also, it would help to change the refer= ence those tests are based upon (minimal-11, minimal-14, minimal-15).
=

Best regards

R=C3=A9my

_______________________________= ________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
__________________= _____________________

Thomas Watteyne, PhD
Research S= cientist & Innovator, Inria
= Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________________________



--
__________________= _____________________

Thomas Watteyne, PhD
Research S= cientist & Innovator, Inria
= Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

_______________________________________



--
=
_______________________________________
=

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria<= /div>
Sr = Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley O= penWSN
Co-chair, IETF 6TiSCH

_____________= __________________________
--001a1142f7f663b69d054e9f6201-- From nobody Wed May 3 07:30:34 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48000126C2F for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 uWzLbc_zvmDf for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:30:31 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9870C129479 for <6tisch@ietf.org>; Wed, 3 May 2017 07:28:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,284,1491256800"; d="scan'208,217";a="222319293" Received: from mail-yw0-f180.google.com ([209.85.161.180]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 03 May 2017 16:28:17 +0200 Received: by mail-yw0-f180.google.com with SMTP id u70so85787913ywe.2 for <6tisch@ietf.org>; Wed, 03 May 2017 07:28:17 -0700 (PDT) X-Gm-Message-State: AN3rC/6C0L0tGLcDNBCxvDT2ZIRFMt0xmznbvEENn4z0BrVvmhdSouen ncwJ9oocg6F61Y2EIXpu7mG9G4Mt1g== X-Received: by 10.129.52.141 with SMTP id b135mr29435780ywa.85.1493821695959; Wed, 03 May 2017 07:28:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Remy Leone Date: Wed, 03 May 2017 14:28:05 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Thomas Watteyne Cc: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary=001a114089848bc656054e9f77e0 Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:30:33 -0000 --001a114089848bc656054e9f77e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure, will do. I will keep pushing new issues to the bitbucket tracker and update the WG once we get to something stable CI-wise. Le mer. 3 mai 2017 =C3=A0 16:22, Thomas Watteyne = a =C3=A9crit : > Remy, > This looks great. I propose that we discuss particular issues directly > through the tracker rather than the ML, but would very much appreciate if > you could keep the WG updated with major developments. > Thomas > > On Wed, May 3, 2017 at 4:18 PM, Remy Leone wrote: > >> No problem. >> I've activated the issue tracking and added a couple of issues: >> https://bitbucket.org/6tisch/td-6tisch/issues?status=3Dnew&status=3Dopen >> >> Let me know if I should move the issues somewhere else. >> >> R=C3=A9my >> >> Le mer. 3 mai 2017 =C3=A0 16:12, Thomas Watteyne a >> =C3=A9crit : >> >>> That sounds great. Having a CI keeping an up-to-date version of the PDF >>> version at all times seems like the best of all worlds. Thanks for doin= g >>> the conversion exercise! >>> >>> On Wed, May 3, 2017 at 3:21 PM, Remy Leone wrote: >>> >>>> I would like to use the one that Carsten used. I've sent him an email >>>> asking for this tool but I'm still waiting for the answer. >>>> >>>> >>>> Le mer. 3 mai 2017 =C3=A0 15:18, Thomas Watteyne >>>> a =C3=A9crit : >>>> >>>>> This is great! I assume there are plenty of tools which will turn the >>>>> yml files into e.g. a PDF version of the TD? >>>>> >>>>> On Wed, May 3, 2017 at 3:06 PM, Remy Leone >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I've just pushed a first version of the 6TiSCH test description in >>>>>> the following repository: >>>>>> >>>>>> https://bitbucket.org/6tisch/td-6tisch >>>>>> >>>>>> I've used the content present in the test description document >>>>>> provided by ETSI during 6TiSCH plugtest events. >>>>>> >>>>>> Using a git-based workflow to change those test descriptions will I >>>>>> think help a great deal in the implementation of automated conforman= ce and >>>>>> interoperability testing. >>>>>> >>>>>> Feel free to start opening pull requests with new tests or >>>>>> corrections of existing ones for the upcoming plugtest event. >>>>>> >>>>>> I would also appreciate if you could help me to distinguish between >>>>>> obsolete and relevant tests. From what I understood, some tests need= s to be >>>>>> updated or removed. >>>>>> Also, it would help to change the reference those tests are based >>>>>> upon (minimal-11, minimal-14, minimal-15). >>>>>> >>>>>> Best regards >>>>>> >>>>>> R=C3=A9my >>>>>> >>>>>> _______________________________________________ >>>>>> 6tisch mailing list >>>>>> 6tisch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> _______________________________________ >>>>> >>>>> Thomas Watteyne, PhD >>>>> Research Scientist & Innovator, Inria >>>>> Sr Networking Design Eng, Linear Tech >>>>> Founder & co-lead, UC Berkeley OpenWSN >>>>> Co-chair, IETF 6TiSCH >>>>> >>>>> www.thomaswatteyne.com >>>>> _______________________________________ >>>>> >>>> >>> >>> >>> -- >>> _______________________________________ >>> >>> Thomas Watteyne, PhD >>> Research Scientist & Innovator, Inria >>> Sr Networking Design Eng, Linear Tech >>> Founder & co-lead, UC Berkeley OpenWSN >>> Co-chair, IETF 6TiSCH >>> >>> www.thomaswatteyne.com >>> _______________________________________ >>> >> > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > Founder & co-lead, UC Berkeley OpenWSN > Co-chair, IETF 6TiSCH > > www.thomaswatteyne.com > _______________________________________ > --001a114089848bc656054e9f77e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, will do. I will keep pushing new issues to the bitbu= cket tracker and update the WG once we get to something stable CI-wise.
Le=C2=A0mer. 3 mai 2017 = =C3=A0=C2=A016:22, Thomas Watteyne <thomas.watteyne@inria.fr> a =C3=A9crit=C2=A0:
Remy,
This looks great. I pr= opose that we discuss particular issues directly through the tracker rather= than the ML, but would very much appreciate if you could keep the WG updat= ed with major developments.
Thomas

On Wed, May 3= , 2017 at 4:18 PM, Remy Leone <remy.leone@inria.fr> wrote:=
No problem.
I'v= e activated the issue=C2=A0tracking and added a couple of issues:
https://bitbucket.org/6tisch/td-6tisch/iss= ues?status=3Dnew&status=3Dopen=C2=A0

L= et me know if I should move the issues somewhere else.

=
R=C3=A9my

Le=C2=A0mer. 3 mai 2017 =C3=A0=C2=A016:12, Thomas Watteyne <thomas.watteyne@inr= ia.fr> a =C3=A9crit=C2=A0:
<= div dir=3D"ltr">That sounds great. Having a CI keeping an up-to-date versio= n of the PDF version at all times seems like the best of all worlds. Thanks= for doing the conversion exercise!

On Wed, May 3, 2017 at 3:21 PM, Remy Leone <remy= .leone@inria.fr> wrote:
I would like to use the one that Carsten used. I've sent = him an email asking for this tool but I'm still waiting for the answer.=


Le=C2=A0mer= . 3 mai 2017 =C3=A0=C2=A015:18, Thomas Watteyne <thomas.watteyne@inria.fr> a = =C3=A9crit=C2=A0:
= This is great! I assume there are plenty of tools which will turn the yml f= iles into e.g. a PDF version of the TD?
On Wed, May 3, 2017 at 3:06 PM, Remy Leone <remy.leon= e@inria.fr> wrote:
=
= Hello,

I've just pushed a first version of the 6TiSC= H test description in the following repository:

https://= bitbucket.org/6tisch/td-6tisch

I've us= ed the content present in the test description document provided by ETSI du= ring 6TiSCH plugtest events.

Using a git-based wor= kflow to change those test descriptions will I think help a great deal in t= he implementation of automated conformance and interoperability testing.

Feel free to start opening pull requests with new te= sts or corrections of existing ones for the upcoming plugtest=C2=A0event.

I would also appreciate if you could help me to dis= tinguish between obsolete and relevant tests. From what I understood, some = tests needs to be updated or removed.=C2=A0
Also, it would help t= o change the reference those tests are based upon (minimal-11, minimal-14, = minimal-15).

Best regards

R=C3=A9my

____________________________________= ___________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch




--
_______________________________________

Thomas Watteyne, PhD<= /font>
Research Scientist & Innovator, Inria
Sr Networking Design Eng,= Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, I= ETF 6TiSCH

________________________________= _______



--
_______________________________________

Thomas Watteyne, PhD<= /font>
Research Scientist & Innovator, Inria
Sr Networking Design Eng,= Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, I= ETF 6TiSCH

________________________________= _______



--
=
________________________________= _______

Thomas Watteyne, PhD
Research Scientist & Inno= vator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co= -lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

<= div style=3D"font-size:small">www.thomaswatteyne.com=
_______________________________________
--001a114089848bc656054e9f77e0-- From nobody Wed May 3 07:54:55 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1831B129BCC for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=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 ygUBN9c8LuBp for <6tisch@ietfa.amsl.com>; Wed, 3 May 2017 07:54:41 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F382E129488 for <6tisch@ietf.org>; Wed, 3 May 2017 07:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v43EqL6h009155; Wed, 3 May 2017 16:52:21 +0200 (CEST) Received: from [192.168.217.113] (p5DC7F3A7.dip0.t-ipconnect.de [93.199.243.167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3wJ1N50YT7zDJDv; Wed, 3 May 2017 16:52:21 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Carsten Bormann In-Reply-To: Date: Wed, 3 May 2017 16:52:19 +0200 Cc: Thomas Watteyne , 6TiSCH mailing list <6tisch@ietf.org> X-Mao-Original-Outgoing-Id: 515515939.392534-d1cd0b6f9dd387d455981c744bcb544a Content-Transfer-Encoding: quoted-printable Message-Id: <54BC6304-E417-4755-8121-8A437B2C4E85@tzi.org> References: To: Remy Leone X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [6tisch] First version of git-tracked test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 May 2017 14:54:49 -0000 On May 3, 2017, at 15:21, Remy Leone wrote: >=20 > I would like to use the one that Carsten used. I've sent him an email = asking for this tool but I'm still waiting for the answer. Sent (off list). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue May 9 05:27:42 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A13129C2F for <6tisch@ietfa.amsl.com>; Tue, 9 May 2017 05:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.122 X-Spam-Level: X-Spam-Status: No, score=-13.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 33PE9TuQKeJU for <6tisch@ietfa.amsl.com>; Tue, 9 May 2017 05:27:39 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F306912943F for <6tisch@ietf.org>; Tue, 9 May 2017 05:27:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13762; q=dns/txt; s=iport; t=1494332858; x=1495542458; h=from:to:subject:date:message-id:mime-version; bh=XMb7BoYWlgPxXLxEAxEiWj0i0WcGhDAr1AzQmtNSdx4=; b=Lo6D7UmQSyTdk2v8KS78Wp03UTL42LOKDYe/zcKUDgjb6KSzm7MdIOK3 Lj8eKxyItcGTLKwd1qqFwnlvxGXNXjkh0gtTZv1cguZqMaRen3woXsl2n ZhrKhdAOc0n47n9GGfYCKq0XhohgGXv2UWxyBD3pdmr6LYcUcliab52P8 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQC3tBFZ/4kNJK1BGhsBAQEDAQEBC?= =?us-ascii?q?QEBAYJuZ2KBDAeNeqIRhTiCDy6FdoRpPxgBAgEBAQEBAQFrHQuFSV4BHGQmAQQ?= =?us-ascii?q?bEooHDjGiC5IyincBAQEBAQEBAwEBAQEBAQEBIIZfgV6EV4FlgRMSAQwwhUkFn?= =?us-ascii?q?gUBhxuLdIINj2eIfYtCAR84fwtwFYU6HIFjdgGGRoEhgQ0BAQE?= X-IronPort-AV: E=Sophos; i="5.38,314,1491264000"; d="scan'208,217"; a="25079097" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2017 12:27:34 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v49CRWtb006077 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Tue, 9 May 2017 12:27:32 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 9 May 2017 07:27:32 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Tue, 9 May 2017 07:27:31 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Agenda, 12 May 2017 interim, 6TiSCH WG Thread-Index: AdLIvx6j4YPedsGLQbOCD3KCV47kGg== Date: Tue, 9 May 2017 12:27:01 +0000 Deferred-Delivery: Tue, 9 May 2017 12:26:19 +0000 Message-ID: <69b1406aa7c346928dfee061ecf9fec2@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.28] Content-Type: multipart/alternative; boundary="_000_69b1406aa7c346928dfee061ecf9fec2XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Agenda, 12 May 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 12:27:41 -0000 --_000_69b1406aa7c346928dfee061ecf9fec2XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Connection details * Date: 12 May 2017 7-8am Pacific: http://www.worldtimebuddy.com/?qm= =3D1&lid=3D100,12,5392171,1850147&h=3D100&date=3D2017-05-12&sln=3D14-15 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4= e38d97d986b507ec12a1f9b1 * Material link: https://bitbucket.org/6tisch/meetings/raw/master/17051= 2_webex/slides_170512_webex.ppt Action Items (previous meeting) * Thomas to contact Carsten * Thomas to contact MR and coordinate PT * Xavi and Qin to review SF0 * Jonathan to review 6P after Charlie's comments are addressed * Xavi and Qin to address Charlie's comments * Xavi to bootstrap research liaison * Diego to write an email and open a ticket to track the issues between SF= and 6P. Agenda * Administrivia [ 7min] * Agenda bashing * Approval minutes from last meeting * Addressing todo's from last time * News from PlugTest * 6P finalization (Thomas, Qin) [20min] * SF0 finalization (Diego) [20min] * Update on security (Michael/Malisa) [ 5min] * AOB [ 3min] --_000_69b1406aa7c346928dfee061ecf9fec2XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Connection details

Action Items (previ= ous meeting)

 * Thomas t=
o contact Carsten
 * Thomas t=
o contact MR and coordinate PT
 * Xavi and=
 Qin to review SF0
 * Jonathan=
 to review 6P after Charlie's comments are addressed
 * Xavi and=
 Qin to address Charlie's comments
 * Xavi to =
bootstrap research liaison
 * Diego to=
 write an email and open a ticket to track the issues between SF and 6P.

Agenda

<= span style=3D"mso-list:Ignore">·        Administrivia [ 7min]

    • Agenda bashing
    • Approval minutes from last meeting
    • =
    • Addressing todo's from last time
    • News from PlugTest

<= span style=3D"mso-list:Ignore">·        6P finalization (Thomas, Qin) [20min]

  • SF0 finalization (Diego) [20min]
  • Update on security (Michael/Malisa) [ 5min]
  • AOB [ 3min]

 

--_000_69b1406aa7c346928dfee061ecf9fec2XCHRCD001ciscocom_-- From nobody Thu May 11 07:23:38 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C963912EC7D for <6tisch@ietfa.amsl.com>; Thu, 11 May 2017 07:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 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_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com 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 dLJUheqw-FZY for <6tisch@ietfa.amsl.com>; Thu, 11 May 2017 07:23:30 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEA112426E for <6tisch@ietf.org>; Thu, 11 May 2017 07:16:22 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id p143so6758227yba.2 for <6tisch@ietf.org>; Thu, 11 May 2017 07:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y5AT7lGGhsJv66Mj5RTiDgnKf0AS1rDpbfPGVl6YxTI=; b=ALYP6/TjkFnb2LwgYv8a6L0wE32HOI1PAgxyYADCUd1c6bNNtomiorp8eKyQCFrvyu 0ilZ+NXkY33CKy8c2+1mqWAnYj5G9G5aGD3QOl/I0crR2bh3SStLBCvdSSHwypOOitD+ ycwxu1ri0IJRQUJE+Yo32f0eqjPxHsNDhS6wU+604QM30126XBrpMSOC4VGHfeunwpBy iRbCzHlmz9zWSKYGDehxxJf91AHOisGNvuDPVaftyJlPZ73XoLf0u7bhuuBRIi9fai7R z+hHY581E3bEebxBhO7MiKOWJCvP5gPfSB0mRoFGOR5FoeXsb3GRTZMzauj9lX1GPr6R Qbzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y5AT7lGGhsJv66Mj5RTiDgnKf0AS1rDpbfPGVl6YxTI=; b=SG+p4heyDLl7XZxRhWg+bvV4WHk9PB33TC7t8VwwQ1tE47WVICPOhhB1izn6o57wHe r+xFtl1EPvZNGk6gpNSr5sjzydMVaGttnBwmmSBnzPUYrVgQTKhjIjOQdn8mFxuMf5dR 8esbUguswKwXRoQR4iKDzmy/7FCuECIUkI1oQAxlIa3sj/cRn+qFyu7TZpaWV8iRHVOM Tg4M5vvCkKl4/RI2Ct+liaP03KJJlw11pJgj2ZnNmX4E2CCdBOORy99Iku1kC3Cw1nI2 ZxuZ1IcfXdU7XJDnvoUtln3TolkwwYdn4yHR87WAMv2MHK7rsmN+eOhysGK090aMAVTe 7mLQ== X-Gm-Message-State: AODbwcDPleR9BBM5qXaIvMc74VphUMgHICffX0bVkXeObSHz/++sosj5 neEVu3sjTGDXhbRDjECgj+mR0JPBfg== X-Received: by 10.37.68.87 with SMTP id r84mr538030yba.34.1494512181442; Thu, 11 May 2017 07:16:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.136.134 with HTTP; Thu, 11 May 2017 07:16:00 -0700 (PDT) In-Reply-To: References: From: "Prof. Diego Dujovne" Date: Thu, 11 May 2017 11:16:00 -0300 Message-ID: To: Xavi Vilajosana Guillen Cc: tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="001a113f5f3eb0281b054f403bf7" Archived-At: Subject: Re: [6tisch] comments SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 14:23:37 -0000 --001a113f5f3eb0281b054f403bf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xavi, I answer to your comments inline. I am really grateful for your comments, since most the new version had not had a detailed revision since the migration from OTF to SF0. Regards, Diego 2017-04-30 8:37 GMT-03:00 Xavi Vilajosana Guillen : > Dear SF0 authors, all > > I've gone through the SF0 draft (v04) published last Friday (28th April). > Please find my constructive comments after reading the document. I hope > they are useful. > > kind regards, > X > ------- > Abstract: > > allocated cells -> scheduled cells? > This belongs to the OTF way of naming scheduled cells, I will update it. > > Intro: > > - for the 6top sublayer -> using the 6P protocol > - the minimal set of functionalities -> what is the minimal set? > - The intro explains that there are 2 algorithms. After this initial > introduction the purpose of the algorithms is briefly explained. Here I > suggest to add another section for each of them and let the introduction > just detail the goal of the document and motivation of the decisions take= n > for this SF. > OK. I will move the explanations from the introduction to the current algorithm description sections which already exist on the draft. > > - The description of the Sched. Alg. is somehow confusing. > > "The Scheduling Algorithm: A number of TX and/or RX cells must be > allocated between neighbor nodes in order to enable data transmission > among them. A portion of these allocated cells will be utilized by > neighbors, > > - what utilized by neighbors mean? do you refer that the cells will be > used to transmit packets/frames between the neighbors? > First, there is a difference between the allocated an used cells: You can allocate a cell, and send a packet over that cell when the time arrives, or keep the cell without a packet during a slotframe. So, in SF0 terms, an allocated cell may or may not be used. I listen to suggestions to change the term "used" to a more representative one. Now, going to your comment, first, SF0 only requests the scheduling of TX cells to a neighbour, which are RX cells on the other side. There are no shared cells since we have no clue on what the application(s) is(are) running on the node is(are) doing. Then, RX cells is a mistake there. The term "utilized" will be changed to "used" or to the proposed way of calling them. When the correct term is chosen, I will define it before this paragraph. > > while the remaining cells can be over-provisioned to > handle unanticipated increases in cell requirements. " > > -over-provisioning must be defined so everybody understands the concept. > OK. I will define what overprovisioning stands for. > > The Scheduling Algorithm collects the cell allocation/deletion requests > from the > neighbors and the number of cells which are currently under usage . > First, the Cell Estimation > > - Algotithm -> Algorithm > OK. Typo. It was hiding from me to survive in future versions, thanks for catching it. > > calculates the number of required cells by adding the collected values > > - What does this mean? what are the collected values? what is their > meaning? > This phrase should go away, it has currently no application. In the former versions we proposed that we were a part of a chain instead of having exclusively peer-to-peer negotiation. > > and second, the calculated value is given to the Allocation Policy, > which provides stability by adding hystheresis and overprovisioning by > deciding when > to schedule the new number of cells, according to a threshold. > > -Lots of information here. Maybe explain a little bit better. Give detail= s > about why it gives stability and how overprovisioning and hysteresis are > used for that. > - Also it is not clear what is the role of the threshold here. > > I will delete this phrase for the sake of clarity. > In order to reduce consumption, this algorithm is triggered only when > there is a change on the number of effectively used cells > > - assume later we will know how to calculate the number of effectively > used cells. > The "effectively used cells" term was coined originally to highlight that there is a huge difference between allocating and using a cell. It will be changed to "used" cells. > > or if there is a change on the number of requested cells from a particula= r > node. > This will be removed. In order to trigger SF0, we only look now at the number of used cells vs. the allocated cells from the node to any of the neighbours. Looking into requests from other neighbours and relating this to a possible traffic increase towards any of the remaining neighbours is not current. This was the original idea when we could identify a parent neighbour from a child neighbour. SF0 is now relative-agnostic. > > "A relocation is > triggered when the PDR value drops below a certain threshold, > compared to the average PDR of the rest of allocated cells. The > destination location on the schedule is defined randomly." > > - this assertion is central to the document, seems like this is one of > the major key points of the document. As said before, for me this should > not be in the introduction bu in a dedicated section explaining how > reloaction works. > Relocation is defined on section 4.3.3 of 6P. We only define here that we trigger that mechanism when an user-defined PDR threshold is reached, compared to the average PDR of all the other cells. Now, we do not go deep on how the average PDR is calculated (it may be calculated from the average PDR of all the cells where statistics are available except from the blacklisted ones). We also state that the replacement cell will be selected randomly among the unscheduled ones. We do not define retries. If it fails, this will be retriggered on the next slotframe and a retry will be issued. > > Section "Scheduling Function Identifier" > > should not be: IANA_SFID_SF0 -> IANA_6TiSCH_SFID_SF0. > OK. > > Section "SF0 Triggering Events" > > 1. If there is a change in the current number of required cells > > - is this triggered by what? 6P allocation? queue size? increase on cell > usage? > change on the number of used cells towards any of the neighbours. > > 2. If there is a successful cell allocation/deallocation process > with the neighbour. > > -A cell allocation is a result of a decision taken in a previous step, i.= e > some algorithm has decided that more cells are needed and those are > allocated. Then after the allocation the algorithm is triggered again. > Could you clarify in the text what is the purpose? > > This will be deleted now. As I explained before, we do not look on the other neighbours just in case this may mean that a new allocation will be reflected on any of the remaining neighbours. > This allows SF0 to be triggered by any change in locally generated or > incoming traffic. The exact mechanism of when SF0 is triggered is > implementation-specific. > no incoming traffic triggering. Candidate for deletion. > > Section "SF0 Cell Estimation Algorithm" > > The Cell Estimation Algorithm takes into account the new incoming > cell requirements > > - define somewhere what incoming cell requirements are? > I will delete this line. > > from the neighbor node and the current outgoing number of used cells. > > - idem, define outgoing > only used vs. scheduled, no outgoing. > > This allows the algorithm to estimate a new > number of cells to be allocated. As a consequence, the Cell > Estimation Algorithm for SF0 follows the steps described below: > 1. Collect the current number of used cells > > -to the particular neighbor or in total in its schedule? > to the particular neighbour. We are always scheduling to a single neighbour at a time, except for relocation, which monitors the whole schedule and relocates accordingly. > > 2. Calculate the new number of cells to be allocated by adding the > current number of used cells plus an OVERPROVISION number of > cells > - Considering the cells in the schedule, how the current number of used > cells are identified? > There should be statistics from the last slotframe on the number of used cells (vs, the number of scheduled cells) towards each of the neighbours. But this is implementation specific and SF0 does not specify how this is collected. > > 3. Submit the request to the allocation policy as REQUIREDCELLS > - explain better. What is submitted? is this a function call? Does this > mean, "indicate to the allocation policy the required cells". > I like "transferred". Function calls are not a matter of SF0, but it can be implemented that way. > > 4. Return to step 1 and wait for a triggering event. > > - Maybe a flow diagram would be a good complement to clarify its use. > OK. > > The OVERPROVISION parameter is a percentage of the > > currently allocated cells -> number of currently allocated cells > > > OK. This was proposed by Tengfei, but I have not seen tested yet compared to a fixed implementation-specific value. > - Why this link here. Maybe use a . and start a new sentence. > e.g., The OVERPROVISION value is added to the used cells parameter ... > OK > > which is added to the used cells to guarantee that > the growth on the number of used cells can be detected without packet > loss. This percentage value is implementation-specific. > > A value of > OVERPROVISION equal to zero leads to queue growth and possible packet > loss, since there are no overprovisioned cells to detect if there is > a growth on the number of used cells. > > -clarify this. > - 1) if no overprovision then no extra cells in the schedule to cope > with sudden increments or unexpected retransmissions > - 2) this may cause the queue to grow and eventually drop packets. > I wouldn't use retransmissions. SF0 should not to retransmit anything, we only retrigger SF0 in case of failure. I think it could be better to say sudden increment in traffic towards the neighbour. But 1) and 2) are connected: no overprovisioned cells -> queue growth can lead to packet loss. > > > Section "SF0 allocation policy" > > The "Allocation Policy" is the set of rules used by SF0 to decide > when to add/delete cells to a particular neighbor to satisfy the cell > requirements. > > SF0 uses the following parameters: > > SCHEDULEDCELLS: The number of cells scheduled from the current node > to a particular neighbor. > > REQUIREDCELLS: The number of cells calculated by the Cell Estimation > Algorithm from the current node to that neighbor. > > SF0THRESH: Threshold parameter introducing cell over-provisioning in > the allocation policy. > > - what is the relation of this with OVERPROVISION percentage in the > previous section? > There is no relation. We keep both independent on purpose. One decides the number of cells to be scheduled, the other decides when. This avoids instability by adding hysteresis, but the allocation policy does not care on how the number of requested cells was chosen by the cell estimation algorithm. This is one of the strong points of SF0. We have completely changed the estimation algorithm from one which had most information (knew about child, parent, cell application requests) to one that only knows the number of used cells vs. the scheduled cells. and the allocation policy did not change. > > Section "Rules for Celllist" > > How do you handle error situations? is there a retry-policy? > With respect to the retry policy, if the required cells are not satisfied, SF0 will be retriggered. The only condition (I find) we have not taken into account is when the schedule is full, and I have commented that several times without answer. We can specify here a number of transactions taking advantage of the celllist response with the available cells (given the number of requested cells for allocation), as a better policy than choosing randomly each time SF0 is retriggered. > > Section "6P Timeout value" > > "The general timeout equals the equivalent time of the number of slots > until the next scheduled cell." > > - I assume this is from the moment the transaction starts. Isn't it? > Please clarify in the description. > - Could you elaborate why this decision? > I truly believe the timeout calculation does not belong to SF0, but to 6P. That is why this sentence is there. We have tried several schemes, but, in the end, they depend on the transactions at the 6P level. From my point of view, the only reason here is that if a transaction fails during a slotframe, it will be retriggered in the next. > > Section SF0 Statistics > > -I do not understand the PDR definition > > Packet Delivery Rate (PDR) is calculated per cell, as the quotient of > the number of successfully delivered packets to 10 > > what is 10? is this how many of the last 10 have been acknowledged? > Succesfully delivered packets is acknowledged. I can change the term, no problem if it clarifies the idea. "to 10" will be deleted. > > , for the last 10 > packet transmission attempts, without counting retransmissions. > > > > Section "Relocating Cells" > > ... PDR_THRESHOLD, defined as a percentage of the > average of the PDR of the rest of the scheduled cells > > -Could you express this in a function? What percentage it is? > -If PDR_THRESHOLD is defined as indicated above, why later it is stated > that "PDR_THRESHOLD is out of the scope of this document and it is > implementation-dependent." > Because it is implementation specific. I will delete the former sentence. > > General comments: > > the document introduces the main ideas for SF0 but IMHO it needs some > editorial work to clarify the functionalities and do not mix concepts > during the explanation, in general it lacks clarity that may compromise a= n > implementation. > >From the comments I made above, I will uniformize terms and delete specific algorithm explanations from the introduction. > I suggest adding more flow diagrams and trying to narrow and maybe put in > a table the configuration values of the mechanism. Also add the > mathematical formulation of the different computations that are conducted= . > The use of SF0THRESH and its relation to OVERPROVISION percentage needs t= o > be clarified. Also the mechanism that trigger the SF0 policy need to be > reviewed, and mention somehow how hysteresis is introduced to avoid > constant variations of the number of scheduled cells. > AFAIK, there are no configuration values except the PDR calculation. However, there are thresholds and parameters which are implementation-specific. I will add the missing flow diagram for the cell estimation algorithm as requested. As I mentioned above, there is no relation between SF0THRESH and OVERPROVISION. If there are available simulations that show one possible relationship, we can add it as a reference. I will remove the idea of hysteresis, and just mention that improves stability by reducing the number of transactions and scheduling events between nodes. > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > > =C2=AD > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a113f5f3eb0281b054f403bf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Xavi,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I answer to your com= ments inline. I am really grateful
for your comments, since most = the new version had not had
a detailed revision since the migrati= on from OTF to SF0.
Regards,

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Diego

2017-04-30 8:37 GMT-03:00 Xavi Vilajosana Guillen <xvilajosa= na@uoc.edu>:
Dear SF0 authors, all

I've gone through the SF0 d= raft (v04) published last Friday (28th April). Please find my constructive = comments after reading the document. I hope they are useful.=C2=A0

kind regards,
X
-------
Abstract:

allocated cells =C2=A0-> scheduled c= ells?

This belongs to the= OTF way of naming scheduled cells, I will update it.
=C2=A0

I= ntro:

=C2=A0- for the 6top sublayer =C2=A0-> us= ing the 6P protocol
=C2=A0- the minimal set of functionalities = =C2=A0-> what is the minimal set?=C2=A0
=C2=A0- The intro expl= ains that there are 2 algorithms. After this initial introduction the purpo= se of the algorithms is briefly explained. Here I suggest to add another se= ction for each of them and let the introduction just detail the goal of the= document and motivation of the decisions taken for this SF.

OK. I will move the explanations from t= he introduction to the current algorithm
description sections whi= ch already exist on the draft.
=C2=A0

=C2=A0- The description of th= e Sched. Alg. is somehow confusing.=C2=A0

=C2=A0&q= uot;The Scheduling Algorithm: A number of TX and/or RX cells must be
<= div>=C2=A0allocated between neighbor nodes in order to enable data transmis= sion
=C2=A0among them. A portion of these allocated cells will be= utilized by
=C2=A0neighbors,=C2=A0

- wh= at utilized by neighbors mean? do you refer that the cells will be used to = transmit packets/frames between the neighbors?

First, there is a difference between the allocated an used = cells: You can allocate a cell, and send a packet
over that cell = when the time arrives, or keep the cell without a packet during a slotframe= . So, in SF0 terms,
an allocated cell may or may not be used. I l= isten to suggestions to change the term "used" to a more=C2=A0
representative one.=C2=A0

Now, going to yo= ur comment, first, SF0 only requests the scheduling of TX cells to a neighb= our, which are
RX cells on the other side. There are no shared ce= lls since we have no clue on what the application(s) is(are)
runn= ing on the node is(are) doing. Then, RX cells is a mistake there.

The term "utilized" will be changed to "used= " or to the proposed way of calling them. When the correct term is
chosen, I will define it before this paragraph.=C2=A0
=C2= =A0

=C2=A0while the remaining cells can be over-provisioned to
=C2=A0handle unanticipated increases in cell requirements. "

-over-provisioning must be defined so everybody understand= s the concept.

OK. I will= define what overprovisioning stands for.
=C2=A0

=C2=A0The Sch= eduling Algorithm collects the cell allocation/deletion requests from the
=C2=A0neighbors and the number of cells which are currently under = usage .
=C2=A0First, the Cell Estimation

=C2=A0- Algotithm -> Algorithm

<= /div>
OK. Typo. It was hiding from me to survive in future versions, th= anks for catching it.
=C2=A0
=

=C2=A0calculates the number of re= quired cells by adding the collected values=C2=A0

= - What does this mean? what are the collected values? what is their meaning= ?

This phrase should go a= way, it has currently no application. In the former versions
we p= roposed that we were a part of a chain instead of having exclusively peer-t= o-peer
negotiation.=C2=A0
=C2=A0

=C2=A0and second, t= he =C2=A0calculated value is given to the Allocation Policy,
=C2= =A0 which provides stability by adding hystheresis and overprovisioning by = deciding when
=C2=A0to schedule the new number of cells, accordin= g to a threshold.

-Lots of information here. Maybe= explain a little bit better. Give details about why it gives stability and= how overprovisioning and hysteresis are used for that.=C2=A0
- A= lso it is not clear what is the role of the threshold here.

<= /div>

I will delete this phrase= for the sake of clarity.=C2=A0

=C2=A0
In order to = reduce consumption, this algorithm is triggered only when
=C2=A0t= here is a change on the number of effectively used cells

- assume later we will know how to calculate the number of effective= ly used cells.

The "= effectively used cells" term was coined originally to highlight that t= here is a huge
difference between allocating and using a cell. It= will be changed to "used" cells.=C2=A0
=C2=A0

or if= there is a change on the number of requested cells from a particular node.=

This will be removed. In= order to trigger SF0, we only look now at the number of used cells vs. the= allocated cells
from the node to any of the neighbours. Looking = into requests from other neighbours and relating this to a possible
traffic increase towards any of the remaining neighbours is not current.= This was the original idea when we could
identify a parent neigh= bour from a child neighbour. SF0 is now relative-agnostic.=C2=A0
= =C2=A0

<= /div>
=C2=A0"A relocation is
=C2=A0triggered when the PD= R value drops below a certain threshold,
=C2=A0compared to the av= erage PDR of the rest of allocated cells. The
=C2=A0destination l= ocation on the schedule is defined randomly."

=C2=A0- this assertion is central to the document, seems like this is one = of the major key points of the document. As said before, for me this should= not be in the introduction bu in a dedicated section explaining how reloac= tion works.

Relocation is= defined on section 4.3.3 of 6P. We only define here that we trigger
<= div>that mechanism when an user-defined PDR threshold is reached, compared = to
the average PDR of all the other cells. Now, we do not go deep= on how the average
PDR is calculated (it may =C2=A0be calculated= from the average PDR of all the cells where
statistics are avail= able except from the blacklisted ones). We also state that the
re= placement cell will be selected randomly among the unscheduled ones.=C2=A0<= /div>
We do not define retries. If it fails, this will be retriggered o= n the next slotframe
and a retry will be issued.=C2=A0
= =C2=A0

<= /div>
=C2=A0Section "Scheduling Function Identifier"

=C2=A0should not be: IANA_SFID_SF0 -> IANA_6TiSCH_SFID_= SF0.

OK.
=C2=A0=

<= div>=C2=A0Section "SF0 Triggering Events"

=C2=A01. If there is a change in the current number of required cells
=C2=A0
- is this triggered by what? 6P allocation? queue s= ize? increase on cell usage?

<= div>change on the number of used cells towards any of the neighbours.=
=C2=A0
<= div>
=C2=A02. If there is a successful cell allocation/deallo= cation process
=C2=A0with the neighbour.

-A cell allocation is a result of a decision taken in a previous step, i.e= some algorithm has decided that more cells are needed and those are alloca= ted. Then after the allocation the algorithm is triggered again. Could you = clarify in the text what is the purpose?


This will be deleted now. As I explained bef= ore, we do not look on the
other neighbours just in case this may= mean that a new allocation
will be reflected on any of the remai= ning neighbours.
=C2=A0
=C2=A0This allows SF0 to be triggered by a= ny change in locally generated or
=C2=A0incoming traffic. The exa= ct mechanism of when SF0 is triggered is
=C2=A0implementation-spe= cific.

no incoming traffi= c triggering. Candidate for deletion.
=C2=A0

Section "SF0= Cell Estimation Algorithm"

The Cell Estimati= on Algorithm takes into account the new incoming
=C2=A0cell requi= rements

- define somewhere what incoming cell requ= irements are?

I will dele= te this line.
=C2=A0

=C2=A0 from the neighbor node and the cur= rent outgoing number of used cells.

- idem, define= outgoing

only used vs. s= cheduled, no outgoing.
=C2=A0
=C2=A0
=C2=A0 This allows the algorithm to= estimate a new
=C2=A0number of cells to be allocated. As a c= onsequence, the Cell
=C2=A0Estimation Algorithm for SF0 follows t= he steps described below:
=C2=A01. Collect the current number of = used cells

=C2=A0-to the particular neighbor or in= total in its schedule?

to the = particular neighbour. We are always scheduling to a single neighbour at a t= ime,
except for relocation, which monitors the whole schedule and= relocates accordingly.
=C2=A0

=C2=A02. Calculate the new number of= cells to be allocated by adding the
=C2=A0current number of used= cells plus an OVERPROVISION number of
=C2=A0cells
- Co= nsidering the cells in the schedule, how the current number of used cells a= re identified?

There should be = statistics from the last slotframe on the number of=C2=A0
used ce= lls (vs, the number of scheduled cells) towards each of the neighbours. But= this
is implementation specific and SF0 does not specify how thi= s is collected.
=C2=A0

=C2=A03. Submit the request to the allocatio= n policy as REQUIREDCELLS
- explain better. What is submitted? is= this a function call? Does this mean, "indicate to the allocation pol= icy the required cells".

I= like "transferred". Function calls are not a matter of SF0, but = it can be implemented that way.
=C2=A0

=C2=A04. Return to step 1 an= d wait for a triggering event.

- Maybe a flow diag= ram would be a good complement to clarify its use.
=

OK.
=C2=A0

=C2=A0The OVERPROVISION parameter is= a percentage of the

=C2=A0 currently allocated ce= lls =C2=A0-> number of currently allocated cells



OK. This was propose= d by Tengfei, but I have not seen tested yet compared to a fixed implementa= tion-specific value.
=C2=A0
<= div dir=3D"ltr">
- Why this link here. Maybe use a . and sta= rt a new sentence.
e.g., The OVERPROVISION value is added to the = used cells parameter ...

OK
=C2=A0
=C2=A0 which is added to the used cells to guarantee that
=
=C2=A0the growth on the number of used cells can be detected without p= acket
=C2=A0loss. This percentage value is implementation-specifi= c.=C2=A0

=C2=A0A value of
=C2=A0OVERPROV= ISION equal to zero leads to queue growth and possible packet
=C2= =A0loss, since there are no overprovisioned cells to detect if there is
=C2=A0a growth on the number of used cells.

=C2=A0-clarify this.
=C2=A0 =C2=A0 - 1) if no overprovision then= no extra cells in the schedule to cope with sudden increments or unexpecte= d retransmissions
=C2=A0 =C2=A0 - 2) this may cause the queue to = grow and eventually drop packets.

I wouldn't use retransmissions. SF0 should not to retransmit anythin= g, we only retrigger SF0
in case of failure. I think it could be = better to say sudden increment in traffic towards the neighbour.
= But 1) and 2) are connected: no overprovisioned cells -> queue growth ca= n lead to packet loss.=C2=A0
=C2=A0


=C2=A0Section &q= uot;SF0 allocation policy"

=C2=A0The "Al= location Policy" is the set of rules used by SF0 to decide
= =C2=A0when to add/delete cells to a particular neighbor to satisfy the cell=
=C2=A0requirements.

=C2=A0SF0 uses the = following parameters:
=C2=A0
=C2=A0SCHEDULEDCELLS: The = number of cells scheduled from the current node
=C2=A0to a partic= ular neighbor.

=C2=A0REQUIREDCELLS: The number of = cells calculated by the Cell Estimation
=C2=A0Algorithm from the = current node to that neighbor.

=C2=A0SF0THRESH: Th= reshold parameter introducing cell over-provisioning in
=C2=A0the= allocation policy.

- what is the relation of this= with OVERPROVISION percentage in the previous section?

There is no relation. We keep both independent on = purpose. One decides the number
of cells to be scheduled, the oth= er decides when. This avoids instability by adding
hysteresis, bu= t the allocation policy does not care on how the number of requested cells = was
chosen by the cell estimation algorithm.

=
This is one of the strong points of SF0. We have completely changed th= e estimation
algorithm from one which had most information (knew = about child, parent, cell application
requests) to one that only = knows the number of used cells vs. the scheduled cells. and
the a= llocation policy did not change.
=C2=A0

Section "Rules for Cel= llist"

How do you handle error situations? is= there a retry-policy?

With res= pect to the retry policy, if the required cells are not satisfied, SF0 will= be retriggered.=C2=A0
The only condition (I find) we have not ta= ken into account is when the schedule is full,
and I have comment= ed that several times without answer.
We can specify here a numbe= r of transactions taking advantage of the celllist response
with = the available cells (given the number of requested cells for allocation), a= s a better
policy than choosing randomly each time SF0 is retrigg= ered.
=C2=A0
=C2=A0
Section "6P Timeout value"

<= /div>
"The general timeout equals the equivalent time of the numbe= r of slots until the next scheduled cell."

- = I assume this is from the moment the transaction starts. Isn't it? Plea= se clarify in the description.
- Could you elaborate why this dec= ision?=C2=A0

I truly believe th= e timeout calculation does not belong to SF0, but to 6P. That is why this s= entence
is there. We have tried several schemes, but, in the end,= they depend on the transactions at the 6P=C2=A0
level. From my p= oint of view, the only reason here is that if a transaction fails during a = slotframe,
it will be retriggered in the next. =C2=A0
= =C2=A0

=
Section SF0 Statistics

-I do not understand t= he PDR definition

Packet Delivery Rate (PDR) is ca= lculated per cell, as the quotient of
=C2=A0the number of success= fully delivered packets to 10

what is 10? is this = how many of the last 10 have been acknowledged?

Succesfully delivered packets is acknowledged. I can chang= e the term, no problem if=C2=A0
it clarifies the idea. "to 1= 0" will be deleted.
=C2=A0

=C2=A0, for the last 10
= =C2=A0packet transmission attempts, without counting retransmissions.
=



Section "Relocating = Cells"

=C2=A0 ... PDR_THRESHOLD, defined as a= percentage of the
=C2=A0average of the PDR of the rest of the sc= heduled cells

=C2=A0-Could you express this in a f= unction? What percentage it is?=C2=A0
=C2=A0-If PDR_THRESHOLD is = defined as indicated above, why later it is stated that "PDR_THRESHOLD= is out of the scope of this document and it is
=C2=A0implementat= ion-dependent."

Because it= is implementation specific. I will delete the former sentence.
= =C2=A0

=
General comments:

the document introduces the= main ideas for SF0 but IMHO it needs some editorial work to clarify the fu= nctionalities and do not mix concepts during the explanation, in general it= lacks clarity that may compromise an implementation.

From the comments I made above, I will uniformize te= rms and delete specific algorithm explanations from the introduction.
=

=C2=A0
I suggest adding more flow diagrams and trying to narrow and mayb= e put in a table the configuration values of the mechanism. Also add the ma= thematical formulation of the different computations that are conducted. Th= e use of SF0THRESH and its relation to OVERPROVISION percentage needs to be= clarified. Also the mechanism that trigger the SF0 policy need to be revie= wed, and mention somehow how hysteresis is introduced to avoid constant var= iations of the number of scheduled cells.

=
AFAIK, there are no configuration values except the PDR calculat= ion. However, there are thresholds and parameters which are implementation-= specific. I will add the missing flow diagram for the cell estimation algor= ithm as requested. As I mentioned above, there is no relation between SF0TH= RESH and OVERPROVISION. If there are available simulations that show one po= ssible relationship, we can add it as a reference. I will remove the idea o= f hysteresis, and just mention that improves stability by reducing the numb= er of transactions and scheduling events between nodes.
=C2=A0


=

--
=
Dr. Xavier Vilajosana
Wireless Networks Lab
I= nternet Interdisciplinary Institute (IN3)
Professor

(+34) = 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la T= ecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelld= efels (Barcelona). Catalonia. Spain
3D"Universitat=C2=A0=C2=A0

=C2=AD
<= /div>

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
DIEGO DUJOVNE
Profesor = Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de= Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2= ) 676 8125
--001a113f5f3eb0281b054f403bf7-- From nobody Fri May 12 08:08:44 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F378B126D85 for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 73LMJ2qkf2bg for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:08:41 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43A8812EB50 for <6tisch@ietf.org>; Fri, 12 May 2017 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36114; q=dns/txt; s=iport; t=1494601381; x=1495810981; h=from:to:subject:date:message-id:mime-version; bh=qzJ/g07GjyuTsnFWy844HpGNAOX0yKIDe/vkD6p6EMM=; b=jUSwFn5Nre1SindOFy/J1wHSXSZT/QWG6PVOR6kKYnPGadePz74WVjUk xoV2QFqGvd91nPbm71HvuDBBxt8zm94+kAd3SD00WHTsCct5MF8CP2Cxo zKjUIBVrAOZL+VEKSe407+CMcsgt1CqYElQqJ5+GhIfcD0jRSX1MgHM5+ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQAzzhVZ/5RdJa1CGhwBAQQBAQoBA?= =?us-ascii?q?YJuPCtigQwHjXynUoIPLoV2hRs/GAECAQEBAQEBAWsdC4VMXgEcHAgBAzwmAQQ?= =?us-ascii?q?bEooJDjGfApIxg1WGeAEBAQEBAQEDAQEBAQEBAQEghl+BXoRXgWWBEwsHAQwwL?= =?us-ascii?q?oIHgx0FngoBhxuLdoINj2eIf4tDAR84fwtwFUaEcwMcgWN2AQSGKQ8XgQqBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.38,330,1491264000"; d="scan'208,217";a="423761095" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2017 15:03:00 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v4CF30O0029248 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <6tisch@ietf.org>; Fri, 12 May 2017 15:03:00 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 12 May 2017 10:02:59 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 12 May 2017 10:02:59 -0500 From: "Pascal Thubert (pthubert)" To: "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: Minutes, 12 May 2017 interim, 6TiSCH WG Thread-Index: AdLLMIZdi8ln21tGQ4e/3XLEmN0l4Q== Date: Fri, 12 May 2017 15:02:51 +0000 Deferred-Delivery: Fri, 12 May 2017 15:02:09 +0000 Message-ID: <748c7ed7a26b44a694834b637235bb8e@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.21] Content-Type: multipart/alternative; boundary="_000_748c7ed7a26b44a694834b637235bb8eXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [6tisch] Minutes, 12 May 2017 interim, 6TiSCH WG X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:08:43 -0000 --_000_748c7ed7a26b44a694834b637235bb8eXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Note: timestamps in PDT. Connection details * Date: 7-8am Pacific: http://www.worldtimebuddy.com/?qm=3D1&lid=3D100,= 12,5392171,1850147&h=3D100&date=3D2017-05-12&sln=3D14-15 * Webex link: https://cisco.webex.com/ciscosales/j.php?MTID=3Dmcdbbe3a4= e38d97d986b507ec12a1f9b1 * Webex Recording: https://cisco.webex.com/ciscosales/lsr.php?RCID=3D01= 514b03f5304ff6bbc0ae87d44b4bcf * Recording password: Zj22kx7d * Material link: https://bitbucket.org/6tisch/meetings/raw/master/17051= 2_webex/slides_170512_webex.ppt Present (previous meeting) 1. Thomas Watteyne 2. Pascal Thubert 3. A Paventhan 4. Diego Dujovne 5. Jonathan Munoz 6. Malisa Vucinic 7. Malisa Vucinic 8. Maria Rita Palattella 9. Michael Richardson 10. Remy Leone 11. Sumankumar Panchal 12. Tengfei Chang 13. Yasuyuki Tanaka Action Items (previous meeting) * Thomas to contact Carsten * Thomas to contact Maria Rita and Miguel and coordinate PlugTest * Xavi and Qin to review SF0 * Jonathan to review 6P after Charlie's comments are addressed * Xavi and Qin to address Charlie's comments * Xavi to bootrap research liaison * Diego to write an email and open a ticket to track the issues between= SF and 6P Taking notes (using Etherpad) 1. Pascal Thubert 2. Thomas Watteyne Action Items * Diego to start a thread on time out computation between SF0 and 6P. W= hether ASN of the time out should be indicated in the packet. Agenda * Administrivia [ 7min] * Agenda bashing * Approval minutes from last meeting * Addressing todo's from last time * News from PlugTest * 6P finalization (Thomas, Qin) [20min] * SF0 finalization (Diego) [20min] * Update on security (Michael/Malisa) [ 5min] * AOB [ 3min] Minutes * [07:05]Administrivia [ 7min] * Agenda bashing * Approval minutes from last meeting =3D> Approved * Minutes of last meeting; this agenda approval * [Michael] "MR" in the todos refers to Maria Rita, not Michael R= ichardson * no other comments * Addressing todo from last time * News from PlugTest * [7:12] 6P finalization (Qin) [20min] * Addressing Charlie's comments, most of them accepted * Qin: Charlie suggests a terminology section. We have a terminology= document. * Tech comments are addressed one by one, list below. * TW: metadata is not always the same but is limited to 2 bytes * Qin: How to express in the draft. We say same usage, gives impress= ion that the meta data is the same. * Thomas: we may say same usage but not same content * Qin: OK * Qin: On 6P vs. SF0, some considerations being potentially impracti= cla. need to chat with SF0 people to address feasibility. * Thomas: about aggregating SFs, well not supported * Thomas: Registry does not exist, lost cause to start one now. * Diego: there was also the requiremtn to define time out but I thin= k it does not belong to SF0. Should be in 6P. SF0 has no tools to defined t= ime outs. * Thomas: Why * Diego: we do not know how long to wait. Would that be the longest = time possible? Impractical. Each transaction may be different. SF0 can hand= le the time out but not compute the value of the timer. * Thomas: The time out depend on the schedule * Qin: different SF will have a same or different values? * Thomas: the SF may know that it needs an adiitional delay. * Diego: SF0 has no control of the duration * Pascal: 6P could return a duration when SF0 sends a packet and SF0= includes that in its time out. * Pascal: SF on node A adds in the request the ASN of the time out * Thomas yes we need a thread on that * [7:42] SF0 finalization (Diego) [20min] * Diego: there were discussions on terms and functions (too fast for= minute taker, see recording). * there are 2 proposed algorithms; very different from one another. = The changes only impact the first. One passes data to the other, that was c= larified. * Qin: Initial status of SF0? What time are overprovisionned cells a= dded? * initial status is 0 cells. We are only having overprovisionned tha= t were used cells in previous instance (next time). * Thomas: figure 1 on page 5 * [7:52] Update on security (Michael/Malisa) [ 5min] * Michael has no update at this time * [7:57] AOB --_000_748c7ed7a26b44a694834b637235bb8eXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Note: timestamps in PDT.

Connection details=

Present (previous m= eeting)

  1. Thomas Watteyne
  2. Pascal Thubert
  3. A Paventhan
  4. Diego Dujovne
  5. Jonathan Munoz
  6. Malisa Vucinic
  7. Malisa Vucinic
  8. Maria Rita Palattella
  9. Michael Richardson
  10. Remy Leone
  11. Sumankumar Panchal
  12. Tengfei Chang
  13. Yasuyuki Tanaka

Action Items (= previous meeting)

  • Thomas to contact Carsten
  • Thomas to contact Maria Rita and Miguel and coordinate PlugTest<= /li>
  • Xavi and Qin to review SF0
  • Jonathan to review 6P after Charlie's comments are addressed
  • Xavi and Qin to address Charlie's comments
  • Xavi to bootrap research liaison
  • Diego to write an email and open a ticket to track the issues between SF an= d 6P

Taking notes (us= ing Etherpad)

  1. Pascal Thubert
  2. Thomas Watteyne

Action Items

  • Diego to start a thread on time out computation between SF0 and 6P. Whether= ASN of the time out should be indicated in the packet.
  • Agenda

    <= span style=3D"mso-list:Ignore">·        Administrivia [ 7min]

      • Agenda bashing
      • Approval minutes from last meeting
      • =
      • Addressing todo's from last time
      • News from PlugTest

    <= span style=3D"mso-list:Ignore">·        6P finalization (Thomas, Qin) [20min]

    • SF0 finalization (Diego) [20min]
    • Update on security (Michael/Malisa) [ 5min]
    • AOB [ 3min]

    Minutes

    • [07:05]Administrivia [ 7min]
      • Agenda bashing
      • Approval minutes from last meeting =3D> Approved
      • Minutes of last meeting; this agenda approval
        • [Michael] "MR" in the todos refers to Maria Rita, not Michael Ric= hardson
        • no other comments
      • Addressing todo from last time
      • News from PlugTest

    <= span style=3D"mso-list:Ignore">·        [7:12] 6P finalization (Qin) [20min]

      • Addressing Charlie's comments, most of them accepted
      • Qin: Charlie suggests a terminology section. We have a terminology document= .
      • Tech comments are addressed one by one, list below.
      • TW: metadata is not always the same but is limited to 2 bytes
      • Qin: How to express in the draft. We say same usage, gives impression that = the meta data is the same.
      • Thomas: we may say same usage but not same content
      • Qin: OK
      • Qin: On 6P vs. SF0, some considerations being potentially impracticla. need= to chat with SF0 people to address feasibility.
      • Thomas: about aggregating SFs, well not supported
      • Thomas: Registry does not exist, lost cause to start one now.
      • Diego: there was also the requiremtn to define time out but I think it does= not belong to SF0. Should be in 6P. SF0 has no tools to defined time outs.=
      • Thomas: Why
      • Diego: we do not know how long to wait. Would that be the longest time poss= ible? Impractical. Each transaction may be different. SF0 can handle the ti= me out but not compute the value of the timer.
      • Thomas: The time out depend on the schedule
      • Qin: different SF will have a same or different values?
      • Thomas: the SF may know that it needs an adiitional delay.
      • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l5 level2 lfo7"> Diego: SF0 has no control of the duration
      • Pascal: 6P could return a duration when SF0 sends a packet and SF0 includes= that in its time out.
      • Pascal: SF on node A adds in the request the ASN of the time out=
      • Thomas yes we need a thread on that

    <= span style=3D"mso-list:Ignore">·        [7:42] SF0 finalization (Diego) [20min]=

      • Diego: there were discussions on terms and functions (too fast for minute t= aker, see recording).
      • there are 2 proposed algorithms; very different from one another. The chang= es only impact the first. One passes data to the other, that was clarified.=
      • Qin: Initial status of SF0? What time are overprovisionned cells added?
      • initial status is 0 cells. We are only having overprovisionned that were us= ed cells in previous instance (next time).
      • Thomas: figure 1 on page 5

    <= span style=3D"mso-list:Ignore">·        [7:52] Update on security (Michael/Malisa) [= 5min]

      • Michael has no update at this time

    <= span style=3D"mso-list:Ignore">·        [7:57] AOB

     

--_000_748c7ed7a26b44a694834b637235bb8eXCHRCD001ciscocom_-- From nobody Fri May 12 08:09:36 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A812EB69 for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com 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 9UwyquJpu9Qi for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:09:32 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E58F5129C62 for <6tisch@ietf.org>; Fri, 12 May 2017 08:03:54 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id l135so12276802ywb.2 for <6tisch@ietf.org>; Fri, 12 May 2017 08:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2DTkljZpF36cenGCMqEHu3VWdNn/YrR9ae2NNcVTf2U=; b=nvP7yrWoz8BCgQjyZRKyRPNa572it5V/PWC6mjEKsPJEdV3JyjP+NaauujsVo4M7V6 jnQgR16UoSqO95TY/TK5Qcj/Y6ZmGUNm8zatQhukp4Xj/wQdn6ExBN3kBGg/Gme7SuX+ A7Rm4HIcLrq36j/duBMDDcrmKMmotVAb2OH7s5ePTnVefvUBVs5BYK4G7cAplXAbzdlK SIaDN447D5tgoBs3VUlwUqvUl4MxOUAbmXRe0zFf/TrZ1l4oXfNANeyT6N6j5RZ033v5 nwfzOHceai6Hbw08Roj4y5WJQleiyGyLfSHUeIiEollX0b0rlbdcVW26uv8sXVqnXEfo DwWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2DTkljZpF36cenGCMqEHu3VWdNn/YrR9ae2NNcVTf2U=; b=YeC8yqDT8UbYmbM4gmtFUNSN9fNJ9AOFDIph4XjnnR1dvKtwhwR57hDFZKZ40oY90Q mEPm/8BrDyzKypwc2PDj8x4evdTuQJYv5U31Jz/FMuVaeScJ7Eq4D24VlTt/agMKfR/p fT265WU7neoTp3tSesgERyP6DovupA5hXhetGRMldBLp/9PZQVAmqRt4kJ3ilx5/E/zS /XUu98fSeSDZw0oANmdjfkNU5DwmN+2QY/1+4ul3gvdYUJDoVBIGXr7PJ6mB9zLQLHPY F05qcFBb7BOHDQF5u9dBVpSf/nEZFg3Td2uPl2zwLfgb5c0CezWkX10ypioBcabyBf8r x2Ug== X-Gm-Message-State: AODbwcCwqmHwS+x4BTY7Fn97bdAJGAJ4XYfXbvJ+fKn0B4aA285WuRIK TsIdGVaA17pGFqbjSxfIdgHcD5nY8Q== X-Received: by 10.13.246.198 with SMTP id g189mr3968599ywf.156.1494601433793; Fri, 12 May 2017 08:03:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.136.134 with HTTP; Fri, 12 May 2017 08:03:33 -0700 (PDT) From: "Prof. Diego Dujovne" Date: Fri, 12 May 2017 12:03:33 -0300 Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="94eb2c0331888ae3ca054f55034f" Archived-At: Subject: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:09:35 -0000 --94eb2c0331888ae3ca054f55034f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, During today's Webex call we discussed transaction timeout implementation problems. As a result, the proposed solution is that SF will include a TTL field with the timeout value that the SF will wait to finish the transaction. This will avoid inconsistencies if the transaction is delayed due to retransmissions or intermediate queues. As a consequence, the timeout value will be implementation-specific. Let me know if you agree in this item. Regards, Diego --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --94eb2c0331888ae3ca054f55034f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 During today's Webex call we di= scussed transaction
timeout implementation problems. As a res= ult, the proposed
solution is that SF will include a TTL fiel= d with the timeout
value that the SF will wait to finish the transactio= n.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 This will avoid inconsistencies if the transaction
= is delayed due to retransmissions or intermediate queues.
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As a conseq= uence, the timeout value will be
implementation-specific.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let me = know if you agree in this item.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego



--
DIEGO= DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunica= ciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile<= br>www.ingenieri= a.udp.cl
(56 2) 676 8125
--94eb2c0331888ae3ca054f55034f-- From nobody Fri May 12 08:40:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A31A12ECA4 for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.009 X-Spam-Level: *** X-Spam-Status: No, score=3.009 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 hGOFmk6GH-TQ for <6tisch@ietfa.amsl.com>; Fri, 12 May 2017 08:40:55 -0700 (PDT) Received: from sonic305-24.consmr.mail.ne1.yahoo.com (sonic305-24.consmr.mail.ne1.yahoo.com [66.163.185.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5E0129434 for <6tisch@ietf.org>; Fri, 12 May 2017 08:35:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1494603340; bh=52LBb1scU3Z10vaNFszsDNIlJvpvD883Ti2m3qMNJZE=; h=Date:From:Reply-To:To:Subject:References:From:Subject; b=QQDXY5klaqhgRTO7NdivipE/hFx8YUNDkAaXO1r/V33uI/gi27Ps5uPnbXYMvmwtqqg5UaguDfWS+4TLAwl/dduL7KAlnly22f7ra9i2GM+PS2PJHJAt1VMydknJri2qaPekYARDQzoAWw8nq/IwJmhc9MZUZVK3uTSWv9qT9LLnKgeiy7FL8v0QjBsD1tMWFuI/mC7tHC61VzneW3tvLcTW87+zoAoYWUUXYjFYPQnLi2IFFfKQuyja6fvahSqaB6qoMzPzpJEJdp7xK43VrCPjkkw49kpnUD64hnaAu/XAceIInclAPHkogcil9F1srpiPdsN+Yq/JtQMEnbmJpg== X-YMail-OSG: 2.cVZ58VM1ldG5mQv6sl0tuGXBIG95QbP6WRnc7sOz.THq8YcBes.xUp0uYMvV0 V58.0.T0CdGMvEIZsAOizulr322lT4WxXFAUfLvPRqYYhjgxVsbcYzlMtThJ309y2B1HsiY34lxm izBFD8ofSdPSdPEkclz0yh684xQtB1Nkt5gmO38Q7dPoHRT1FuiSXuFeepI1s1ggRAYMw5fi8WV_ eoDv.rtzbDokO5a5N1xFBSDm0g88a9IgzzUj0bccGoXZqtcf0Fw8ynfRFsFIixRT6XKAaBuS4BIa .vg6SxBCq9Gk4OICPLkqh3WtfXkPsIoVmatCCukVmPZ8MZmsln2L_chTViVqmUzKm8lXNxxiTZ5s C7lhZcYDZ4Fvvojfn6tLxwuhpmhJ49vTlNO2LGr31g63J6CGONC84UktIhJFEmZtCU0D.9fpYtTK LFoQlDKhiTTgyFCITtGNbIMWtE2_NyVnLD6YKTciwA8gc434HO4wYZt0yp3gKttoVF318zJqtKQi eR6tDKKQGmUIPeGLTFdtnd49zJ10w3v2s5UU- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 12 May 2017 15:35:40 +0000 Date: Fri, 12 May 2017 15:35:13 +0000 (UTC) From: Qin Wang Reply-To: Qin Wang To: "Prof. Diego Dujovne" , 6TiSCH Mailing List <6tisch@ietf.org> Message-ID: <1518731540.732434.1494603313592@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_732433_619945655.1494603313590" References: <1518731540.732434.1494603313592.ref@mail.yahoo.com> X-Mailer: WebService/1.1.9641 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: [6tisch] consideration on initial status in Figure 1, SF0 draft X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 15:40:56 -0000 ------=_Part_732433_619945655.1494603313590 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Diego, Just below Figure 1, the text is as follows. ---------------------------------------------------------------------1. =C2= =A0If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more=C2=A0 = =C2=A0 =C2=A0 =C2=A0cells.2. =C2=A0If (SCHEDULEDCELLS-SF0THRESH)<=3DREQUIRE= DCELLS<=3DSCHEDULEDCELLS, do=C2=A0 =C2=A0 =C2=A0 =C2=A0nothing.3. =C2=A0If = SCHEDULEDCELLS<=3DREQUIREDCELLS, add one or more cells.--------------------= ------------------------------------------------- I'm not very clear how it works. Here is my questions:1) what is the initia= l value of SCHEDULEDCELLS, SF0THRESH?2) what do you mean by " delete one or= more cells" and "delete one or more cells"? Is there any formula to determ= ine the number of cells to ADD/DELETE?3) After ADD or DELETE N cells, how t= o change SF0THRESH? ThanksQin ------=_Part_732433_619945655.1494603313590 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Diego,

Just below Figure 1, the text is as fo= llows.

----------------------------= -----------------------------------------
1.  If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRES= H), delete one or more
       cells.
2.  If (SCHEDULEDCELLS-SF0THRESH)<=3DREQUIREDCELLS= <=3DSCHEDULEDCELLS, do
       nothing.
3.  If SCHEDULEDCELLS<=3DREQUIRED= CELLS, add one or more cells.
-----------------------------------------------------= ----------------

I'm not very clear how it works. Here is my questions:
1) what is the initia= l value of SCHEDULEDCELLS, SF0THRESH?
2) what do you mean by " delete one or more c= ells" and "delete one or more cells"? Is there any formula to determine the= number of cells to ADD/DELETE?
3) After ADD or DELETE N cells, how to change SF0TH= RESH?
Thank= s
Qin

=


= ------=_Part_732433_619945655.1494603313590-- From nobody Mon May 15 03:46:14 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4319612EAE1 for <6tisch@ietfa.amsl.com>; Mon, 15 May 2017 03:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 pIJjsrhxuzp8 for <6tisch@ietfa.amsl.com>; Mon, 15 May 2017 03:46:07 -0700 (PDT) Received: from mailsender.cdac.in (mailsender.cdac.in [196.1.113.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A54C2129C06 for <6tisch@ietf.org>; Mon, 15 May 2017 03:41:57 -0700 (PDT) Received: from ims.pune.cdac.in (ims.pune.cdac.in [10.208.1.15]) by mailsender.cdac.in (8.14.2/8.14.2) with ESMTP id v4FAfXEE016806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2017 16:11:33 +0530 Received: from mailgw.pune.cdac.in ([10.208.1.4]) by ims.pune.cdac.in (8.14.4/8.14.4) with ESMTP id v4FAf220000465; Mon, 15 May 2017 16:11:02 +0530 X-AuthUser: lijo Received: from CIGLIJO (cig_lijo.tvm.cdac.in [10.176.11.63]) (authenticated bits=0) by mailgw.pune.cdac.in (8.14.2/8.13.8) with ESMTP id v4FAf0fS001276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Mon, 15 May 2017 16:11:01 +0530 From: "Lijo Thomas" To: "'Prof. Diego Dujovne'" , <6tisch@ietf.org> References: In-Reply-To: Date: Mon, 15 May 2017 16:13:28 +0530 Message-ID: <011101d2cd68$17444a50$45ccdef0$@cdac.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0112_01D2CD96.30FF9390" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJJKnv/fstROSOAKPeu9bvgmBGswKEIedVQ Content-Language: en-in X-CDAC-PUNE-MailScanner-ID: v4FAf220000465 X-CDAC-PUNE-MailScanner: Found to be clean, Found to be clean X-CDAC-PUNE-MailScanner-MCPCheck-IMS: MCP-Clean, MCP-Checker (score=0, required 1) X-CDAC-PUNE-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.199, required 6, autolearn=disabled, ALL_TRUSTED -1.00, BAYES_50 0.80, HTML_MESSAGE 0.00, RP_MATCHES_RCVD -0.00, URIBL_BLOCKED 0.00), not spam, SpamAssassin (not cached, score=-2.539, required 6, autolearn=disabled, ALL_TRUSTED -1.80, BAYES_20 -0.74, HTML_MESSAGE 0.00) X-CDAC-PUNE-MailScanner-Information: Please contact npsfhelp@cdac.in/mailadmin@cdac.in for more information X-MailScanner-ID: v4FAfXEE016806 X-CDAC-PUNE-MailScanner-From: lijo@cdac.in X-CDAC-MailScanner-Spam-Status: No Archived-At: Subject: Re: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 10:46:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0112_01D2CD96.30FF9390 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Diego, =20 As SF0 address a scheduling scheme, it would be better if the algorithm sug= gest the values. =20 Or maybe you could detail it with an example or a flow diagram.=20 =20 =20 Thanks & Regards, Lijo Thomas=20 =20 =20 From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Prof. Diego Dujo= vne Sent: 12 May 2017 20:34 To: 6tisch@ietf.org Subject: [6tisch] Timeout implementation on 6P/SF0 =20 Dear all, During today's Webex call we discussed transaction timeout implementation problems. As a result, the proposed solution is that SF will include a TTL field with the timeout=20 value that the SF will wait to finish the transaction. This will avoid inconsistencies if the transaction is delayed due to retransmissions or intermediate queues. As a consequence, the timeout value will be=20 implementation-specific. Let me know if you agree in this item.=20 Regards, Diego --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl =20 (56 2) 676 8125 ---------------------------------------------------------------------------= ---------------------------------------------------- [ C-DAC is on Social-Media too. Kindly follow us at: Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ---------------------------------------------------------------------------= ---------------------------------------------------- ------=_NextPart_000_0112_01D2CD96.30FF9390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Diego,

 

As SF0 address a scheduling scheme, = it would be better if the algorithm suggest the values.

 <= /span>

Or maybe y= ou could detail it with an example or a flow diagram.

 

 

Thanks & Regards,

Lijo Thomas

 

=

 

From: 6tisch [mailto= :6tisch-bounces@ietf.org] On Behalf Of Prof. Diego Dujovne
Sen= t: 12 May 2017 20:34
To: 6tisch@ietf.org
Subject: [= 6tisch] Timeout implementation on 6P/SF0

 

Dear all,<= o:p>

     &nbs= p;      During today's Webex call we discussed tra= nsaction

timeout implementati= on problems. As a result, the proposed

solution is that SF will include a TTL field with the timeout value that the SF will wait to finish the transaction.

        =     This will avoid inconsistencies if the transaction<= /o:p>

is delayed due to retransmissions = or intermediate queues.

 = ;           As a conseque= nce, the timeout value will be
implementation-specific.

<= /div>

       &n= bsp;    Let me know if you agree in this item.

 &nbs= p;          Regards,

      &n= bsp;            = ;            &n= bsp; Diego




--

DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3= =A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad D= iego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

<= /div>

----= ---------------------------------------------------------------------------= ------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and des= troy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this em= ail
is strictly prohibited and appropriate legal action will be taken.
---------------------------------------------------------------------= ---------------------------------------------------------- ------=_NextPart_000_0112_01D2CD96.30FF9390-- From nobody Fri May 19 02:16:47 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF12012EBCA for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=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 UwDFgGB-8GSD for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 02:16:42 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3EF12ECBD for <6tisch@ietf.org>; Fri, 19 May 2017 02:10:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,363,1491256800"; d="scan'208,217";a="224189943" Received: from mail-yb0-f171.google.com ([209.85.213.171]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 19 May 2017 11:09:59 +0200 Received: by mail-yb0-f171.google.com with SMTP id s22so16290789ybe.3 for <6tisch@ietf.org>; Fri, 19 May 2017 02:09:59 -0700 (PDT) X-Gm-Message-State: AODbwcDw18+IzYIwCj6ResoBfNNkV9aEfU3Xg5NVlUdYa+OvjS9GZjBW PPtt8juJV5o2rtx1nKV9T8frq0sYAQ== X-Received: by 10.37.175.142 with SMTP id g14mr192478ybh.85.1495184997920; Fri, 19 May 2017 02:09:57 -0700 (PDT) MIME-Version: 1.0 From: Remy Leone Date: Fri, 19 May 2017 09:09:47 +0000 X-Gmail-Original-Message-ID: Message-ID: To: 6TiSCH mailing list <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="089e08245670acbd45054fdce2a9" Archived-At: Subject: [6tisch] First pass upon the test description X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 09:16:45 -0000 --089e08245670acbd45054fdce2a9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I've reviewed the 6TiSCH test description and I got some suggestions that I've written as issues: https://bitbucket.org/6tisch/td-6tisch/issues?status=3Dnew&status=3Dopen Could you please comment, open new issues if you see some. My goal is to have as many test descriptions phrased with Falsifiable assertions that can be translated easily within a program. Best regards R=C3=A9my --089e08245670acbd45054fdce2a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've reviewed the 6TiSCH tes= t description and I got some suggestions that I've written as issues:


C= ould you please comment, open new issues if you see some. My goal is to hav= e as many test descriptions phrased with Falsifiable assertions that can be= =C2=A0translated easily within a program.

Best regards

R=C3=A9my
--089e08245670acbd45054fdce2a9-- From nobody Fri May 19 08:29:33 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D08127B60 for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 08:29:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu 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 5C2Xi2yJiizo for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 08:29:28 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F59B128AFE for <6tisch@ietf.org>; Fri, 19 May 2017 08:29:28 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id n23so41423092pfb.2 for <6tisch@ietf.org>; Fri, 19 May 2017 08:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IVEX5RJRiVJvMSlOQ9Ye3n54VfafyVql70nFb+/HK98=; b=X5O4PoMsYacbMWQsIhfINCdnBQu0RpQSjy75EpbjLEcJ8lV43dpfaRw8bf0KK2OqOt BMu/7q5cTIut6V98hIyi6UQPDr/mfc96SLwwOer4jB7RRnYhIxov5jnn/ybn7MRyrFZo csfzXw56+YHBX9gvVp79yULd3pENDl16vrImE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IVEX5RJRiVJvMSlOQ9Ye3n54VfafyVql70nFb+/HK98=; b=Yi+OIDUsg4a5oHFDmiuL5sY4Z94cU1VklmOkLTiYb0ZpgTAmOiMDI39Oo1pOXfMhHS gx9LMKfa0lydksYImzTGZewiK5ssLDl4Xmnf0VJTbS/eJogTQ5MWdP86c87IUygkhlcM SlKMHB+Bj332fcyI50sXUV9bqng0SGSKIJPJ55imxCfo8ipidvkamOlXgop1owxzFVOp 6mrr84vfVqjubmVD3cFQkcrrH6w/9RZlriZRg2ITFEVgH6Dz6VDze1uqxyrNbRFBxvkK qAJVwbbN4yPXQiUhdp7WQXKx/fkIUbzULswpSPw/K7bzE8I9YEqHYkAcpBhPjvTQtwWA 18Hg== X-Gm-Message-State: AODbwcAkhUPZBmwFgIGQoKBwJXj+wda32AlmVbGN5LR78/+SOWE//MVL pFRiBrfrGv8Eo3f3uW5Iu4iQMoISWBtz X-Received: by 10.99.158.17 with SMTP id s17mr5788359pgd.219.1495207767642; Fri, 19 May 2017 08:29:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.176.195 with HTTP; Fri, 19 May 2017 08:29:27 -0700 (PDT) In-Reply-To: <1888942833.154064.1494845242843.JavaMail.root@llavaneres.uoc.es> References: <1888942833.154064.1494845242843.JavaMail.root@llavaneres.uoc.es> From: Xavi Vilajosana Guillen Date: Fri, 19 May 2017 17:29:27 +0200 Message-ID: To: Lijo Thomas Cc: "Prof. Diego Dujovne" , tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="f403045e2b46db2f6d054fe22fde" Archived-At: Subject: Re: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 15:29:31 -0000 --f403045e2b46db2f6d054fe22fde Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Diego, I agree with Lijo Thomas, could you provide a very simple diagram showing how the ttl will work. What I understand is that the origin adds the TTL in the request message and the receiver sets the Timeout to this value once the request has been received. In this manner the TTL is dependent on the reception of the request. am I right? regards, Xavi 2017-05-15 12:43 GMT+02:00 Lijo Thomas : > Dear Diego, > > > > As SF0 address a scheduling scheme, it would be better if the algorithm > suggest the values. > > > > Or maybe you could detail it with an example or a flow diagram. > > > > > > *Thanks & Regards,* > > *Lijo Thomas * > > > > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Prof. > Diego Dujovne > *Sent:* 12 May 2017 20:34 > *To:* 6tisch@ietf.org > *Subject:* [6tisch] Timeout implementation on 6P/SF0 > > > > Dear all, > > During today's Webex call we discussed transaction > > timeout implementation problems. As a result, the proposed > > solution is that SF will include a TTL field with the timeout > value that the SF will wait to finish the transaction. > > This will avoid inconsistencies if the transaction > > is delayed due to retransmissions or intermediate queues. > > As a consequence, the timeout value will be > implementation-specific. > > Let me know if you agree in this item. > > Regards, > > Diego > > > > > -- > > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --f403045e2b46db2f6d054fe22fde Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Diego,

I agree with Lijo Thomas, could = you provide a very simple diagram showing how the ttl will work. What I und= erstand is that the origin adds the TTL in the request message and the rece= iver sets the Timeout to this value once the request has been received. In = this manner the TTL is dependent on the reception of the request.

am I right?

regards,
Xavi
=

2017-05-15 = 12:43 GMT+02:00 Lijo Thomas <lijo@cdac.in>:

Dear Diego,

= =C2=A0

As SF0 address a scheduling scheme, it wou= ld be better if the algorithm suggest the values.

<= p class=3D"MsoNormal">=C2=A0

Or maybe you could d= etail it with an example or a flow diagram.

=C2=A0

=

=C2=A0

Thanks & Re= gards,

Lijo Thomas <= u>

<= u>=C2=A0

=C2=A0

From: 6tisch [mai= lto:6tisch-bou= nces@ietf.org] On Behalf Of Prof. Diego Dujovne
Sent:= 12 May 2017 20:34
To: 6tisch@ietf.org
Subject: [6tisch] Timeout impl= ementation on 6P/SF0

=C2=A0

Dear all,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 During today's Webe= x call we discussed transaction

timeout implementation problems. As a result, the proposed

solution is that SF will include= a TTL field with the timeout
value that the SF will wait to finish the= transaction.

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will avoid i= nconsistencies if the transaction

is delayed due to retransmissions or intermediate queues.<= u>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, the timeout value wi= ll be
implementation-specific.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Let me know if you agree in this item.

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Diego




--

DIEGO DUJOVNE
Profesor Asociado
Escuela de = Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Univ= ersidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125


----------------------------------------------------= -----------------------------------------------------------------= ----------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destr= oy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this emai= l
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------= -----------------------------------------------------------------= -

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
=
3D"Universitat=C2=A0=C2=A0=
=C2=AD
--f403045e2b46db2f6d054fe22fde-- From nobody Fri May 19 09:18:16 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD221294EF for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 09:18:14 -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=-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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com 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 KQ9LCrS7XXQk for <6tisch@ietfa.amsl.com>; Fri, 19 May 2017 09:18:11 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8351294EC for <6tisch@ietf.org>; Fri, 19 May 2017 09:18:11 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l74so37026382ywe.2 for <6tisch@ietf.org>; Fri, 19 May 2017 09:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5KbiHRvnNfMfY+PNk+QvWwPEmUiyFs5aijMqOvs1y7c=; b=r2Ji4bZWCfZAYQkD9eYPx3/gXzFm9Ma5Y6KytbR8LDW3MHCw4DzqlwL/q5vYa3nEuw 3u620sTIAvoE2T2DQbIsBNwyZ2bLrGnLQrynnPA2bACprnqU94ltWj+fWoAxr9G/6Hxd SAniT3Vs0x7Ix/eRXnKsndLgp6G2ShFeNsoEwWSqL/2k377WjN8QNTtH3e3uMgUpioOd i9WTkjvVzQHu05s7r8F29jO5QMXQQWeh08CFg0r9rlIYCaQtfQlCX3MPgaXIC3iSPEvY qr4eC2mguCdtDTYpFTvxIhni4bKm5gghODZF4SXNtPSyyuUYjAcGfJtgT06+XKgMvg+G t2Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5KbiHRvnNfMfY+PNk+QvWwPEmUiyFs5aijMqOvs1y7c=; b=s9OvxmsP//qllYD9fq1QiqvAE94SpDw9tiJ7gHSBCnOOBNPcE0qOfpyAXPCG9rE5EN /S10D1ZJjLnKyA7RBBZrRI9R21o4UUm592PE+1Pjc1EOhD0WHm5DwsIkIOJiYhPEMZ1+ 8z6F20KEsr1ug8KvomuM4f4By9Aob3YAjyNZQf4dRluQX68fr/mlUBY7H3YlWdB0z6+X 7Ehqf6L5p65g47HBAiJzFsgqyUM6p9m8fC9Nhb/55vjnHcaQK1QPXKrY153EYhVrwMvu YqLqHDms0Iz4k0jgB8lRFl6UAqWmyVeKn51guZsD5FDqHviPBUx7ykR0Tw9lGeQhPuTF Z2Sw== X-Gm-Message-State: AODbwcDLQWGLt0e5VUFu7r7L82utD8oabkEyZoamx7JZ3cLOJEk17/GL RSfBlRa6KSPAXdWf6oTpEcm32wf+FrOsYLE= X-Received: by 10.13.216.209 with SMTP id a200mr9526194ywe.5.1495210690465; Fri, 19 May 2017 09:18:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.233.135 with HTTP; Fri, 19 May 2017 09:17:50 -0700 (PDT) In-Reply-To: References: <1888942833.154064.1494845242843.JavaMail.root@llavaneres.uoc.es> From: "Prof. Diego Dujovne" Date: Fri, 19 May 2017 12:17:50 -0400 Message-ID: To: Xavi Vilajosana Guillen Cc: Lijo Thomas , tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="001a114e4484120bda054fe2de19" Archived-At: Subject: Re: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 May 2017 16:18:14 -0000 --001a114e4484120bda054fe2de19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xavi, Lijo: The idea I have been working on is to generate a timeout value which is implementation-specific, and that will be sent by SF0 to the counterpart. There is no maximum (and the minimum must be 0). This value will be valid only for the current transaction-neighbour meaning that for different neighbours and for each of the transactions with them this value can change. The ttl value location on the packet is straightforward, as an 8-bit field on the packet after the header. SF0 on the neighbour that starts the transaction defines the timeout value which is valid until the end of the transaction. The timeout time units are also implementation-specific. Given this description, a diagram could be: Example Transaction where the timeout does not expire |TTL Value--------------------------------------------------------| |A|------First Exchange-------->|B|-----Second Exchange----->|A| Example Transaction where the timeout expires |TTL Value-------------------------------------------------| |A|------First Exchange-------->|B|-----Second Exchange----->|A| Regards, Diego 2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen : > Diego, > > I agree with Lijo Thomas, could you provide a very simple diagram showing > how the ttl will work. What I understand is that the origin adds the TTL = in > the request message and the receiver sets the Timeout to this value once > the request has been received. In this manner the TTL is dependent on the > reception of the request. > > am I right? > > regards, > Xavi > > 2017-05-15 12:43 GMT+02:00 Lijo Thomas : > >> Dear Diego, >> >> >> >> As SF0 address a scheduling scheme, it would be better if the algorithm >> suggest the values. >> >> >> >> Or maybe you could detail it with an example or a flow diagram. >> >> >> >> >> >> *Thanks & Regards,* >> >> *Lijo Thomas * >> >> >> >> >> >> *From:* 6tisch [mailto:6tisch-bounces@ietf.org] *On Behalf Of *Prof. >> Diego Dujovne >> *Sent:* 12 May 2017 20:34 >> *To:* 6tisch@ietf.org >> *Subject:* [6tisch] Timeout implementation on 6P/SF0 >> >> >> >> Dear all, >> >> During today's Webex call we discussed transaction >> >> timeout implementation problems. As a result, the proposed >> >> solution is that SF will include a TTL field with the timeout >> value that the SF will wait to finish the transaction. >> >> This will avoid inconsistencies if the transaction >> >> is delayed due to retransmissions or intermediate queues. >> >> As a consequence, the timeout value will be >> implementation-specific. >> >> Let me know if you agree in this item. >> >> Regards, >> >> Diego >> >> >> >> >> -- >> >> DIEGO DUJOVNE >> Profesor Asociado >> Escuela de Inform=C3=A1tica y Telecomunicaciones >> Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile >> www.ingenieria.udp.cl >> (56 2) 676 8125 >> >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> [ C-DAC is on Social-Media too. Kindly follow us at: >> Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ] >> >> This e-mail is for the sole use of the intended recipient(s) and may >> contain confidential and privileged information. If you are not the >> intended recipient, please contact the sender by reply e-mail and destro= y >> all copies and the original message. Any unauthorized review, use, >> disclosure, dissemination, forwarding, printing or copying of this email >> is strictly prohibited and appropriate legal action will be taken. >> ------------------------------------------------------------ >> ------------------------------------------------------------------- >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > =C2=AD > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a114e4484120bda054fe2de19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Xavi, Lijo:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 The idea I =C2=A0have been working on is to generate a timeou= t value
which is implementation-specific, and that will be sent b= y SF0 to the counterpart.
There is no maximum (and the minimum mu= st be 0).
This value will be valid only for the current transacti= on-neighbour meaning
that for different neighbours and for each o= f the transactions with them this
value can change.=C2=A0
The ttl value location on the packet is straightforward, as an 8-bit fie= ld on the
packet after the header. SF0 on the neighbour that star= ts the transaction defines
the timeout value which is valid until= the end of the transaction.=C2=A0
The timeout time units are als= o implementation-specific.
Given this description, a diagram coul= d be:

Example Transaction where the timeout does n= ot expire


|TTL Value------------------------------------------------------= --|
|A|---= ---First Exchange-------->|B|-----Second Exchange----->|A|


Example Transaction where the = timeout expires

|TTL V= alue-------------------------------------------------|
|A|------First Exchange-------= ->|B|-----Second Exchange----->|A|

<= div>Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Diego=C2=A0


2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen <x= vilajosana@uoc.edu>:
Diego,

I agree with Lijo Thomas, could you pr= ovide a very simple diagram showing how the ttl will work. What I understan= d is that the origin adds the TTL in the request message and the receiver s= ets the Timeout to this value once the request has been received. In this m= anner the TTL is dependent on the reception of the request.

<= /div>
am I right?

regards,
Xavi
=

= 2017-05-15 12:43 GMT+02:00 Lijo Thomas <lijo@cdac.in>:
=

Dear D= iego,

=C2=A0

As SF0 address a scheduling scheme, it would be better if the al= gorithm suggest the values.

= =C2=A0

Or maybe you could detail it with an examp= le or a flow diagram.

=C2=A0

=C2=A0

Thanks & Regards,

Lijo Thomas

<= p class=3D"MsoNormal">=C2=A0

=C2=A0=

Fro= m: 6tisch [mailto:6tisch-bounces@ietf.org= ] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34=
To: 6tisch@= ietf.org
Subject: [6tisch] Timeout implementation on 6P/SF0

<= p class=3D"MsoNormal">=C2=A0

Dear all,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 During today's Webex call we discussed transaction=

ti= meout implementation problems. As a result, the proposed

<= /div>

solution is that SF will include a TTL fie= ld with the timeout
value that the SF will wait to finish the transacti= on.

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will avoid inconsiste= ncies if the transaction

is delayed due to retransmissions or intermediate queues.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, the timeout value will be implementation-specific.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let me= know if you agree in this item.

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Diego<= u>


=

--

DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3= =A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad D= iego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

<= /div>

--------------------------------= -----------------------------------------------------------------= ------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destr= oy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this emai= l
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------= -----------------------------------------------------------------= -

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch



--
Dr. Xavier VilajosanaWireless Networks Lab
Internet Interdisciplinary Institute (IN3)
= Professor

(+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org=
http://wine.rdi.u= oc.edu
Parc = Mediterrani de la Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Buildin= g
08860 Castelldefels (Barcelona). Catalonia. Spain
Dr. Xavie= r Vilajosana
Wireless Networks Lab
Internet Interdisciplina= ry Institute (IN3)
Professor

(+34) 646 633 681
xvil= ajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia=C2=A0
Av C= arl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Cata= lonia. Spain
3D"Universitat=C2=A0=C2=A0
= =C2=AD



--
DIEGO DUJOVNE
Profesor Asociado
Escuela de I= nform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Unive= rsidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
--001a114e4484120bda054fe2de19-- From nobody Mon May 22 15:42:55 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635C31293EC for <6tisch@ietfa.amsl.com>; Mon, 22 May 2017 15:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.51 X-Spam-Level: *** X-Spam-Status: No, score=3.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_MUA_MOZILLA=2.309, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com 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 E8duVVl4Z_5c for <6tisch@ietfa.amsl.com>; Mon, 22 May 2017 15:42:52 -0700 (PDT) Received: from sonic311-25.consmr.mail.ne1.yahoo.com (sonic311-25.consmr.mail.ne1.yahoo.com [66.163.188.206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E491120724 for <6tisch@ietf.org>; Mon, 22 May 2017 15:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1495492971; bh=oPq2Gy8C8oJtJKFoIwRxQ7RJcpKf1tsXJX3P8sEFTZA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VannMO/CKb/3EUzx8jLthW/okmfFdPtESK2ePE32KMXo84LgvtIkJdbPJa5jVeX2KHTndslKme1JTldtZ5uS9K5v5YwJaMAf5UrxIBMparJvpmi8o4zN4Lko+MEZwAoiNt6gPwFxAla1gNAOj/RYiyVFKpiuVgs7G5Hk99ve+/WZhd4qZKDK6iZX9P+VEgh6q+BjGPLB3XNck55fJ4rZEUYlPSGXe3K4oYGEjOBbOsfjLGGMjKSxW9Pq4eks4a4pc8iF6ePp15+asYaDvacj0ogZRQbBk63NWJF7ta4DPmsP8dc1yZtPMHJa+4ES/9dFCUPfTuohXLw5MtTwAo1n9A== X-YMail-OSG: JZd3pAoVM1nGdSiqtrIloUxy05CDBSE5lh1IilR7KSkU9ddTgjgJmUFsd.YFFfO qpwtT1THSBQGSnBQBAMr37fVFoqOvhpgEIWT6lQEgDOZB.x0KUNx4coEUIC0cp5uqEeUDeM2E6.M Iy5TQGGif9jvxKjq0dHn6ybbsq2Cm8C_D3aS63IAWO8IYzd56WFsoICTcoEtGlwtQ2zxo3GN8bdM xjDvjjLp2NWv0j1v7Pbs9cS.Vum44hQwIjGTSC2_IXxvZniKwDS3pIA4d1YOsAYbNqV6JwNm09We Yg.1JdJPjufxE7Deh1A8692T_zAzOI4bd_7Ercvmu0MGdiwPHgglykUKK_TqNRGFImAMYLbRGpG7 MjvQq02qPvls.La2.2jCHlh6_pfKaMumZqjFXCtA9ob.0vFoU1QXIcsAYmMgU0YhUsw4Pg40eq8r P0QwHwyn1DtUXQ7kZsCprzEiYhxFSRe2AnAFl2h4p_fDRDeUyocgIohos3DRTLXXnLU.otdE2znt P4q3rurZ0iZKGMc1mdK08ODHIDKf4JUPR3PE- Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Mon, 22 May 2017 22:42:51 +0000 Date: Mon, 22 May 2017 22:42:29 +0000 (UTC) From: Qin Wang Reply-To: Qin Wang To: "Prof. Diego Dujovne" , Xavi Vilajosana Guillen Cc: Lijo Thomas , tisch <6tisch@ietf.org> Message-ID: <317530517.4126261.1495492949882@mail.yahoo.com> In-Reply-To: References: <1888942833.154064.1494845242843.JavaMail.root@llavaneres.uoc.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4126260_1559828216.1495492949874" X-Mailer: WebService/1.1.9679 YahooMailNeo Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Archived-At: Subject: Re: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 22:42:54 -0000 ------=_Part_4126260_1559828216.1495492949874 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Diego and all, According to my understanding, TTL is the lifetime of a Message and its fun= ction is different from Timeout. For example, when nodeA sends a ADD-Reques= t to nodeB, nodeA can set Timeout in a local Timer counting for the maximum= waiting time for Response from nodeB, and, at same time, attaches a TTL in= ADD-Request message to tell nodeB when the Request message will expire. In= this sense, the Timeout value set in nodeA should be greater than TTL valu= e, because the Timeout value should cover not only the valid lifetime value= of Request message, but also the time duration for nodeB to sent back Resp= onse message. What do you think? ThanksQin=C2=A0=20 On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne wrote: =20 Xavi, Lijo:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The ide= a I =C2=A0have been working on is to generate a timeout valuewhich is imple= mentation-specific, and that will be sent by SF0 to the counterpart.There i= s no maximum (and the minimum must be 0).This value will be valid only for = the current transaction-neighbour meaningthat for different neighbours and = for each of the transactions with them thisvalue can change.=C2=A0The ttl v= alue location on the packet is straightforward, as an 8-bit field on thepac= ket after the header. SF0 on the neighbour that starts the transaction defi= nesthe timeout value which is valid until the end of the transaction.=C2=A0= The timeout time units are also implementation-specific.Given this descript= ion, a diagram could be: Example Transaction where the timeout does not expire |TTL Value--------------------------------------------------------||A|-----= -First Exchange-------->|B|-----Second Exchange----->|A| Example Transaction where the timeout expires |TTL Value-------------------------------------------------||A|------First = Exchange-------->|B|-----Second Exchange----->|A| Regards, =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Diego=C2=A0 2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen : Diego, I agree with Lijo Thomas, could you provide a very simple diagram showing h= ow the ttl will work. What I understand is that the origin adds the TTL in = the request message and the receiver sets the Timeout to this value once th= e request has been received. In this manner the TTL is dependent on the rec= eption of the request. am I right? regards, Xavi 2017-05-15 12:43 GMT+02:00 Lijo Thomas : Dear Diego,=C2=A0As SF0 address a scheduling scheme, it would be better if = the algorithm suggest the values.=C2=A0Or maybe you could detail it with an= example or a flow diagram. =C2=A0=C2=A0Thanks & Regards,Lijo Thomas =C2=A0= =C2=A0From: 6tisch [mailto:6tisch-bounces@ietf.or g] On Behalf Of Prof. Die= go Dujovne Sent: 12 May 2017 20:34 To: 6tisch@ietf.org Subject: [6tisch] Timeout implementation on 6P/SF0=C2=A0Dear all,=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 During today's We= bex call we discussed transactiontimeout implementation problems. As a resu= lt, the proposedsolution is that SF will include a TTL field with the timeo= ut=20 value that the SF will wait to finish the transaction.=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This will avoid inconsistenci= es if the transactionis delayed due to retransmissions or intermediate queu= es.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As a = consequence, the timeout value will be=20 implementation-specific.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Let me know if you agree in this item. =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0 Diego -- DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 ------------------------------ ------------------------------ -------------= ----------------- ------------------------------ ------- [ C-DAC is on Social-Media too. Kindly follow us at:=20 Facebook: https://www.facebook.com/CDACI NDIA & Twitter: @cdacindia ] This e-mail is for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies and the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email is strictly prohibited and appropriate legal action will be taken. ------------------------------ ------------------------------ -------------= ----------------- ------------------------------ ------- ______________________________ _________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/l istinfo/6tisch --=20 | Dr. Xavier Vilajosana Wireless Networks Lab Internet Interdisciplinary Institute (IN3) Professor (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu | | Parc Mediterrani de la Tecnologia=C2=A0 Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain | =C2=A0=C2=A0 =C2=AD --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch =20 ------=_Part_4126260_1559828216.1495492949874 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Diego and all,

According to my under= standing, TTL is the lifetime of a Message and its function is different fr= om Timeout. For example, when nodeA sends a ADD-Request to nodeB, nodeA can= set Timeout in a local Timer counting for the maximum waiting time for Res= ponse from nodeB, and, at same time, attaches a TTL in ADD-Request message = to tell nodeB when the Request message will expire. In this sense, the Time= out value set in nodeA should be greater than TTL value, because the Timeou= t value should cover not only the valid lifetime value of Request message, = but also the time duration for nodeB to sent back Response message.

What do you think?=

Thanks
Qin 


On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne <diego.dujo= vne@mail.udp.cl> wrote:


Xavi, Lijo:
&= nbsp;               The idea I  hav= e been working on is to generate a timeout value
which is impleme= ntation-specific, and that will be sent by SF0 to the counterpart.
There is no maximum (and the minimum must be 0).
This value wil= l be valid only for the current transaction-neighbour meaning
tha= t for different neighbours and for each of the transactions with them this<= /div>
value can change. 
The ttl value location on the p= acket is straightforward, as an 8-bit field on the
packet after t= he header. SF0 on the neighbour that starts the transaction defines
the timeout value which is valid until the end of the transaction. =
The timeout time units are also implementation-specific.
Given this description, a diagram could be:

Example Transaction where the timeout does not expire


|TTL Value-------------------------------------------= -------------|
|A|------First Exchange-------->|B|-----Second Exchange----->|= A|


Example Transaction where the timeout expires

|TTL Value-----= --------------------------------------------|
|A|------First Exchange-------->|= B|-----Second Exchange----->|A|

Regards,

   =                     &nbs= p;           Diego 


2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen <xv= ilajosana@uoc.edu>:
Diego,

I agree with Lijo Thomas, could you provide a very simple diagram showing = how the ttl will work. What I understand is that the origin adds the TTL in= the request message and the receiver sets the Timeout to this value once t= he request has been received. In this manner the TTL is dependent on the re= ception of the request.

am I right?=

regards,
Xavi

2017-05-15 1= 2:43 GMT+02:00 Lijo Thomas <lijo@cdac.in>:
Dear Diego,
 =
As SF0 address a scheduling scheme, it would be better if = the algorithm suggest the values.
 
Or maybe you could detail it with an example or a flow diagram.=
 
 =
Thanks & Regards,
<= b>Lijo Thomas
 
 
From: 6tisch [mailto:6tisch-bounces@ietf.or g] On Behalf Of Prof. Diego DujovneSent: 12 May 2017 20:34
To:= 6tisch@ietf.org
Subject: [6tisch] Timeout implementation on 6P/SF0<= u>
 
=
Dear all,
            During= today's Webex call we discussed transaction
timeout implementation problems. As a result, the proposed
solution is = that SF will include a TTL field with the timeout
value = that the SF will wait to finish the transaction.
<= div>
     &nb= sp;      This will avoid inconsistencies if the tr= ansaction
is delayed due to retransmissions or intermediate queues.<= /div>
   &nb= sp;        As a consequence, the timeout= value will be
implementation-specific.
    = ;        Let me know if you agree in thi= s item.
       = ;     Regards,
        = ;            &n= bsp;             Die= go



-- =
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Faculta= d de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 81= 25

------------------------------ -------------------------= ----- ------------------------------ ------------------------------ -------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.facebook.com= /CDACI NDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipien= t(s) and may
contain confidential and privileged information. If you = are not the
intended recipient, please contact the sender by reply e= -mail and destroy
all copies and the original message. Any unauthorized re= view, use,
disclosure, dissemination, forwarding, printing or copyi= ng of this email
is strictly prohibited and appropriate legal action will= be taken.
------------------------------ -------------------------= ----- ------------------------------ ------------------------------ -------

______________________________ _________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/l istinfo/6tis= ch



=

--
<= div>
Dr. Xavier Vila= josana
Wireless Networks Lab
= Internet Interdisciplinary Institute (IN3)
Professor
<= br clear=3D"none">(+34) 646 63= 3 681
xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.r= di.uoc.edu
Parc Mediterrani de la Tecnolo= gia 
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Universita=  <= /span>
=C2= =AD



--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y= Telecomunicaciones
Facultad de Ingenier=C3=ADa - Univers= idad Diego Portales - Chile
www.ingenier= ia.udp.cl
(56 2) 676 8125
____________= ___________________________________
6tisch mailing list6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
<= /div>

------=_Part_4126260_1559828216.1495492949874-- From nobody Mon May 22 15:53:44 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058EC129409 for <6tisch@ietfa.amsl.com>; Mon, 22 May 2017 15:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.com 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 3VvYJ1wpFESm for <6tisch@ietfa.amsl.com>; Mon, 22 May 2017 15:53:39 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A82CF1293EC for <6tisch@ietf.org>; Mon, 22 May 2017 15:53:39 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p73so56071874ywp.0 for <6tisch@ietf.org>; Mon, 22 May 2017 15:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=knKCdmOYc2CBFjBGP0jQsXLC3JqQxx5b/S1BQWIAKSw=; b=ce6bMs07zTd1fcS3Y0j4AvGgSA26B7EBPiQO37ZKFSnJF6usugjNPeJzuVFBstnLNY OYxbiDwNAHLu7CKiEuKC50O6yTa6C0ZPZvDrWJPl/zFdWhjfweFPIuUot4DBjZKqqA4V cjNmlamGk0g1ePhaAcPKzsv5+9dA9iRdzA0RxzlBRUrAwhfvbhJWGno+lDYkj/s+WFjZ 35Fn6n76Vk12GweEWONXyYYg6BD30PqIQMOmDq18XVYyxEC+hCWNpg68QqQvKRehmmwH 3Bi5RCMd/d0KeEmZ3ftLkyhi4bn5PV6MffVvKyEcuKTV+jQmuZQfEYs6poBv/srdHMCe VcYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=knKCdmOYc2CBFjBGP0jQsXLC3JqQxx5b/S1BQWIAKSw=; b=ORtT5KWHvaeYlR9cJw/+53BU3oTIzEt0K9RwhdYr8MKYOgiYp4YOwvchcaJUHcGm5F VwdXmBoMUF9ZVbloHe2VlpV7PyX/FPLizegnwC2ruJtsj5XE9maejNh0dcgs7o0Yjevh KzbjZX93zd/l/2gq3CWakiEZrSjZf3sP+5LP7fhbjlgtA1PBGPqGnxIEUlS4b4/FMgUj 0Nv+NDoIIGAZV+FzEfyDg77zmB9nojCYU8cjCXHprvvQGN99Bxy1cajsqIVp4Ybe7Xfs aimUMCGzyxakz9MllYrpAHTjS3JQhLm/ZrNcObqAIt3c97TYwTsQSWhHGTm2S38Fq2RV aSYw== X-Gm-Message-State: AODbwcBQXiyN08cq8yvQ+t6yaqPfHxRANp4wsfF9e1ajG146Y1J+SsiM kNUZjymhUi5rGTuKp3wmuUek9rVYXps3 X-Received: by 10.129.107.138 with SMTP id g132mr20125042ywc.117.1495493618488; Mon, 22 May 2017 15:53:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.233.135 with HTTP; Mon, 22 May 2017 15:53:17 -0700 (PDT) In-Reply-To: <317530517.4126261.1495492949882@mail.yahoo.com> References: <1888942833.154064.1494845242843.JavaMail.root@llavaneres.uoc.es> <317530517.4126261.1495492949882@mail.yahoo.com> From: "Prof. Diego Dujovne" Date: Mon, 22 May 2017 18:53:17 -0400 Message-ID: To: Qin Wang Cc: Xavi Vilajosana Guillen , Lijo Thomas , tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="001a114739a4e4e82e055024bd7f" Archived-At: Subject: Re: [6tisch] Timeout implementation on 6P/SF0 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 May 2017 22:53:43 -0000 --001a114739a4e4e82e055024bd7f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Qin, I do agree, and I interpret that I have expressed that as the timeout for the full transaction. In the graph, Node B should not send any response packet after the timeout has expired. A full transaction is composed either by two messages or by three messages. From the difference you mention from ttl to timeout, just replace the ttl with timeout. I probably used them interchangeably when I should have not. Thanks for the remark, Diego 2017-05-22 18:42 GMT-04:00 Qin Wang : > Hi Diego and all, > > According to my understanding, TTL is the lifetime of a Message and its > function is different from Timeout. For example, when nodeA sends a > ADD-Request to nodeB, nodeA can set Timeout in a local Timer counting for > the maximum waiting time for Response from nodeB, and, at same time, > attaches a TTL in ADD-Request message to tell nodeB when the Request > message will expire. In this sense, the Timeout value set in nodeA should > be greater than TTL value, because the Timeout value should cover not onl= y > the valid lifetime value of Request message, but also the time duration f= or > nodeB to sent back Response message. > > What do you think? > > Thanks > Qin > > > On Friday, May 19, 2017 12:18 PM, Prof. Diego Dujovne < > diego.dujovne@mail.udp.cl> wrote: > > > Xavi, Lijo: > The idea I have been working on is to generate a timeout > value > which is implementation-specific, and that will be sent by SF0 to the > counterpart. > There is no maximum (and the minimum must be 0). > This value will be valid only for the current transaction-neighbour meani= ng > that for different neighbours and for each of the transactions with them > this > value can change. > The ttl value location on the packet is straightforward, as an 8-bit fiel= d > on the > packet after the header. SF0 on the neighbour that starts the transaction > defines > the timeout value which is valid until the end of the transaction. > The timeout time units are also implementation-specific. > Given this description, a diagram could be: > > Example Transaction where the timeout does not expire > > > |TTL Value--------------------------------------------------------| > |A|------First Exchange-------->|B|-----Second Exchange----->|A| > > > Example Transaction where the timeout expires > > |TTL Value-------------------------------------------------| > |A|------First Exchange-------->|B|-----Second Exchange----->|A| > > Regards, > > Diego > > > 2017-05-19 11:29 GMT-04:00 Xavi Vilajosana Guillen : > > Diego, > > I agree with Lijo Thomas, could you provide a very simple diagram showing > how the ttl will work. What I understand is that the origin adds the TTL = in > the request message and the receiver sets the Timeout to this value once > the request has been received. In this manner the TTL is dependent on the > reception of the request. > > am I right? > > regards, > Xavi > > 2017-05-15 12:43 GMT+02:00 Lijo Thomas : > > Dear Diego, > > As SF0 address a scheduling scheme, it would be better if the algorithm > suggest the values. > > Or maybe you could detail it with an example or a flow diagram. > > > *Thanks & Regards,* > *Lijo Thomas * > > > *From:* 6tisch [mailto:6tisch-bounces@ietf.or g <6tisch-bounces@ietf.org>= ] > *On Behalf Of *Prof. Diego Dujovne > *Sent:* 12 May 2017 20:34 > *To:* 6tisch@ietf.org > *Subject:* [6tisch] Timeout implementation on 6P/SF0 > > Dear all, > During today's Webex call we discussed transaction > timeout implementation problems. As a result, the proposed > solution is that SF will include a TTL field with the timeout > value that the SF will wait to finish the transaction. > This will avoid inconsistencies if the transaction > is delayed due to retransmissions or intermediate queues. > As a consequence, the timeout value will be > implementation-specific. > Let me know if you agree in this item. > Regards, > Diego > > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > > ------------------------------ ------------------------------ > ------------------------------ ------------------------------ ------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACI NDIA > & Twitter: @cdacindia ] > > This e-mail is for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the > intended recipient, please contact the sender by reply e-mail and destroy > all copies and the original message. Any unauthorized review, use, > disclosure, dissemination, forwarding, printing or copying of this email > is strictly prohibited and appropriate legal action will be taken. > ------------------------------ ------------------------------ > ------------------------------ ------------------------------ ------- > > ______________________________ _________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/l istinfo/6tisch > > > > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 > xvilajosana@uoc.edu > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > 08860 Castelldefels (Barcelona). Catalonia. Spain > [image: Universitat Oberta de Catalunya] > =C2=AD > > > > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Inform=C3=A1tica y Telecomunicaciones > Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a114739a4e4e82e055024bd7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Qin,
=C2=A0 =C2=A0 =C2=A0 I do agree, and I interpret = that I have expressed that as the timeout
for the full transactio= n. In the graph, Node B should not send any response
packet after= the timeout has expired. A full transaction is composed either
b= y two messages or by three messages.=C2=A0
=C2=A0 =C2=A0 =C2=A0 F= rom the difference you mention from ttl to timeout, just replace the ttl
with timeout. I probably used them interchangeably when I should ha= ve not.
=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks for the remark,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Diego

2017-05-22 18:42 GMT-04:00 Qin Wang <= qinwang6top@yaho= o.com>:
Hi Diego and all,

=
According to my understanding, TTL is the lifetime of a Messag= e and its function is different from Timeout. For example, when nodeA sends= a ADD-Request to nodeB, nodeA can set Timeout in a local Timer counting fo= r the maximum waiting time for Response from nodeB, and, at same time, atta= ches a TTL in ADD-Request message to tell nodeB when the Request message wi= ll expire. In this sense, the Timeout value set in nodeA should be greater = than TTL value, because the Timeout value should cover not only the valid l= ifetime value of Request message, but also the time duration for nodeB to s= ent back Response message.

What do you think?<= /div>

Thanks
Qin=C2=A0


=
On Friday, May 19, 2017 12:18 PM, Prof.= Diego Dujovne <diego.dujovne@mail.udp.cl> wrote:


=
Xavi, Lijo:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= The idea I =C2=A0have been working on is to generate a timeout value
=
which is implementation-specific, and that will be sent by SF0 to the = counterpart.
There is no maximum (and the minimum must be 0).
This value will be valid only for the current transaction-neighbour = meaning
that for different neighbours and for each of the transac= tions with them this
value can change.=C2=A0
The ttl va= lue location on the packet is straightforward, as an 8-bit field on the
packet after the header. SF0 on the neighbour that starts the transa= ction defines
the timeout value which is valid until the end of t= he transaction.=C2=A0
The timeout time units are also implementat= ion-specific.
Given this description, a diagram could be:

Example Transaction where the timeout does= not expire


|TTL Value----------------------= ----------------------------------|
|A|------First Exchange-------->|B|= -----Second Exchange----->|A|


= Example Transaction where t= he timeout expires

|TTL Value------------------------------------------------= -|
|A|----= --First Exchange-------->|B|-----Second Exchange----->|A|=

Regards,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 D= iego=C2=A0


2017-05-19 11:29 GM= T-04:00 Xavi Vilajosana Guillen <xvilajo= sana@uoc.edu>:
Diego,

I agree with Lijo Thomas, could you provide a very simple di= agram showing how the ttl will work. What I understand is that the origin a= dds the TTL in the request message and the receiver sets the Timeout to thi= s value once the request has been received. In this manner the TTL is depen= dent on the reception of the request.

am I right?

regards,
Xavi

2017-05-15 12:43 GMT+02:00 Lijo Thomas <lijo@cdac.in>:
=
Dear Diego,=
=C2=A0
As SF0 address a scheduling scheme, it would be better if = the algorithm suggest the values.
=C2=A0
Or maybe you could detail= it with an example or a flow diagram.
=C2=A0
=C2=A0
= Thanks & Regards,
L= ijo Thomas
=C2=A0<= u>
=C2=A0
From: 6tisch [mailto:6tisch-= bounces@ietf.or g] On Behalf Of Prof. Diego Dujovne
Sent: 12 May 2017 20:34
<= b>To: 6tisch@ietf.org
Subject: [= 6tisch] Timeout implementation on 6P/SF0
<= span class=3D"">
=C2=A0
Dear all,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 During today's Webex call we discussed transaction
timeout implementation problems. As a result, the proposed<= /div>
s= olution is that SF will include a TTL field with the timeout
value that the SF will wait to finish the transaction.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 This wil= l avoid inconsistencies if the transaction
is delayed due to r= etransmissions or intermediate queues.
=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 As a consequence, the timeout= value will be
implementation-specific.
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Let me know= if you agree in this item.
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Regards,=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 Diego<= /u>



--
DIEGO DUJOVNE
Profesor= Asociado
Escuela de Inform=C3=A1tica y Telecomunicacione= s
Facultad de Ingenier=C3=ADa - Universidad Diego Portale= s - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

------------------------------ ------------------------------ = ------------------------------ ------------------------------ -------
[ C-DAC is on Social-Media too. Kindly follow us at:=20
Facebook: https://www.faceb= ook.com/CDACI NDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipien= t(s) and may
contain confidential and privileged information. If you = are not the
intended recipient, please contact the sender by reply e= -mail and destroy
all copies and the original message. Any unauthorized re= view, use,
disclosure, dissemination, forwarding, printing or copyi= ng of this email
is strictly prohibited and appropriate legal action will= be taken.
------------------------------ -------------------------= ----- ------------------------------ ------------------------------ -------

______________________________ _________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/l istinfo/6tis= ch



--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdiscipli= nary Institute (IN3)
Professor

(+34) 646 633 681
xvil= ajosana@uoc.edu
http://xvilajosana.org
http:/= /wine.rdi.uoc.edu
Parc Mediterrani de la Tec= nologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain
3D"Univers==C2=A0=C2=A0
=C2=AD



--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Telecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(= 56 2) 676 8125
____________= ___________________________________
6tisch mailing l= ist
6tisch@ietf.org
https:/= /www.ietf.org/mailman/listinfo/6tisch

=



--
=
DIEGO DUJOVNE
Profesor Asociado
Escuela de Inform=C3=A1tica y Te= lecomunicaciones
Facultad de Ingenier=C3=ADa - Universidad Diego Portale= s - Chile
www= .ingenieria.udp.cl
(56 2) 676 8125
--001a114739a4e4e82e055024bd7f-- From nobody Wed May 24 05:21:26 2017 Return-Path: X-Original-To: 6tisch@ietf.org Delivered-To: 6tisch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3D6129AD7; Wed, 24 May 2017 05:21:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: 6tisch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149562848402.28423.2952321488847854356@ietfa.amsl.com> Date: Wed, 24 May 2017 05:21:24 -0700 Archived-At: Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-05.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:21:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : 6top Protocol (6P) Authors : Qin Wang Xavier Vilajosana Thomas Watteyne Filename : draft-ietf-6tisch-6top-protocol-05.txt Pages : 37 Date : 2017-05-24 Abstract: This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. SFs are expected to be defined in future companion specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-05 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-6top-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 24 05:24:06 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB27F12941D for <6tisch@ietfa.amsl.com>; Wed, 24 May 2017 05:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu 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 E0NipKzAnBur for <6tisch@ietfa.amsl.com>; Wed, 24 May 2017 05:24:02 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FD6127180 for <6tisch@ietf.org>; Wed, 24 May 2017 05:24:02 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id u187so65067534pgb.0 for <6tisch@ietf.org>; Wed, 24 May 2017 05:24:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=lxARo3k7g8FNLbHlOcTsh/wxtZ1Mh+CS/f95wnfZ+uw=; b=HP+Pq2hcFz2KpuGR7UkgJ12ihW34f8/bRVcsGOpsntHHkCGP3RpgUJ1RgQVAgOBopZ q6n4XFAJvex55pIJvaTaTvSkMerNadYs2Lj9IpFIxs6k7TI0ajWiHewWLcoOfk+abXtH SiPKhCpvlQS4kX+eppl7nFxkHWFAOsmxlvr5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lxARo3k7g8FNLbHlOcTsh/wxtZ1Mh+CS/f95wnfZ+uw=; b=ctqn7cKWmRUjFwlbNoEe0JkZrM9uGJ+72OrQrXI6Hay6MLJhZPxRroJGdnUgndzzE7 FDMZPRdKhRtYYkuruGCHkG1MUAfaVdVcaQYZDpQI7rBrQV/MLFQEEEl9XCaQoITGsABl 3d+u2qMgFjHAH8VTPLPH03KD0jlnzssVzxmDLXIWU1tJnDEFYcL3QzAHs52H3YbGMAd/ 42mHenGK1z+KW+Q3yyUmQddv+7NRLWHMPscBQl9nciMpC0y5PYm7ByiPqwAfuUbwT5c5 p5FG/8EQ3hCyIWlM+N17+0rirtHB8l+cHNy98Wf6mHFiyquY19Vi7W2qUFALj4Jljzfr xhbg== X-Gm-Message-State: AODbwcBXl/WdqHCWc2UY3auU9regXkPjDadI9vJ785eug+0EBUapM7G7 Tmmd4yemZAiqcLC0t/WUWWF8C+HYypJX X-Received: by 10.84.217.21 with SMTP id o21mr5178857pli.105.1495628641486; Wed, 24 May 2017 05:24:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.176.195 with HTTP; Wed, 24 May 2017 05:24:00 -0700 (PDT) In-Reply-To: <1703611204.48235.1495628552763.JavaMail.root@vilafranca.uoc.es> References: <1703611204.48235.1495628552763.JavaMail.root@vilafranca.uoc.es> From: Xavi Vilajosana Guillen Date: Wed, 24 May 2017 14:24:00 +0200 Message-ID: To: tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="f403045c6784e45cdc0550442d13" Archived-At: Subject: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-05.txt X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 12:24:05 -0000 --f403045c6784e45cdc0550442d13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, we have submitted a new version of 6P addressing the comments raised during the last meeting discussion. regards, Xavi A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF. Title : 6top Protocol (6P) Authors : Qin Wang Xavier Vilajosana Thomas Watteyne Filename : draft-ietf-6tisch-6top-protocol-05.txt Pages : 37 Date : 2017-05-24 Abstract: This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. SFs are expected to be defined in future companion specifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-05 https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-6top-protocol-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-6tisch-6top-protocol-05 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch --=20 Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajosana@uoc.edu http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya] =C2=AD --f403045c6784e45cdc0550442d13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

we have submitted a new versi= on of 6P addressing the comments raised during the last meeting discussion.=

regards,
Xavi

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e = of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 6top Protocol (6P)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Qin = Wang
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Xavier Vilajosana
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thomas Watteyne
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-6tisch-6top-protocol-05.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 37
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-05-24

Abstract:
=C2=A0 =C2=A0This document defines the 6top Protocol (6P), which enables =C2=A0 =C2=A0distributed scheduling in 6TiSCH networks.=C2=A0 6P allows nei= ghbor nodes
=C2=A0 =C2=A0to add/delete TSCH cells to one another.=C2=A0 6P is part of t= he 6TiSCH
=C2=A0 =C2=A0Operation Sublayer (6top), the next higher layer to the IEEE S= td
=C2=A0 =C2=A0802.15.4 TSCH medium access control layer.=C2=A0 The 6top Sche= duling
=C2=A0 =C2=A0Function (SF) decides when to add/delete cells, and triggers 6= P
=C2=A0 =C2=A0Transactions.=C2=A0 Several SFs can be defined, each identifie= d by a
=C2=A0 =C2=A0different 6top Scheduling Function Identifier (SFID).=C2=A0 Th= is document
=C2=A0 =C2=A0lists the requirements for an SF, but leaves the definition of= the SF
=C2=A0 =C2=A0out of scope.=C2=A0 SFs are expected to be defined in future c= ompanion
=C2=A0 =C2=A0specifications.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-6tisch-6top-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft= -ietf-6tisch-6top-protocol-05
https://datatracker.ietf.org= /doc/html/draft-ietf-6tisch-6top-protocol-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?<= wbr>url2=3Ddraft-ietf-6tisch-6top-protocol-05


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch



--
Dr. Xavier Vilajosana
Wireless Network= s Lab
Internet Interdisciplinary Institute (IN3)
Professor

= (+34) 646 633 681
xvilajosana@uoc.edu
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la= Tecnologia=C2=A0
Av Carl Friedrich Gauss 5, B3 Building
08860 Castel= ldefels (Barcelona). Catalonia. Spain
<= div dir=3D"ltr" style=3D"font-size:12.8px">
3D"Universitat=C2=A0=C2=A0
=C2=AD
=
--f403045c6784e45cdc0550442d13-- From nobody Fri May 26 22:52:35 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F46912EACE for <6tisch@ietfa.amsl.com>; Fri, 26 May 2017 22:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 GqlJw60NXxiN for <6tisch@ietfa.amsl.com>; Fri, 26 May 2017 22:52:33 -0700 (PDT) Received: from smtps.ntu.edu.tw (smtps.ntu.edu.tw [140.112.2.142]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC84126557 for <6tisch@ietf.org>; Fri, 26 May 2017 22:52:32 -0700 (PDT) Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com [209.85.213.51]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtps.ntu.edu.tw (Postfix) with ESMTP id 1E8D8106ADE for <6tisch@ietf.org>; Sat, 27 May 2017 13:52:31 +0800 (CST) Received: by mail-vk0-f51.google.com with SMTP id x71so13553167vkd.0 for <6tisch@ietf.org>; Fri, 26 May 2017 22:52:31 -0700 (PDT) X-Gm-Message-State: AODbwcDoU+o+GWoYt49h3akXpL/P7is+pzXeyDb33bjxz7tCmJOLHO3y FliQQL0pglNX8PU/05sreICBdsPHEQ== X-Received: by 10.31.242.79 with SMTP id q76mr2498189vkh.128.1495864349234; Fri, 26 May 2017 22:52:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.198.193 with HTTP; Fri, 26 May 2017 22:52:28 -0700 (PDT) From: Polly Huang Date: Sat, 27 May 2017 13:52:28 +0800 X-Gmail-Original-Message-ID: Message-ID: To: 6tisch@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [6tisch] ACM BuildSys 2017 Call for Paper X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 05:52:34 -0000 -- Our sincere apologies if you receive duplicates of the call -- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dear Colleagues, Please see below the Call for Papers for ACM BuildSys 2017. We enthusiastically look forward to your submissions on advancements in systems for any aspect of the built environment. Our sincere apologies if you receive multiple copies of this email. BuildSys has established itself as the premier conference for researchers and practitioners working to develop and optimize smart infrastructure systems that are driven by sensing, computing, and control functions. The review process is very thorough, and publications are considered to have the same value as journal publications in engineering fields. November 8-9, 2017 Delft, The Netherlands | co-located with ACM SenSys 2017 http://buildsys.acm.org/2017/ Important Dates: Abstract Registration: June 9, 2017 (11:59 PM AoE) Paper Submission Deadline: June 16, 2017 (11:59 PM AoE) Acceptance Notification: August 18, 2017 Camera-Ready Deadline: September, 2017 Conference Dates: November 8-9, 2017 ** For the abstract registration, you only need to enter the title of the paper, the list of authors and their email addresses, the PC conflicts, and a brief abstract (~150-250 words). After registering the paper's abstract, you will have an additional week to upload the PDF file of the paper (either a 10-page Full paper or a 4-page Notes paper). Advances in the effective integration of networked sensors, building controls, and physical infrastructure are transforming our society, allowing the formation of unprecedented built environments and interlocking physical, social, cyber challenges. Built environments, including buildings and critical urban infrastructure, account for over half of society=E2=80=99s energy consumption and are the mainstay of o= ur nation=E2=80=99s economy, security and health. As a result, there is a broa= d recognition that systems optimizing explicitly for the built environment are particularly important in improving our society, e.g., by increasing its sustainability and enhancing people=E2=80=99s quality-of-life. These systems represent the foundation for emerging =E2=80=9Csmart cities=E2=80=9D. The 4th ACM International Conference on Systems for Energy-Efficient Built Environments (BuildSys 2017) will be held November 8-9, 2017 at Delft, The Netherlands. We invite original contributions in the areas of intelligent systems and applications for the built environment. BuildSys particularly emphasizes approaches that improve energy efficiency, reduce costs, increase performance, and add novel functionality for improving users=E2=80=99 comfort and experience. BuildSys= =E2=80=99 scope is broad, encompassing all systems within the built environment of the urban fabric, including not only buildings but also critical infrastructure systems, such as water, power, lighting, communications, and transportation that will make up the =E2=80=9Csmart cities=E2=80=9D of the future. Submission Types: We solicit three types of original submissions: * Regular papers for oral presentation (10 pages) * Notes papers for oral presentation (4 pages) * Technical posters and demos will be solicited via a separate call (2 pa= ges) Topics: Papers are invited in all emerging aspects of information-driven systems for the built environment. Topics of interest include but are not limited to the following: =C2=B7 Applications in smart and connected communities; =C2=B7 Sensing and control for urban infrastructure systems; =C2=B7 Novel sensor methodologies, techniques, and tools; =C2=B7 Sensing and control of electrical, gas, and water loads; =C2=B7 Improved user interfaces to built infrastructure; =C2=B7 Modeling, simulation, optimization, and control of heating, cooling, lighting, ventilation, water usage and other resource flows in built environments; =C2=B7 Sensor systems and applications that enhance energy efficiency, energy reliability, durability and comfort; =C2=B7 Systems that integrate infrastructure with the smart grid to offer demand response and ancillary services; =C2=B7 Distributed generation, alternative energy, renewable sources, and energy storage in buildings; =C2=B7 Emerging standards for data collection, energy control, or interoperability of disparate devices or systems; =C2=B7 Sensing, modeling, and predicting the urban heartbeat including sounds, movements, and radio spectrum; =C2=B7 Human in the loop sensing and control for efficient usage of electricity, gas, heating, water; =C2=B7 Sensor systems for reliable occupancy counting; =C2=B7 Long-lived and energy harvesting sensor systems; =C2=B7 Scalable indoor localization and contextual computing; =C2=B7 Security, privacy, safety, and reliability in built systems; =C2=B7 Empirical studies of city-scale wireless communications. From nobody Sat May 27 01:02:11 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1AB12778D for <6tisch@ietfa.amsl.com>; Sat, 27 May 2017 01:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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] autolearn=ham autolearn_force=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 TZIdBRXDewDo for <6tisch@ietfa.amsl.com>; Sat, 27 May 2017 01:02:07 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76455120721 for <6tisch@ietf.org>; Sat, 27 May 2017 01:02:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.38,400,1491256800"; d="scan'208,217";a="225931883" Received: from mail-ua0-f180.google.com ([209.85.217.180]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 27 May 2017 10:02:03 +0200 Received: by mail-ua0-f180.google.com with SMTP id y4so16029749uay.2 for <6tisch@ietf.org>; Sat, 27 May 2017 01:02:03 -0700 (PDT) X-Gm-Message-State: AODbwcDnhcChNZfsBNeumIFKAJGOlXha7K5dXjEB92jogvToYnJkhIWy 8trbOT50NCPH7kkAu5aWV+3+HRhHtA== X-Received: by 10.159.59.132 with SMTP id r4mr2642377uah.75.1495872122414; Sat, 27 May 2017 01:02:02 -0700 (PDT) MIME-Version: 1.0 References: <20170527044147.6363DB81CFF@rfc-editor.org> In-Reply-To: <20170527044147.6363DB81CFF@rfc-editor.org> From: Thomas Watteyne Date: Sat, 27 May 2017 08:01:50 +0000 X-Gmail-Original-Message-ID: Message-ID: To: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="f403043edfc87c7e5205507cdee9" Archived-At: Subject: [6tisch] Fwd: RFC 8137 on IEEE 802.15.4 Information Element for the IETF X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 08:02:10 -0000 --f403043edfc87c7e5205507cdee9 Content-Type: text/plain; charset="UTF-8" FYI ---------- Forwarded message --------- From: Date: Sat, 27 May 2017 at 06:42 Subject: RFC 8137 on IEEE 802.15.4 Information Element for the IETF To: , Cc: , A new Request for Comments is now available in online RFC libraries. RFC 8137 Title: IEEE 802.15.4 Information Element for the IETF Author: T. Kivinen, P. Kinney Status: Standards Track Stream: IETF Date: May 2017 Mailbox: kivinen@iki.fi, pat.kinney@kinneyconsultingllc.com Pages: 7 Characters: 12946 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-kivinen-802-15-ie-06.txt URL: https://www.rfc-editor.org/info/rfc8137 DOI: 10.17487/RFC8137 IEEE Std 802.15.4 defines Information Elements (IEs) that can be used to extend 802.15.4 in an interoperable manner. The IEEE 802.15 Assigned Numbers Authority (ANA) manages the registry of the Information Elements. This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the IE is formatted to provide subtypes. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC -- _______________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com _______________________________________ --f403043edfc87c7e5205507cdee9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI

---------- Forwarded= message ---------
From: <rfc-editor@rfc-editor.org>
Date: Sat, 27 May 2017 at 06:42
= Subject: RFC 8137 on IEEE 802.15.4 Information Element for the IETF
To: = <ietf-announce@ietf.org&g= t;, <rfc-dist@rfc-editor.org= >
Cc: <drafts-u= pdate-ref@iana.org>, <rfc-editor@rfc-editor.org>


A new Request for Com= ments is now available in online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 8137

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 IEEE 802.15.4 Inform= ation Element
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for t= he IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0T. Kivinen,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 P. Ki= nney
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0May 2017
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 kivinen@iki.fi,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pat.kinn= ey@kinneyconsultingllc.com
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 12946
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-kivinen-802-15-ie-0= 6.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc8137

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 10.17487/RFC813= 7

IEEE Std 802.15.4 defines Information Elements (IEs) that can be used
to extend 802.15.4 in an interoperable manner.=C2=A0 The IEEE 802.15
Assigned Numbers Authority (ANA) manages the registry of the
Information Elements.=C2=A0 This document formulates a request for ANA to allocate a number from that registry for the IETF and describes how the
IE is formatted to provide subtypes.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/standard= s) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/retriev= e/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


--
_____________________________________= __

Thomas Watteyne, PhD
Research Scientist & Innovator= , Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead= , UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

From: Yasuyuki Tanaka Message-ID: <1ca931b4-e4f9-aa49-add3-dd601f0577e0@toshiba.co.jp> Date: Wed, 31 May 2017 21:36:43 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MAIL-FROM: X-SOURCE-IP: [172.27.153.184] X-Spam: exempt Archived-At: Subject: [6tisch] Plugtest Registration Site...? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:36:47 -0000 Hi all, Is there any web page such as a registration site which provides details on the plugtest in July...? Best, Yatch From nobody Wed May 31 07:18:08 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6013129B73 for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 07:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 waVgSMETw34j for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 07:18:03 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976CB129494 for <6tisch@ietf.org>; Wed, 31 May 2017 07:18:02 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id h4so10074266lfj.3 for <6tisch@ietf.org>; Wed, 31 May 2017 07:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ha3hEYaDv2TKUWST7pfyLFmAGsEb4qJGcV01eutTOYQ=; b=h5fjnFSiZVooWvefFuQsEZPa7I+N/Si1WHA3lS/CtMOR0e5OYKl5zSUSdDlp5c0La4 QBlvKup4EGbGiQBt9p0Wh5RcK/rHQ4b90pQfiYr1F1owyYEqncCD3GPLBA4GOtk3S4ti uYDoEcHxbuSw/XLrRkZCn2pTYQqehxJHAX/NO/ybi7nep8X98r5Zt172CQNyhbAXIhbV aHkG3SkC9t/z7CNIwhRusboG5HZIFGHoymcvQAFo7P5F7fUvjtbmOHErRRLcYvX03SMB L2aFnzTHktno39UURwjapOcEZVZDIOad4XSI2VgguTKBqMFg6kobaSVTOoZMXKw9pY0y GiGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ha3hEYaDv2TKUWST7pfyLFmAGsEb4qJGcV01eutTOYQ=; b=BKfpMRAqRNirfevZt5VJCZygSZSu1Qt4Q1X+qVUwh+WkgiYAjMrN0moOO/h9py3zDE 9v+JOZKO8sU9WuCyBIArYcNFU5z1/82BRPSGaK5iiSsQJd0c6ncY3+gxQjCwLYI8jsEr 8ZH5FQTIUeqtd7YlKU4wpjMMsgAXlA/iDPp4t2BhTeOxlJzf83zt4MHAw2jK5U89vbit ulQStducz+gOCmypjOQzqyx4Z6DGgdpoXOC75i8T1qxbKIR8nmXebn5ptG9RCERjf8hI xVhUE3VENb9skvQIYPUUA3eIRIYKQfeNf+DDQ5F3pSQeUlOVSzqDMZspkKPRrHFogJNg P9OQ== X-Gm-Message-State: AODbwcCSYhIy7FTXP1juB+0i1yYO8dNlPw8SRSMxuTEkd6Ulno7bYaEN UzH1lsReN1w8psA3Hhf5nEHRUSuUUg== X-Received: by 10.46.70.10 with SMTP id t10mr8093341lja.45.1496240280726; Wed, 31 May 2017 07:18:00 -0700 (PDT) MIME-Version: 1.0 Sender: xvilajosana@gmail.com Received: by 10.25.181.29 with HTTP; Wed, 31 May 2017 07:18:00 -0700 (PDT) In-Reply-To: <1ca931b4-e4f9-aa49-add3-dd601f0577e0@toshiba.co.jp> References: <1ca931b4-e4f9-aa49-add3-dd601f0577e0@toshiba.co.jp> From: Xavier Vilajosana Date: Wed, 31 May 2017 16:18:00 +0200 X-Google-Sender-Auth: Q6HB_5dpQ9UefnHrfwqcvwF78OA Message-ID: To: Yasuyuki Tanaka Cc: "6tisch@ietf.org" <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="f403045f78e86e74700550d296c3" Archived-At: Subject: Re: [6tisch] Plugtest Registration Site...? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:18:07 -0000 --f403045f78e86e74700550d296c3 Content-Type: text/plain; charset="UTF-8" Hi Yatch, I think this will be announced soon, maybe this Friday. regards, Xavi 2017-05-31 14:36 GMT+02:00 Yasuyuki Tanaka : > Hi all, > > Is there any web page such as a registration site which provides details > on the plugtest in July...? > > Best, > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > --f403045f78e86e74700550d296c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yatch,

I think this will be announce= d soon, maybe this Friday.

regards,
Xavi=

2017-= 05-31 14:36 GMT+02:00 Yasuyuki Tanaka <yasuyuki9.tanaka@toshi= ba.co.jp>:
Hi all,

Is there any web page such as a registration site which provides details on= the plugtest in July...?

Best,
Yatch

_______________________________________________
6tisch mailing list
6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch

--f403045f78e86e74700550d296c3-- From nobody Wed May 31 07:41:27 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FA512785F for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 3yX0-MXC_OqQ for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 07:41:24 -0700 (PDT) Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net [210.149.48.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E6712778D for <6tisch@ietf.org>; Wed, 31 May 2017 07:41:21 -0700 (PDT) Received: by mo.tsb.2iij.net (tsb-mo1501) id v4VEfJj6032081; Wed, 31 May 2017 23:41:19 +0900 Received: from unknown [172.27.153.187] (EHLO tsb-mr1501.hop.2iij.net) by mas1505.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id f06de295.0.57004.00-697.114474.mas1505.tsb.2iij.net (envelope-from ); Wed, 31 May 2017 23:41:19 +0900 (JST) X-MXL-Hash: 592ed60f26913b81-c6e692379b8d3276240669121ed463fadb3c93bf Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1501) with ESMTP id v4VEfJ7I027459 for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:19 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id v4VEfJRN013114 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:19 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v4VEfJux023629 for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:19 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 1017 for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:19 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id v4VEfJpK023624 for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:19 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id v4VEfIsp024214 for 6tisch@ietf.org; Wed, 31 May 2017 23:41:18 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id ZAA24212; Wed, 31 May 2017 23:41:18 +0900 Received: from mx11.toshiba.co.jp (mx11.toshiba.co.jp [133.199.90.141]) by ovp11.toshiba.co.jp with ESMTP id v4VEfI1D012915 for <6tisch@ietf.org>; Wed, 31 May 2017 23:41:18 +0900 (JST) Received: from spiffy20.isl.rdc.toshiba.co.jp by toshiba.co.jp id v4VEfIQX022593; Wed, 31 May 2017 23:41:18 +0900 (JST) Received: from [133.196.17.212] (nm-pptp212.isl.rdc.toshiba.co.jp [133.196.17.212]) by spiffy20.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id 6624015EAB5; Wed, 31 May 2017 23:41:18 +0900 (JST) To: Xavier Vilajosana Cc: "6tisch@ietf.org" <6tisch@ietf.org> References: <1ca931b4-e4f9-aa49-add3-dd601f0577e0@toshiba.co.jp> From: Yasuyuki Tanaka Message-ID: Date: Wed, 31 May 2017 23:41:18 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-MAIL-FROM: X-SOURCE-IP: [172.27.153.187] X-Spam: exempt Archived-At: Subject: Re: [6tisch] Plugtest Registration Site...? X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 14:41:26 -0000 Thank you, Xavi! > I think this will be announced soon, maybe this Friday. I'm looking forward to it ;-) Best, Yatch On 2017/05/31 23:18, Xavier Vilajosana wrote: > Hi Yatch, > > I think this will be announced soon, maybe this Friday. > > regards, > Xavi > > 2017-05-31 14:36 GMT+02:00 Yasuyuki Tanaka > >: > > Hi all, > > Is there any web page such as a registration site which provides > details on the plugtest in July...? > > Best, > Yatch > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > > From nobody Wed May 31 09:01:18 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D9112EAE4 for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 09:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 7ANzCS6CHK6e for <6tisch@ietfa.amsl.com>; Wed, 31 May 2017 09:01:16 -0700 (PDT) Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D31412EA74 for <6tisch@ietf.org>; Wed, 31 May 2017 09:01:16 -0700 (PDT) Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.85) for 6tisch@ietf.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1dG63d-000zUU-W2>; Wed, 31 May 2017 18:01:14 +0200 Received: from vpnweb-0272.wlan.tu-harburg.de ([134.28.177.16]) by inpost2.zedat.fu-berlin.de (Exim 4.85) for 6tisch@ietf.org with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (envelope-from ) id <1dG63d-000ELV-Ob>; Wed, 31 May 2017 18:01:13 +0200 From: Lotte Steenbrink Content-Type: multipart/alternative; boundary="Apple-Mail=_DFA2B232-84B7-49CC-BAD9-6F4CAC37DD59" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9E2FCAB0-E629-4ACF-8175-F71A8818BEC2@fu-berlin.de> Date: Wed, 31 May 2017 18:01:16 +0200 To: 6tisch@ietf.org X-Mailer: Apple Mail (2.3273) X-Originating-IP: 134.28.177.16 X-ZEDAT-Hint: A Archived-At: Subject: [6tisch] SF0 and 6top error/return code questions X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 16:01:17 -0000 --Apple-Mail=_DFA2B232-84B7-49CC-BAD9-6F4CAC37DD59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear 6TiSCH Working Group, while reading through the SF0 and 6top drafts, I've struggled with the = way some error and return codes are defined and used. Since I'm new to = 6TiSCH, I'm not quite sure if there's something that I'm missing or of = this is unintentional, and would be very grateful for any hints. My = issues are the following: draft-ietf-6tisch-6top-protocol-04 mentions a return code of ERR_VER in = section 4.4.1., but doesn't list it in the table of section 8.2.4. 6P = Return Codes (the table does, however list VERSION). Also, the table in = section 8.2.4 mentions a return code called SFID, while section 4.4.2. = says to set a return code called ERR_SFID. The same goes for other = codes, such as ERR_GEN, ERR_EOL and ERR_BUSY. Is this intentional? Additionally, draft-ietf-6tisch-6top-sf0-04 prefixes the response codes = with RC_, which (I presume) makes them easier to search and gives them = more context, but is a bit confusing when searching fro them in the 6top = draft initially. Is this intentional as well? If not, would it make = sense to rename ERR_VER and VERSION (in table 8.2.4.) in the 6top draft = to RC_ERR_VER, ERR_SFID and SFID (in table 8.2.4.) to RC_ERR_SFID etc.? With kind regards, Lotte Steenbrink= --Apple-Mail=_DFA2B232-84B7-49CC-BAD9-6F4CAC37DD59 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear 6TiSCH Working Group,

while reading through the SF0 and 6top drafts, I've struggled = with the way some error and return codes are defined and used. Since I'm = new to  6TiSCH, I'm not quite sure if there's something that I'm = missing or of this is unintentional, and would be very grateful for any = hints. My issues are the following:

draft-ietf-6tisch-6top-protocol-04 mentions a return = code of ERR_VER in section 4.4.1., but doesn't list it in the table of = section 8.2.4. 6P Return Codes (the table does, however list VERSION). = Also, the table in section 8.2.4 mentions a return code called SFID, = while section 4.4.2. says to set a return code called ERR_SFID. The same = goes for other codes, such as ERR_GEN, ERR_EOL and ERR_BUSY. Is this intentional?

Additionally, draft-ietf-6tisch-6top-sf0-04 prefixes the = response codes with RC_, which (I presume) makes them easier to search = and gives them more context, but is a bit confusing when searching fro = them in the 6top draft initially. Is this intentional as well? If not, = would it make sense to rename ERR_VER and VERSION (in table 8.2.4.) = in the 6top draft to RC_ERR_VER, ERR_SFID and SFID (in table 8.2.4.) to = RC_ERR_SFID etc.?

With kind regards,
Lotte = Steenbrink
= --Apple-Mail=_DFA2B232-84B7-49CC-BAD9-6F4CAC37DD59-- From nobody Wed May 31 15:14:58 2017 Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D0A12783A; Wed, 31 May 2017 15:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 KxZdg3Et9yJo; Wed, 31 May 2017 15:14:41 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C7112EAE4; Wed, 31 May 2017 15:14:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8A44FB80D65; Wed, 31 May 2017 15:14:09 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, 6tisch@ietf.org Message-Id: <20170531221409.8A44FB80D65@rfc-editor.org> Date: Wed, 31 May 2017 15:14:09 -0700 (PDT) Archived-At: Subject: [6tisch] BCP 210, RFC 8180 on Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.22 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: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 22:14:43 -0000 A new Request for Comments is now available in online RFC libraries. BCP 210 RFC 8180 Title: Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration Author: X. Vilajosana, Ed., K. Pister, T. Watteyne Status: Best Current Practice Stream: IETF Date: May 2017 Mailbox: xvilajosana@uoc.edu, pister@eecs.berkeley.edu, twatteyne@linear.com Pages: 28 Characters: 60068 See Also: BCP 210 I-D Tag: draft-ietf-6tisch-minimal-21.txt URL: https://www.rfc-editor.org/info/rfc8180 DOI: 10.17487/RFC8180 This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. This minimal mode of operation specifies the baseline set of protocols that need to be supported and the recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time-Slotted Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrapping and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH-compliant devices. This document is a product of the IPv6 over the TSCH mode of IEEE 802.15.4e Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC