Dear all,
A new version of I-D, draft-ietf-6tisch-msf-18.txt is just posted.
It mainly resolved the comments from Eric.
I believe the current version resolved the all comments posted by the reviewers.
Very much looking forward to the next step action!
Taking care!
Tengfei
Dr. Tengfei Chang
Thanks Erik for the review!
I will fix those comments and publish a new version soon.
Tengfei
Dr. Tengfei Chang
Post-doctoral Researcher
Wireless Networking for Evolving & Adaptive Applications (EVA)
National Inst. for Research in Comp. Sci. and Automation ( Inria )
(+33)1 80 49 4
Hello all,
A new version of 6TiSCH MSF draft is published. It mainly resolved the comments
from Donald (cc'ed).
Thanks again for these comments!
Erik, Let me know if there is any further action required from my side to push
it forward.
Thanks!
Regards,
Tengfei
Dr. Tengfei Chang
Post
Alright, then I will keep the version 17 unpublished, until it's needed.
Thanks a lot Pascal!
Tengfei
Stay Healthy! Stay Optimistic!
Dr. Tengfei Chang
Post-doctoral Researcher
Wireless Networking for Evolving & Adaptive Applications (EVA)
National Inst. for Research in Comp.
parent", which I changed it to the "selected routing parent".
Will correct it and publish a new version.
Thanks for the catching!
Tengfei
Stay Healthy! Stay Optimistic!
Dr. Tengfei Chang
Post-doctoral Researcher
Wireless Networking for Evolving & Adaptive Applications (EV
Optimistic!
Dr. Tengfei Chang
Post-doctoral Researcher
Wireless Networking for Evolving & Adaptive Applications (EVA)
National Inst. for Research in Comp. Sci. and Automation ( Inria )
(+33)1 80 49 41 43
tengfei.ch...@inria.fr
www.tchang.org
> From: "Pascal Thube
he radio range of the attacker" is not exactly a fixed constant ...
> attackers are not in general bound by legal limits and can increase Tx
> power subject only to their equipment and budget.
>
>MSF adapts to traffics containing packets from IP layer. It is
>possible that th
and Georgios
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Stay healthy, stay optimistic!
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inr
so inline.
>
> On Mon, Mar 30, 2020 at 01:40:24PM +0200, Tengfei Chang wrote:
> > Hi Ben,
> >
> > I replied inline:
> >
> > On Tue, Mar 24, 2020 at 8:27 PM Benjamin Kaduk wrote:
> >
> > > Hi Tengfei,
> > >
> > > Also inline.
> >
Hi Benjamin,
You may notice that the MSF revision 15 has been created.
It mainly fixed the comments your mentioned in your second response.
Thanks again for your review on MSF draft!
Tengfei
On Mon, Mar 30, 2020 at 1:40 PM Tengfei Chang
wrote:
> Hi Ben,
>
> I replied inline:
>
&
Hi Ben,
I replied inline:
On Tue, Mar 24, 2020 at 8:27 PM Benjamin Kaduk wrote:
> Hi Tengfei,
>
> Also inline.
>
> On Tue, Mar 24, 2020 at 12:22:02PM +0100, Tengfei Chang wrote:
> >Hi Benjamin,
> >I replied inline starting with '>'
> >Th
he rows of Figure 2.
>
> *RESPONSE*: it will be ordered as the time it appears in the text in
next version.
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
ne of the algorithm met the rule/One of the algorithms that meet the
> rule
>
> s/Alternative behaviors may involved/Alternative behaviors may be involved
>
> s/when alternative security/when an alternative security
>
> s/node keeps listen/node keeps listening
>
>
--
> COMMENT:
> --
>
> Please use the RFC 8174 boilerplate rather than the RFC 2119 boilerplate.
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.o
ts and can increase Tx
> power subject only to their equipment and budget.
>
> Yes, I agree. For action, I will simply remove the example.
>
>MSF adapts to traffics containing packets from IP layer. It is
>possible that the IP packet has a non-zero DSCP (Diffserv
Sorry for the previous incomplete email...
On Wed, Mar 18, 2020 at 12:29 PM Tengfei Chang
wrote:
> Hello Mirija,
>
> Thanks for the comments on the draft!
> I replied inline starting with '> '
>
> On Wed, Mar 11, 2020 at 2:19 PM Mirja Kühlewind via Datatracker <
&
" How this rate limit is set is out of scope of MSF."
> Maybe
> " How this rate limit is implemented is out of scope of MSF.
>
> 6) "Appendix A. Contributors" -> Usually Contributors is an own section
> in the
> body of the document and not part of the appendix but I'm sure the RFC
> editor
> will advise you correctly.
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Hello Roman,
Thanks for the comments on the draft!
I replied inline starting with '> '
===
Roman Danyliw has entered the following ballot position for
draft-ietf-6tisch-msf-12: Discuss
When responding, please keep the subject
e 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
> WG of the IETF.
>
> Title : 6TiSCH Minimal Scheduling Function (MSF)
> Authors : Tengfei Chang
>
ternet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title : 6TiSCH Minimal Scheduling Function (MSF)
> Authors : Tengfei Chang
>
ed, with one small change
> that will make it even better, as described next.
>
> In the last sentence of your proposed change, s/The algorithm of limiting
> the/However, any such algorithm of limiting the/
>
> Once again, thanks.
>
> - vijay
>
> On Sat, Feb 15, 2020
used to limit the traffic of broadcast
> frames? Perhaps some reference could be provided to a document that
> contains
> these rules?
>
> Nits:
>
> - S6: s/It is calculated/The timeout value is calculated/
>
> Thank you.
>
&
.
Thanks for handling this!
Regards,
Tengfei
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https
rectories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> WG of the IETF.
>
> Title : 6TiSCH Minimal Scheduling Function (MSF)
> Authors : Tengfei Chang
> Malisa Vucinic
>
pplied and doesn't break 1 byte storage of
NumTx.
Tengfei
On Fri, Dec 13, 2019 at 9:57 AM Tengfei Chang
wrote:
> Thanks Yatch! I will have those comments integrated into next version.
>
>
>
> Original message
> From: Yasuyuki Tanaka
> Date: Fri, Dec 13, 2
Thanks Yatch! I will have those comments integrated into next version. Original message From: Yasuyuki Tanaka Date: Fri, Dec 13, 2019, 12:01 AMTo: Tengfei Chang Cc: 6tisch@ietf.org, yasuyuki.tan...@inria.frSubject: Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09Hi Tengfei,Thank you
I am not aware of IPR that applies to this draft.Regards, Tengfei Original message From: Xavi Vilajosana Guillen Date: Fri, Dec 13, 2019, 7:57 AMTo: Mališa Vučinić Cc: "Pascal Thubert (pthubert)" , "Prof. Diego Dujovne" , tisch <6tisch@ietf.org>Subject: Re: [6tisch] hepherd write
welcome to review and put comments!
Regards,
Tengfei
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https
e
>
> *“before it is passed to the 6top sublayer where MSF can observe it.” Or
> something similar?*
>
>
>
> Otherwise, all good!
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* jeudi 12 décembre
very good to me. It resolves my concerns.
>>
>> Best,
>> Yatch
>>
>> On 12/12/2019 6:01 AM, Tengfei Chang wrote:
>> > Cool! Thanks for the additional info! Integrated as well!
>> >
>> > On Thu, Dec 12, 2019 at 4:55 PM Pascal Thubert (pthubert)
&g
itself. I’d
> reword to say that the distribution of traffic over multiple parents is a
> routing decision that is out of scope for MSF...
>
>
> Regards,
>
> Pascal
>
> Le 6 déc. 2019 à 12:01, Tengfei Chang a écrit :
>
>
> I will add the following text at the in
On Fri, Dec 6, 2019 at 9:31 PM Yasuyuki Tanaka
wrote:
> Hi Pascal, Tengfei,
>
> On 12/6/2019 6:48 PM, Tengfei Chang wrote:
> > Yes, MSF indeed aware of the routing information such as RPL parent, I
> > consider this is like an information stored at IPv6 layer that MSF
ement,
> they would just confuse future readers.
>
> I think, Pascal has a different opinion.
>
> Best,
> Yatch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
; still a direction so it’s doable just need to agree that the parent is
> towards the destination.
>
> All the best,
>
> Pascal
>
>
> > Best,
> > Yatch
> >
> > ___
> > 6tisch mailing list
> > 6tisch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tisch
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
OW the IP layer passes an IP packet to the lower layer (6top), and 6top
> needs to assign the packet to a bundle. Once that is done, if the bundle is
> managed by MSF, then MSF observes the transmission. Same goes for incoming
> traffic.
>
>
>
> Do you want me to provide the sent
!
Tengfei
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
hub...@cisco.com> wrote:
> Hello Tengfei
>
>
> Please see below
>
> Le 27 nov. 2019 à 21:44, Tengfei Chang a écrit :
>
>
> Thanks a lot for the reviewing, I responded inline:
>
> On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) <
> pthub...@cisco.com&
easy
> to compute the slot offset of autocells for self and parent and avoids
> those. Why not do that?
>
TC: agreed! Will apply in the next version.
>
>
>
>
>
>
> Section 16 will require more attention, either now or during secdir
> review, probably both. You should start now. Think, say, what if an
> attacker claims many cells to all its neighbors? Can it attack someone’s
> autocells to block him?
>
TC: That's a good question! It may have a chance to do so. We need discuss
internally on this section.
Thanks for belling ahead!
>
>
>
>
>
>
> Voila!
>
>
>
> Pascal as shepherd.
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
t the 6P Transaction. Issue a 6P CLEAR command to
> draft> that neighbor (this command may fail at the link layer).
> draft> Remove all cells scheduled with that neighbor from the
> draft> local schedule. Keep that node in the neighbor and routing
> draft>
uthors : Tengfei Chang
Malisa Vucinic
Xavier Vilajosana
Simon Duquennoy
Diego Dujovne
Filename: draft-ietf-6tisch-msf-08.txt
Pages : 19
Date
version is ready for WGLC.
Please let us know if any further changes are required! Thanks!
MSF authors
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tcahng.org
> >The num_transmissions for target is calculated for negotiated tx cells.
>
>
>
> I see. It make sense especially on the last sudden drop of
> target_num_transmissions in the figure.
>
> In this case, there is only one num_tx_cell. It hit 256 then drop to 128.
>
>
>
d by exactly 1, regardless of whether the cell is
used to transmit/receive a frame.
4. Why the target node was chosen to be a neighbor of Dagroot out of 36
> nodes in the network?
>
The goal of the figure is to show the behaviors of downstream traffic
adaptation.
Ping to a first
, but
> mentions signalling messages, which may confuse users.
>
> Best regards
> AB
>
> On Fri, Oct 11, 2019 at 3:41 PM Tengfei Chang
> wrote:
>
>> Hi Christian,
>>
>> Thanks for pointing this issue out!
>> The neighbor polling section is re
tract amendment, or
> an acceptance of a contract offer unless explicitly and conspicuously
> designated or stated as such.
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
——
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tcahng.org
——
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
t;- Downward traffic adaptation
>
> Were discussed and there was no objection. Do you fell ready for WGLC now?
>
>
>
> All the best
>
>
>
> Pascal
>
>
>
> *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang
> *Sent:* vendredi 4 o
concerns on the 6P Timeout are
- do you think this is an issue or not
- if yes, what's your suggestion?
Thanks!
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman
are integrated into version 06 content. You can read it to
check exactly how we did the changes.
Please let me know if you have comments on them. Thanks!
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https
from the candidate pool
directly when required.
Please let me know if you have any comments on this fix. Thanks!
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman
Hi Pascal,
The two issues mentioned in the IETF 105 meeting are
- Rules for CellList
- Downward traffic adaptation
Those two issues are resolved in new version published msf-06.
I will create threads for those issues to clear how they are resolved.
Thanks for reminder!
Tengfei
On Fri,
co
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
>
>
> --
>
> *De: *"tengfei chang"
> *À: *"6tisch" <6tisch@ietf.org>
> *Envoyé: *Lun
.
For the 1st reason, the node may try to send another 6P request later.
For the 2nd reason, the node may switch to another parent but it's layer
violated.
Any solutions for this case?
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
Hi Pascal,
Thanks for notification!
I just pushed the PDF version but don't know how to remove the previous
uploaded slides. Could you check that? Thanks!
Tengfei
On Wed, Jul 17, 2019 at 4:51 PM Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:
> Dear all:
>
>
>
> On the side, please
nefficient. If the cells are not used a lot it will take time. I disagree
> that it can be the sole procedure to avoid collisions.
>
>
>
> All the best,
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang
> *Sent:* mercredi 17 juillet 2019 06:12
> *To:* Pasc
larger value of MAX_NUMCELLS indeed
> introduces higher latency." Maybe "a larger value"?
>
TC: Thanks for pointing them out, will be fixed in the next version!
>
> Kind regards,
> Esteban
>
> On Tue, 2019-07-02 at 12:57 +0200, Tengfei Chang wrote:
> > Dear a
Hi Pascal,
For the synchronization, I agree. It should be listening for a
certain period of time and then choose which EB to use for synchronizing.
Will update in the next version.
For the rule of celllist:
- > Not the same problem. Think about this, where does the list of free
cells come
Hi Pascal,
On Mon, Jul 8, 2019 at 3:08 PM Pascal Thubert (pthubert)
wrote:
> Hello Tengfei
>
> tions address is correct. Thanks!
>
>
>
>
>
> “
>
>During this step, the pledge MAY synchronize to any EB it receives
>
>from the network it wishes to join.
>
> “
>
> In TSCH, time creates an
e RTO in RFC6298. In stead of traffic
congestion control, the Timeout here is mostly influenced by one hop link
quality.
>
>
>
>
> “
>
>
>
>| IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC |
>
>| | (MSF)
> Although managing the counters for each neighbor is conceptually
>
> simple, I admit it might be too much overhead for constrainted nodes.
>
Thanks for the comments! However, along the network time, the node won't
send upper layer packet s to non-parent neighbor.
In case of switching parent, the t
Thanks a lot Yatch for reviewing the draft. I will reply inline:
On Tue, Jul 2, 2019 at 2:58 PM Yasuyuki Tanaka
wrote:
> Thank you, Tengfei and the other authors, for the update!
>
> Here are my comments:
>
> [Major] Negotiated RX cell (Section 4.6)
>
>
version before the submission deadline.
During the time, we will evaluate the v4 MSF and would like to have your
comments as well.
Thanks in advance!
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
Hi Koojana,
It's true that MSF works with RPL closely. And it's mainly designed for
upstream traffic.
As you mentioned, MSF could be extended by having autonomous cell to any
potential neighbors that the node intend to have packet exchanged with.
The concept of parent/upstream node could be
Good catch! It's probably written because in an old version when we send
join request/response on the minimal cell. We will remove this sentence in
next version.
Thanks!
Tengfei
On Fri, May 17, 2019 at 3:53 PM Koojana Kuladinithi <
koojana.kuladini...@tuhh.de> wrote:
> Hi
>
> MSF draft in
6P ADD request is always (?) Tx=1
>
> RX=0, there is no downstream managed cells. As a result, downstream
>
> packets such as DAO-ACK have to use AutoDownCell or the minimal
>
> cell. I think we should have downstream cells, too.
>
>
>
>
>
> Best regards,
>
&g
at 4:58 PM Tengfei Chang
wrote:
> Hi Yatch,
>
> Thanks for the reviewing! I will reply your comments inline.
>
> On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka
> wrote:
>
>> Thank you, the authors!
>>
>> I confirmed most of my comments to the previous version
Hi Yatch,
Thanks for the reviewing! I will reply your comments inline.
On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka
wrote:
> Thank you, the authors!
>
> I confirmed most of my comments to the previous version have been
> addressed. It reads better :-)
>
> Here are my comments: two comments
not referenced in
> the main text.
>
> - There are a number of typos in the text, for example:
> Boradcast -> Broadcast
> maxmium -> maximum
> calcualted -> calculated
> bewteen -> between
>
> Best regards,
> Atis
>
>
>
> On Tue, Apr 9, 201
( I accidentally sending the email before finishing) the reply continues
inline...
On Wed, Apr 17, 2019 at 1:57 PM Tengfei Chang
wrote:
> Hi Fabrice,
>
> Thanks a lot for your detailed comments! I will reply them inline below.
>
> On Tue, Apr 9, 2019 at 11:39 AM Fabrice The
hen, everything is fine. The PDR will take a long
> time
> FT> to reflect the actual PDR. The cell may be RELOCATED erroneously.
> FT> (the collision may have been solved meanwhile by the conflicting link)
>
> FT> Is it something you considered?
>
> ———
> towards it prefer
MSF!
Any comments and feedback are appreciated!
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
cell.
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Thanks for the comments! Generally, all comments are taken.
I will fix them in the next version!
Tengfei
On Mon, Mar 25, 2019 at 7:59 AM Thomas Watteyne
wrote:
> Authors,
>
> Please find below my review of draft-ietf-6tisch-msf-02. It's a patch
> file to the txt version of the draft.
>
> You
to ask us questions!
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Hi Yatch,
Thanks for the following-up comments! I replied inline below.
On Thu, Mar 21, 2019 at 4:25 PM Yasuyuki Tanaka
wrote:
> Thank you, Tengfei.
>
> Additional and following-up comments:
>
>
> [Section 5.1, what to do after timeout of a 6P transaction]
>
Thanks a lot Yatch, for the comments!
I will answer your comments inline.
On Mon, Mar 18, 2019 at 3:50 PM Yasuyuki Tanaka
wrote:
> Hi,
>
> Thank you, Tengfei and the other authors, for updating the draft!
>
> I'm sharing my comments on the latest version.
>
>
Dear all,
draft-ietf-6tisch-msf-02.txt is just published.
The main changes made in this version are
- Resolve the issues in Pending Elements section.
- Using autonomous SHARED and non-SHARED cells.
- Overall revised the specification.
Additional information about how the issues in
Dear all,
We am happy to announce that OpenWSN project is going to present during the
hackathon!
We are targeting to show:
- OpenTestbed: a simple but elegant Testbed
- A 40 nodes 6TiSCH network running over OpenTestbed with OpenWSN
implementation
- An OpenBenchmark platform
when the node has a parent, DIO should be sent after
when one managed Tx cell is installed to the parent
Regards,
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman
Hi Malisa and Tero,
Thanks for answering my question! It is clear to me!
I don't fully understand. Do you mean in which case would a node send
> another Join Request, if it has already completed the join process sometime
> before and obtained the L2 encryption keys?
>
My question is exactly
- slotframe length
- number of links
- link information (slotoffset, channeloffset, type)
Is there anything else we should also add?
Tengfei
--
Chang Tengfei,
Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
-- Forwarded message --
From:
Date: Mon, Jul 2, 2018 at 6:37 PM
Subject: New Version Notification for draft-chang-6tisch-msf-02.txt
To: Malisa Vucinic , Simon Duquennoy ,
Xavier Vilajosana , Diego Dujovne <
diego.dujo...@mail.udp.cl>, Tengfei Chang
A new version of I-D,
Hi John,
Before switching parent, the node still can keep synchronized to it's old
parent through the TXRXSHARED cell. That cell is only shared between the
node and its parent.
The keepalive on TXRXSHARED cell should be able to keep the node
synchronized.
Tengfei
On Wed, Nov 15, 2017 at 12:34
Hi Esteban,
I replied inline :-)
On Mon, Nov 13, 2017 at 8:19 PM, Esteban Municio <
esteban.muni...@uantwerpen.be> wrote:
> Hi,
>
> After reading the draft I have some small comments.
>
> When requesting the first 6P ADD, the CellsOptions are TX=1,RX=1,SHARED=1
> which means that the cell is
All,
Here is the msf draft which has been submitted at here:
https://datatracker.ietf.org/doc/draft-chang-6tisch-msf/
Tengfei
On Tue, Oct 31, 2017 at 1:17 PM, Tengfei Chang <tengfei.ch...@inria.fr>
wrote:
> Diego, All,
>
> Because of my mistake, I failed to submit th
you have another link in the meantime (e.g. a
> WIP in bitbucket) ?
>
>
>
> Thanks in advance
>
>
>
> Pascal
>
>
>
> *From:* Tengfei Chang [mailto:tengfei.ch...@inria.fr]
> *Sent:* mardi 31 octobre 2017 13:17
> *To:* Prof. Diego Dujovne <diego.dujo...@mail.u
Note-Well, Blue Sheets, Scribes, Agenda Bashing [ 5min]
>>
>> * Status of the work[ 5min]
>>
>> * IETF 100 prep (chairs) [15min]
>>
>> * draft-ietf-6tisch-minimal-security (
I like the idea!
On Wed, Jul 19, 2017 at 9:03 PM, Pascal Thubert (pthubert) <
pthub...@cisco.com> wrote:
> Makes sense to me J
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavi
> Vilajosana Guillen
> *Sent:* mercredi 19 juillet 2017 19:23
> *To:* tisch <6tisch@ietf.org>
raffic (ping, EB, etc) will result is frames being exchanged between
> neighbor, which allows us to verify timing inside the timeslot, no?
>
> Probably missing something,
>
> Thomas
>
> On Fri, Jun 9, 2017 at 3:47 PM, Tengfei Chang <tengfei.ch...@inria.fr>
> wr
Remy,
The draft looks great! Thanks for updating!
I have reviewed the draft and have one comment on the test:
TD_6TiSCH_FORMAT_02
It says a ping echo request packet is used to test the timing template.
I think we shouldn't use layer 3 packets to test layer 2 behaviors.
What other layer 2
@Thomas, Thanks a lot for the meeting!
@Yatch, I like your comments. Looking forwarding to discuss on it. Here are
two more comments(tiny) from my side :
[slide-17]
ppt>*Section 4.3*: do we wait for a link-layer ACK on the Response (or
Confirmation) before committing the transaction?
ppt> à
e. To resolve
>> such a possible inconsistency, the node issues CLEAR to each of its
>> neighbors.
>>
>> Best,
>> Yatch
>>
>> On 2016/11/02 15:29, Tengfei Chang wrote:
>>
>>> All,
>>>
>>> For the decision when a node is
is added through relocation or
not. SF0 may take different decision.
What do you think?
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
is DO NOT issue a clear command to previous parent
until the nodes has reserved new cells to its new parent. This is to avoid
the swing if the reservation failed to its new parent and changed back to
previous parent.
What do you think?
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Research Engineer,
lt;(SCHEDULEDCELLS-SF0THRESH))
1. When required cells equals 0, remove all cells but keep one in schedule
2. when required cells is greater than 0, remove SCHEDULEDCELLS-
REQUIREDCELLS-(SF0THRESH+1)/2
Does this make sense?
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Resear
Hi Professor, all
Probably there is no overlap between specific error code. But some concept
of the error code is not that clear for me.
=
In section 4.3.8 about aborting a 6P Transaction:
4.3.8
; parent is currently over this threshold value.
> For instance, is an ETX of 1.5 reasonable? (PDR = 66%)
>
> Best regards,
> Fabrice
>
>
>
>
> Le 28 mai 2016 à 04:48, Tengfei Chang <tengfei.ch...@gmail.com> a écrit :
>
> Dear all,
>
> The Op
at do you think?
Tengfei
--
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
> for more. But with the token / seqnum we are open if one day we decide
>> otherwise…
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* Qin Wang [mailto:qinwang6...@yahoo.com]
>> *Sent:* mercredi 9 mar
e allowed during a 6P transaction: This
> increases
> delay, but reduces complexity.
> What do you think?
> Regards,
>
> Diego
>
>
>
>
>
> 2016-03-04 6:00 GMT-03:00 Tengfei Chang <tengfei.ch...@gmail.com>:
>
>>
;
>
>
> *From:* 6lo [mailto:6lo-boun...@ietf.org] *On Behalf Of *Tengfei Chang
> *Sent:* lundi 25 janvier 2016 12:00
> *To:* 6tisch@ietf.org; 6...@ietf.org
> *Subject:* [6lo] Compression Reference and Coalescence
>
>
>
> Dear all,
>
>
>
> I have some
1 - 100 of 112 matches
Mail list logo
