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 5259A129435 for <6tisch@ietfa.amsl.com>; Wed, 23 Nov 2016 15:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.516 X-Spam-Level: X-Spam-Status: No, score=-3.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham 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 nQ2CWkbWZzqA for <6tisch@ietfa.amsl.com>; Wed, 23 Nov 2016 15:03:13 -0800 (PST) Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (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 11D441294E3 for <6tisch@ietf.org>; Wed, 23 Nov 2016 15:03:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1479942191; bh=HZXhzVMU7WNZXoFaCGumL/GKqfMIcloWQyCzecx0zt8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=fu2TcLKa2aSET8gec5W2dSULfgbVSdMZePXv4L14yAI1mPOrLkD5f/bNnd559Uzqoz2GbvRPFu/Y1N2vut3Mthjap0TO53F5yOhlnNUNiGHVY47o5UFe3Z8dz8f7KK42+AQJ9Dr8LYtd6E0GB4pwdOs/+fXXXQ43Og8UUspXawk61oQWIBmsBfq45NXBsBzK8to2U5R6jcg4upVAcP0ROHb8ACHKGE2Ze6PzwrfazmL0eDYYs430r8ZnWh33jnsOl3PRa2LOwT2+ADvyoF14yaIF1H+tjjd/UUAP9myoXyFbCna737PYZlK/e9Jkhw69GxEMCx47m6lV3zjFMDckHg== Received: from [98.139.215.140] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 23 Nov 2016 23:03:11 -0000 Received: from [98.139.215.254] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 23 Nov 2016 23:03:11 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 23 Nov 2016 23:03:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 25533.23177.bm@omp1067.mail.bf1.yahoo.com X-YMail-OSG: CSmRqo0VM1lq0vwnShiXKQWxKWhUKMJFS9gpXMkDhb5iirrlAbai_QNcYuCYHxn G8HcK9sW4KnG.tjE_niBg0OwDpVlsrA_zIpEJpv4rUa8egyNM6stZAe1tV.07LGT35W7.EWdzAaP l_.eV.11Om0cBgkBl74fQPrBNzNhVa.RjweR3qXwjfmgU1TGjI_fiw7HcZ3e9lissM9xoSbZzMUT AnPlGge7V81l1D0ia2y0cvyu7pMo2DLJnuCyF9uDIkpJKIZrKkEBDZIkOaW1VhthROHmESqTfl0F Vww3XwYj7n8BnSfzHzRnd1d6RSSyP6556BUs0kMYmuGeLuEWHHSDeFkZKBEa5Aw8AynmJASKEvgI NP6pS4SVJaL_VUIv1DTDTMWrSYL.M_AkzTius3Oqo4_oxtfVZHLayA9RccFTlgqR083meq1s_AwH rIOn5TWZovQ35kiH4rozlKCxnB2UOPB5Pf4WaDhG5hjbWIytlpxNBOgLU0eRHpVDNIZLNw.KqZZk- Received: from jws400131.mail.bf2.yahoo.com by sendmailws157.mail.bf1.yahoo.com; Wed, 23 Nov 2016 23:03:10 +0000; 1479942190.643 Date: Wed, 23 Nov 2016 23:02:17 +0000 (UTC) From: Qin Wang To: Yasuyuki Tanaka , Thomas Watteyne , Xavi Vilajosana Guillen Message-ID: <1833275349.763606.1479942137593@mail.yahoo.com> In-Reply-To: References: <1739694970.195512.1479755120596.JavaMail.root@vilafranca.uoc.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_763605_23011872.1479942137589" Archived-At: Cc: "6tisch@ietf.org" <6tisch@ietf.org> Subject: Re: [6tisch] Handling Inconsistent Allocation in 6P X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Qin Wang 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, 23 Nov 2016 23:03:16 -0000 ------=_Part_763605_23011872.1479942137589 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yasuyuki, Regarding to the reasons of inconsistent allocation asked in your email, I = think, roughly speaking, they are (1) failure in communication because of P= HY problems like bed channel condition, collision, and (2) failure in proce= ssing because of MAC problems such as buffer overflow.=C2=A0 The approach of 6P ACK/NACK may address reason (2), but cannot address reas= on (1), because 6P ACK/NACK may drop also. According to my understanding, t= he 2bits Generation Counter can cover the two reasons of inconsistent alloc= ation in very high probability and keep 6P simple as well. Thus, I prefer t= he 2bits Generation Counter solution also. ThanksQin =C2=A0=20 On Tuesday, November 22, 2016 11:47 AM, Yasuyuki Tanaka wrote: =20 Xavi, Thomas, thank you for the responses! I'm replying both of you in a single email to save bandwidth ;-) Sorry for making this email so long... I put a shorter response first. thomas> From an implementation point of view, cells that are in the thomas> process of being reserved (i.e. 6P add request sent but no thomas> response received yet) should be marked as "reserved" and only thomas> committed to the schedule once the 6P transaction if over. I thomas> believe this captures Nicola's idea, but turning it into a thomas> recommendation for implementers, rather than a protocol thomas> feature. This idea covers the requester side in a 2-step transaction. From the point of view of the respondent, it has no idea if its response reaches the requester in time. Therefore, there is no chance for the responder to decide whether to commit the operation or not after success in sending the response. Of course, the generation counter detects a inconsistency case where a response is out of time without Nicola's idea (the generation counter of the respondent is ahead of one of the requester). xavi> it adds complexity and more messages over the air, which are xavi> costly and can also fail (e.g external interference). What xavi> happens if we loose the 6P NACK? How the NACK sender know that xavi> the NACK has been received? Thanks, they are good questions. I guess timeout would cause an error like "unrecoverable inconsistency", then CLEAR could be sent. xavi> What causes less overhead, 2 bits per each 6P command or 1 or 2 xavi> extra packets per transaction (assuming only write/state xavi> modification transactions). For me the former is way simpler. I agree with you, Xavi. The former is less overhead. Basically, less message is better. Let me explain my little concerns on the generation management at 6P: =C2=A0 (1) it makes 6P aware of a series of transactions, at least the =C2=A0 =C2=A0 =C2=A0 result of a previous transaction, which is already tak= en care of =C2=A0 =C2=A0 =C2=A0 by a SF =C2=A0 (2) it limits options to deal with inconsistency The first item, (1), is what I felt something a bit strange with when I was writing code for the GTX/GRX stuff. Until then, I thought the role of 6P was abstracting a set of the 6top operations and getting every single transaction done well; it didn't care about past transactions (let's set aside SeqNum for now). And, in my thoughts, a SF on 6P was in charge of a whole scheduling process to each neighbor involving a series of transactions. This was a simple architectural concept for me. Now, this is not the case because of the generation counter at the 6P layer. I'm in favor of the simple concept, although there may have been no such a concept in 6top as I thought... The second one is more practical. While the draft says a post-action after detecting inconsistency is up to a SF, the SF has no choice but sending CLEAR because other command is not accepted, responded with RC_ERR_GEN, under a generation inconsistency situation. This means, one inconsistent transaction will ruin all the rest of scheduled cells which are still valid. I feel that this is rooted in the first item I mentioned; there are two entities managing consistency. By the way, I may not understand fully how an inconsistency occurs... Are there any inconsistency cases which timeout of either side cannot detect, requester side or respondent side? In other words, are there any inconsistency cases which 6P can detect but SFs cannot? Answers to this question would help me understand why the generation management at 6P is really necessary... If the generation management was not necessary, I'd propose to remove it and to add a rollback command to 6P in order to cancel the previous operation in a separate transaction, operation to cancel which is specified by SeqNum of the concerned operation in the rollback command payload. A transaction with the rollback command is supposed to be initiated when the previous transaction ends with timeout. This proposal would make no changes on the current transaction patterns. It would simplify 6P, which would not need to do for consistency management nor generation management. There could be false positives caused by inconsistency detection with timeout, but I assume they are not big deal. # In this sense, I prefer calling the value Transaction ID rather than # SeqNum. Thank you all for reading up to here... Best, Yatch On 2016/11/22 8:23, Thomas Watteyne wrote: > I'd like to keep 6P simple, and just have a mechanism to detect inconsist= encies. I believe roll-back to a previous schedule generation adds too much= complexity. From an implementation point of view, cells that are in the pr= ocess of being reserved (i.e. 6P add request sent but no response received = yet) should be marked as "reserved" and only committed to the schedule once= the 6P transaction if over. I believe this captures Nicola's idea, but tur= ning it into a recommendation for implementers, rather than a protocol feat= ure. > > On Mon, Nov 21, 2016 at 9:56 PM, Xavi Vilajosana Guillen > wrote: > >=C2=A0 =C2=A0 Hi Yatch, >=C2=A0 =C2=A0 my 2 cents inline > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 I've been thinking about how to handle inconsi= stencies. I know the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 current draft has an inconsistency detection m= echanism with generation >=C2=A0 =C2=A0 =C2=A0 =C2=A0 management; just wondering if there is another= way or a supplemental >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanism to deal with such a situation. > >=C2=A0 =C2=A0 We decided at the IETF meeting last week to reduce the numbe= r of generation counters from 2 to 1 (2bits field) as now 6P commands can a= dd different types of cells so we need to account for transactions now. I s= tate that here to outline that the proposed mechanism is very simple. At ev= ery transaction we increment a generation counter. It cannot happen that th= e two sides of the transaction have inconsistent counters. If this happens,= then the schedules are reset. I agree that this is detected after the erro= r has occurred. > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 I thought that the 2-phase commit (2PC) protoc= ol could be useful >=C2=A0 =C2=A0 =C2=A0 =C2=A0 here. Then, I found the nice idea by Nicola in= the ML archive. In >=C2=A0 =C2=A0 =C2=A0 =C2=A0 terms of the 2PC protocol, 6P ACK is Commit. 6= P NACK (mentioned in >=C2=A0 =C2=A0 =C2=A0 =C2=A0 another email by Nicola) is Abort or Rollback. >=C2=A0 =C2=A0 =C2=A0 =C2=A0 # We may need another type of message to ackno= wledge Commit or Abort. > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 An advantage of this approach is that 6P can r= esolve an inconsistency >=C2=A0 =C2=A0 =C2=A0 =C2=A0 when it occurs at the least cost, by cancellin= g the concerned >=C2=A0 =C2=A0 =C2=A0 =C2=A0 operation alone. An apparent disadvantage is a= dding further complexity >=C2=A0 =C2=A0 =C2=A0 =C2=A0 to 6P. > > >=C2=A0 =C2=A0 it adds complexity and more messages over the air, which are= costly and can also fail (e.g external interference). What happens if we l= oose the 6P NACK? How the NACK sender know that the NACK has been received? > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 What others think...? > > >=C2=A0 =C2=A0 I like to answer with another question. What causes less ove= rhead, 2 bits per each 6P command or 1 or 2 extra packets per transaction (= assuming only write/state modification transactions). For me the former is = way simpler. > >=C2=A0 =C2=A0 regards, >=C2=A0 =C2=A0 X > > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Best, >=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yatch > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________________________________________= _ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 6tisch mailing list >=C2=A0 =C2=A0 =C2=A0 =C2=A0 6tisch@ietf.org >=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/6tisch <= https://www.ietf.org/mailman/listinfo/6tisch> > > > > >=C2=A0 =C2=A0 -- >=C2=A0 =C2=A0 Dr. Xavier Vilajosana Guill=C3=A9n=C2=AD >=C2=A0 =C2=A0 Research Professor >=C2=A0 =C2=A0 Wireless Networks Research Group >=C2=A0 =C2=A0 Internet Interdisciplinary Institute (IN3) >=C2=A0 =C2=A0 Universitat Oberta de Catalunya=C2=AD > >=C2=A0 =C2=A0 +34 646 633 681 | xvilajosana@u= oc.edu =C2=AD | Skype=C2=AD: xvilajosana >=C2=A0 =C2=A0 http://xvilajosana.org >=C2=A0 =C2=A0 http://wine.rdi.uoc.edu/ > >=C2=A0 =C2=A0 Parc Mediterrani de la Tecnologia >=C2=A0 =C2=A0 Av. Carl Friedrich Gauss, 5. Edifici B3 >=C2=A0 =C2=A0 08860 Castelldefels (Barcelona) > > > >=C2=A0 =C2=A0 =C2=AD > >=C2=A0 =C2=A0 _______________________________________________ >=C2=A0 =C2=A0 6tisch mailing list >=C2=A0 =C2=A0 6tisch@ietf.org >=C2=A0 =C2=A0 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 > _______________________________________ _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch =20 ------=_Part_763605_23011872.1479942137589 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yasuyuki,
=
Regarding to the reasons of incons= istent allocation asked in your email, I think, roughly speaking, they are = (1) failure in communication because of PHY problems like bed channel condi= tion, collision, and (2) failure in processing because of MAC problems such= as buffer overflow. 

The approach= of 6P ACK/NACK may address reason (2), but cannot address reason (1), beca= use 6P ACK/NACK may drop also. According to my understanding, the 2bits Gen= eration Counter can cover the two reasons of inconsistent allocation in ver= y high probability and keep 6P simple as well. Thus, I prefer the 2bits Gen= eration Counter solution also.

Thanks
Qin



 

<= br>
On Tuesday, Nove= mber 22, 2016 11:47 AM, Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp&= gt; wrote:


Xavi, = Thomas, thank you for the responses!

I= 'm replying both of you in a single email to save bandwidth ;-)

Sorry for making this email so long... I put a sh= orter response first.

thomas> From = an implementation point of view, cells that are in the
th= omas> process of being reserved (i.e. 6P add request sent but no
thomas> response received yet) should be marked as "reserved"= and only
thomas> committed to the schedule once the 6= P transaction if over. I
thomas> believe this captures= Nicola's idea, but turning it into a
thomas> recommen= dation for implementers, rather than a protocol
thomas>= ; feature.

This idea covers the reques= ter side in a 2-step transaction. From the
point of view = of the respondent, it has no idea if its response
reaches= the requester in time. Therefore, there is no chance for the
responder to decide whether to commit the operation or not after
success in sending the response. Of course, the generation cou= nter
detects a inconsistency case where a response is out= of time without
Nicola's idea (the generation counter of= the respondent is ahead of
one of the requester).

xavi> it adds complexity and more message= s over the air, which are
xavi> costly and can also fa= il (e.g external interference). What
xavi> happens if = we loose the 6P NACK? How the NACK sender know that
xavi&= gt; the NACK has been received?

Thanks= , they are good questions. I guess timeout would cause an error
like "unrecoverable inconsistency", then CLEAR could be sent.

xavi> What causes less overhead, 2 bits p= er each 6P command or 1 or 2
xavi> extra packets per t= ransaction (assuming only write/state
xavi> modificati= on transactions). For me the former is way simpler.

I agree with you, Xavi. The former is less overhead. Basicall= y, less
message is better.

Let me explain my little concerns on the generation management at 6P= :

  (1) it makes 6P aware of a s= eries of transactions, at least the
      = result of a previous transaction, which is already taken care of
      by a SF

  (2) it limits options to deal with inconsistency

The first item, (1), is what I felt something a bit st= range with when
I was writing code for the GTX/GRX stuff.= Until then, I thought the
role of 6P was abstracting a s= et of the 6top operations and getting
every single transa= ction done well; it didn't care about past
transactions (= let's set aside SeqNum for now). And, in my thoughts, a
S= F on 6P was in charge of a whole scheduling process to each neighbor
involving a series of transactions. This was a simple architect= ural
concept for me. Now, this is not the case because of= the generation
counter at the 6P layer. I'm in favor of = the simple concept, although
there may have been no such = a concept in 6top as I thought...

The = second one is more practical. While the draft says a post-action
after detecting inconsistency is up to a SF, the SF has no choice= but
sending CLEAR because other command is not accepted,= responded with
RC_ERR_GEN, under a generation inconsiste= ncy situation. This means,
one inconsistent transaction w= ill ruin all the rest of scheduled cells
which are still = valid. I feel that this is rooted in the first item I
men= tioned; there are two entities managing consistency.

By the way, I may not understand fully how an inconsistency<= br clear=3D"none">occurs... Are there any inconsistency cases which timeout= of either
side cannot detect, requester side or responde= nt side? In other words,
are there any inconsistency case= s which 6P can detect but SFs cannot?
Answers to this que= stion would help me understand why the generation
managem= ent at 6P is really necessary...

If th= e generation management was not necessary, I'd propose to remove
it and to add a rollback command to 6P in order to cancel the pre= vious
operation in a separate transaction, operation to c= ancel which is
specified by SeqNum of the concerned opera= tion in the rollback command
payload. A transaction with = the rollback command is supposed to be
initiated when the= previous transaction ends with timeout. This
proposal wo= uld make no changes on the current transaction patterns. It
would simplify 6P, which would not need to do for consistency
management nor generation management. There could be false positi= ves
caused by inconsistency detection with timeout, but I= assume they are
not big deal.

# In this sense, I prefer calling the value Transaction ID rathe= r than
# SeqNum.

Tha= nk you all for reading up to here...

B= est,
Yatch

On 2016/1= 1/22 8:23, Thomas Watteyne wrote:
> I'd like to keep 6= P simple, and just have a mechanism to detect inconsistencies. I believe ro= ll-back to a previous schedule generation adds too much complexity. From an= implementation point of view, cells that are in the process of being reser= ved (i.e. 6P add request sent but no response received yet) should be marke= d as "reserved" and only committed to the schedule once the 6P transaction = if over. I believe this captures Nicola's idea, but turning it into a recom= mendation for implementers, rather than a protocol feature.
>
> On Mon, Nov 21, 2016 at 9:56 PM, Xavi Vilajo= sana Guillen <xvilajosana@uoc.edu <mailto:xvilajosana@uoc.edu>> wrote:
><= br clear=3D"none">>    Hi Yatch,
> =   my 2 cents inline
>
>>        I've been thinking about h= ow to handle inconsistencies. I know the
>   = ;     current draft has an inconsistency detection mechanism wit= h generation
>        management;= just wondering if there is another way or a supplemental
>        mechanism to deal with such a situation.<= br clear=3D"none">>
>    We decided at t= he IETF meeting last week to reduce the number of generation counters from = 2 to 1 (2bits field) as now 6P commands can add different types of cells so= we need to account for transactions now. I state that here to outline that= the proposed mechanism is very simple. At every transaction we increment a= generation counter. It cannot happen that the two sides of the transaction= have inconsistent counters. If this happens, then the schedules are reset.= I agree that this is detected after the error has occurred.
>
>
>      =   I thought that the 2-phase commit (2PC) protocol could be useful>        here. Then, I found the ni= ce idea by Nicola in the ML archive. In
>   =     terms of the 2PC protocol, 6P ACK is Commit. 6P NACK (menti= oned in
>        another email by= Nicola) is Abort or Rollback.
>      &= nbsp; # We may need another type of message to acknowledge Commit or Abort= .
>
>        = An advantage of this approach is that 6P can resolve an inconsistency
>        when it occurs at the least = cost, by cancelling the concerned
>     = ;   operation alone. An apparent disadvantage is adding further compl= exity
>        to 6P.
>
>
>    it = adds complexity and more messages over the air, which are costly and can al= so fail (e.g external interference). What happens if we loose the 6P NACK? = How the NACK sender know that the NACK has been received?
>
>
>      &nb= sp; What others think...?
>
>>    I like to answer with another question. = What causes less overhead, 2 bits per each 6P command or 1 or 2 extra packe= ts per transaction (assuming only write/state modification transactions). F= or me the former is way simpler.
>
&= gt;    regards,
>    X
>
>
>
>
>        Best,
>        Yatch
>
>        ___________________________= ____________________
>        6ti= sch mailing list
>        6tisch@ietf.org <mailto:6tisch@ietf.org>
>        https://www.ietf= .org/mailman/listinfo/6tisch <https://www.ietf.org/ma= ilman/listinfo/6tisch>
>
>=
>
>
> =   --
>    Dr. Xavier Vilajosana Guil= l=C3=A9n=C2=AD
>    Research Professor
>    Wireless Networks Research Group
>    Internet Interdisciplinary Institute (IN3)
>    Universitat Oberta de Catalunya=C2=AD
>
>    +34 646 633 681 &l= t;tel:%2B34%20646%20633%20681>| xvilajosana@uoc.edu <mailto:xvilajosana@uoc.edu>=C2=AD | Skype= =C2=AD: xvilajosana
>    http://xvilajosana.org <= /a><http://xvilajosana.org>
>    http://wine= .rdi.uoc.edu/
>
>   = ; Parc Mediterrani de la Tecnologia
>    A= v. Carl Friedrich Gauss, 5. Edifici B3
>    = 08860 Castelldefels (Barcelona)
>
&= gt;
>
>    =C2=AD
>
>    ___________________= ____________________________
>    6tisch ma= iling list
>    6tisch@ietf.org= <mailto:6tisch@ietf.org>
>&= nbsp;   https://www.ietf.org/mailman/listinfo/6tisch <= /a><https://www.ietf.org/mailman/listinfo/6tisch><= br clear=3D"none">>
>
>
>
> --
> _________= ______________________________
>
>= ; Thomas Watteyne, PhD
> Research Scientist & Inno= vator, Inria
> Sr Networking Design Eng, Linear Tech> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com <http://www.thomaswatteyne.com>
> ______= _________________________________

____= ___________________________________________
6tisch mailin= g list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch


------=_Part_763605_23011872.1479942137589--