Re: [6tisch] time to close WG

[Prof. Diego Dujovne]

Pascal,
I agree for that case, you are right.
Just keep it in sleep mode until then. :D
Regards,

  Diego

Le mer. 23 mars 2022 à 13:52, Pascal Thubert (pthubert)  a écrit :

> Hello Michael
>
> We kept it open in case new work comes up. This might happen once RAW has
> progressed to the point that it requires interfaces that 6TiSCH can
> implement in the 802.15.4 TSCH case. Maybe we can observe RAW, wait and see
> ?
>
> Keep safe;
>
> Pascal
>
> > -Original Message-
> > From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Michael Richardson
> > Sent: mercredi 23 mars 2022 17:41
> > To: 6tisch@ietf.org
> > Subject: [6tisch] time to close WG
> >
> >
> > Hallway discussion was: why is 6tisch still open?
> > All the drafts are published, and I don't think we are rechartering.
> >
> > We never got ultra-constrained onboarding specificed, but EDHOC might
> pick
> > that up.
> >
> > --
> > ]   Never tell me the odds! | ipv6 mesh
> networks
> > [
> > ]   Michael Richardson, Sandelman Software Works| network
> architect
> > [
> > ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails
> > [
> >
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Finally !!

[Prof. Diego Dujovne]

Dear all,
 I can remember the first meeting in 2013, at the 6tisch BOF.
Since then, I had the chance to meet  and collaborate
with great people, which became a really interesting and fruitful learning
experience.
After 8 years, I can see the results and all the work behind in
perspective.
 I would like to thank you all for the 6tisch experience.
 What's best is that we can keep enjoying our current projects
and expect
many more in the future.
Regards from the not-so-sunny south,

   Diego

Le mar. 1 juin 2021 à 11:00, Xavi Vilajosana Guillen 
a écrit :

> That has been a fantastic journey and experience. Thanks to the chairs and
> all participants and contributors that made it possible.
>
> Warmest regards from Barcelona!
> X
>
> Missatge de Pascal Thubert (pthubert) 
> del dia dt., 1 de juny 2021 a les 16:56:
>
>> Dear all
>>
>>
>>
>> It is our greatest pleasure to announce that the following RFCs were just
>> published on the IETF data tracker:
>>
>>
>>
>>
>>
>> RFC 9030  *(was
>> draft-ietf-6tisch-architecture)*
>> *An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of
>> IEEE 802.15.4 (6TiSCH)*
>>
>> 2021-05
>> 57 pages
>>
>> New
>>
>> Informational RFC
>>
>>
>>
>> RFC 9031  *(was
>> draft-ietf-6tisch-minimal-security)*
>> *Constrained Join Protocol (CoJP) for 6TiSCH*
>>
>> 2021-05
>> 41 pages
>>
>> New
>>
>> Proposed Standard RFC
>>
>>
>>
>> RFC 9032  *(was
>> draft-ietf-6tisch-enrollment-enhanced-beacon)*
>> *Encapsulation of 6TiSCH Join and Enrollment Information Elements*
>>
>> 2021-05
>> 10 pages
>>
>> New
>>
>> Proposed Standard RFC
>>
>>
>>
>> RFC 9033  *(was
>> draft-ietf-6tisch-msf)*
>> *6TiSCH Minimal Scheduling Function (MSF)*
>>
>> 2021-05
>> 20 pages
>>
>> New
>>
>> Proposed Standard RFC
>>
>>
>>
>> This concludes the work items that this working group had on its plate.
>>
>>
>>
>> Many thanks to you all for years of hard work, in standards, open source
>> implementation, and interop testing.
>>
>>
>>
>> Keep safe!
>>
>>
>>
>> The chairs
>> ___
>> 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
> xvilajos...@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]
> ­
>
> INFORMACIÓ SOBRE PROTECCIÓ DE DADES DE LA UNIVERSITAT OBERTA DE CATALUNYA
> (UOC)
>
> Us informem que les vostres dades identificatives i les contingudes en els
> missatges electrònics i fitxers adjunts es poden incorporar a les nostres
> bases de dades amb la finalitat de gestionar les relacions i comunicacions
> vinculades a la UOC, i que es poden conservar mentre es mantingui la
> relació. Si ho voleu, podeu exercir el dret a accedir a les vostres dades,
> rectificar-les i suprimir-les i altres drets reconeguts normativament
> adreçant-vos a l'adreça de correu emissora o a fuoc...@uoc.edu.
>
> Aquest missatge i qualsevol fitxer que porti adjunt, si escau, tenen el
> caràcter de confidencials i s'adrecen únicament a la persona o entitat a
> qui s'han enviat.
>
> Així mateix, posem a la vostra disposició un delegat de protecció de dades
> que no només s'encarregarà de supervisar tots els tractaments de dades de
> la nostra entitat, sinó que us podrà atendre per a qualsevol qüestió
> relacionada amb el tractament de dades. La seva adreça de contacte és
> d...@uoc.edu.
> --
> INFORMACIÓN SOBRE PROTECCIÓN DE DATOS DE LA UNIVERSITAT OBERTA DE
> CATALUNYA (UOC)
> Os informamos de que vuestros datos identificativos y los contenidos en
> los mensajes electrónicos y ficheros adjuntos pueden incorporarse a
> nuestras bases de datos con el fin de gestionar las relaciones y
> comunicaciones vinculadas a la UOC, y de que pueden conservarse mientras se
> mantenga la relación. Si lo deseáis, podéis ejercer el derecho a acceder a
> vuestros datos, rectificarlos y suprimirlos y otros derechos reconocidos
> normativamente dirigiéndoos a la dirección de correo emisora o a
> fuoc...@uoc.edu.
> Este mensaje y cualquier fichero que lleve adjunto, si procede, tienen el
> carácter de confidenciales y se dirigen únicamente a la persona o entidad a
> quien se han enviado.
> Así mismo, ponemos a vuestra disposición a un delegado de protección de
> datos que no solo se encargará de supervisar todos los tratamientos de
> datos de nuestra entidad, sino que podrá atenderos para cualquier cuestión
> relacionada con el tratamiento de datos. Su 

Re: [6tisch] [6lo] FW: [802.15-ALL] Sad news about Dr. Robert F. Heile

[Prof. Diego Dujovne]

Really sad, I had the chance to listen to his thoughtful comments
and presentations at several of the WG meetings.
Regards,

 Diego

Le mar. 29 sept. 2020 à 04:55, Samita Chakrabarti 
a écrit :

> This is a very sad news. Bob Heile used to attend 6lo wg meetings
> regularly. It was always a pleasure talking with him.
> May his soul rest in peace.
> -Samita
>
> On Sat, Sep 26, 2020, 4:10 AM Pascal Thubert (pthubert)  40cisco@dmarc.ietf.org> wrote:
>
>> Dear all, I thought you wanted to know. Bob was the chair of IEEE 802.15
>> for a great many years.
>>
>>
>>
>> *From:* pat.kin...@kinneyconsultingllc.com <
>> pat.kin...@kinneyconsultingllc.com>
>> *Sent:* vendredi 25 septembre 2020 18:13
>> *To:* stds-802-w...@listserv.ieee.org
>> *Subject:* [802.15-ALL] Sad news about Dr. Robert F. Heile
>>
>>
>>
>> It is with my greatest regrets and deepest sorrow that I must inform you
>> of the passing of Dr Robert F Heile’s last night.  As you know Bob’s
>> condition was deteriorating rapidly.  He was at home, in no pain, and with
>> his wife, Bonnie, and two daughters, Sarah and Beth, when he peacefully
>> passed away.
>>
>>
>>
>> At this time, I have not heard of the arrangements nor services, I will
>> send out additional information as I find out.
>>
>>
>>
>> Sincerely,  Pat
>>
>> Pat Kinney
>> *Kinney Consulting LLC*
>> IEEE 802.15 WG chair, IEEE 802.15 SCm chair, IEEE 802.15.12 chair
>> ISA100 co-chair, ISA100.20 chair
>> M: +1.847.997.3775
>> O: +1.847.960.3715
>> pat.kin...@kinneyconsultingllc.com
>> --
>>
>> To unsubscribe from the STDS-802-WPAN list, click the following link:
>> https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-WPAN=1
>> ___
>> 6lo mailing list
>> 6...@ietf.org
>> https://www.ietf.org/mailman/listinfo/6lo
>>
> ___
> 6lo mailing list
> 6...@ietf.org
> https://www.ietf.org/mailman/listinfo/6lo
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Secdir last call review of draft-ietf-6tisch-enrollment-enhanced-beacon-06

[Prof. Diego Dujovne]

Yoav,
 Thank you for your feedback. I will add that line on the next
version.
Regards,

 Diego Dujovne

Le jeu. 16 janv. 2020 à 15:03, Yoav Nir via Datatracker 
a écrit :

> Reviewer: Yoav Nir
> Review result: Has Nits
>
> The draft is short and to the point and easy to understand.  The security
> considerations (and privacy considerations!) sections are well written and
> cover everything.  I'm just missing one clause.
>
> The first paragraph reads:
>All of the contents of this Information Element are sent in the
>clear.  The containing Enhanced Beacon is not encrypted.
>
> What I'm missing is "...and this is fine because the 6tisch-Join-Info
> structure
> contains no sensitive information."
>
> I'm not disputing this or asking for rigorous proof, but it you say "this
> is
> sent in the clear", you should finish with at least a statement that says
> that
> this is OK.
>
>

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-06.txt

[Prof. Diego Dujovne]

Dear all,
  A new version of the Enrollment Enhanced Beacon
draft was published on Monday Nov. 4th, including all the changes
proposed by Carles.
 Thank you.
 Regards,

   Diego Dujovne

Le lun. 4 nov. 2019 à 19:15,  a écrit :

>
> 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
> WG of the IETF.
>
> Title   : IEEE 802.15.4 Information Element encapsulation
> of 6TiSCH Join and Enrollment Information
> Authors : Diego Dujovne
>   Michael Richardson
> Filename:
> draft-ietf-6tisch-enrollment-enhanced-beacon-06.txt
> Pages   : 8
> Date: 2019-11-04
>
> Abstract:
>In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are
>limited to specific times and specific channels.  Nodes in a TSCH
>network typically frequently send Enhanced Beacon (EB) frames to
>announce the presence of the network.  This document provides a
>mechanism by which small details critical for new nodes (pledges) and
>long sleeping nodes may be carried within the Enhanced Beacon.
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-enrollment-enhanced-beacon-06
>
> https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-enrollment-enhanced-beacon-06
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-enrollment-enhanced-beacon-06
>
>
> 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/
>
> ___
> 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

Re: [6tisch] Iotdir early review of draft-ietf-6tisch-enrollment-enhanced-beacon-05

[Prof. Diego Dujovne]

Dear all,
 I would like to thank Carles for his prompt
and detailed review of the enrollment enhanced beacon
draft. We have taken care of all the comments and made
the corresponding changes.
 Version -06 was published on Monday, as you
may have noticed on the datatracker.
 Regards,

   Diego Dujovne

Le mar. 29 oct. 2019 à 00:07, Suresh Krishnan  a écrit :

> Thanks a lot Carles for your careful review and your text change
> proposals. Authors, any thoughts on these changes?
>
> Regards
> Suresh
>
> > On Oct 24, 2019, at 12:01 PM, Carles Gomez via Datatracker <
> nore...@ietf.org> wrote:
> >
> > Reviewer: Carles Gomez
> > Review result: Ready with Issues
> >
> > Thanks to the authors for writing this document.
> >
> > I did not identify technical problems. (There are comments below that do
> have a
> > technical side, but the issues might just be editorial.)
> >
> > There is a number of suggestions provided below, mostly editorial and
> about
> > presentation.
> >
> > Title
> > - "IEEE802.15.4" --> "IEEE 802.15.4"
> > - "Informational Element" --> "Information Element"
> > - "6tisch" --> "6TiSCH"
> >
> > Abstract: I'd suggest adding a comma after "In TSCH mode of IEEE STD
> 802.15.4".
> >
> > Section 1.
> > - "As further details" --> "As further detailed"
> > - Introduce the acronym "EB" the first time that "Enhanced Beacon"
> appears.
> > (Then use "EB" thereafter in the document.)
> >
> > Subsection 1.2.
> > - After "synchronization of ASN and Join Metric," perhaps you may insert
> > "carrying" and reorganize a bit the rest of the sentence. - "existance"
> -->
> > "existence" - "There are a limited number...". --> "There is a limited
> > number..." - "... by each router". Perhaps, to give more context, "by
> each
> > router in the network".
> >
> > Subsection 1.3.
> > - Title: please add ":" after "synchronization".
> > - Title: capitalize "solicitations" and "advertisements"
> > - On the first use of RS, RA, NS and NA, please use the expanded form and
> > introduce the acronym, and use the acronym thereafter. - "consuming a
> broadcast
> > aloha slot with unencrypted traffic" appears to be one of the reasons
> > mentioned, but it is a bit hidden between parenthesis. You may want to
> > reorganize the sentence to emphasize that this is actually the crucial
> point. -
> > Second bullet in the list: did you mean "RA" instead of "Router
> Soliciation" -
> > Third bullet in the list: "If it must listen for a RS as well..." Did
> you mean
> > "listen for an RA" ?
> >
> > - It might be nice to close Section 1 by adding something along the
> lines of
> > "This document defines...". However, this would not be specific to
> subsection
> > 1.3. Therefore, some reorganization of Section 1 might improve the
> document.
> >
> > Section 2.
> > - Even if there is a single figure in the whole document, it might be
> good to
> > add a figure number and a caption the format for the new IE subtype. -
> After
> > the figure, is there a particular reason why the fields of the format are
> > presented in a different order from the one in the format? - Please add
> a ":"
> > after the name of each field and its definition/description. - "this
> field
> > indicates the willingness to act as join proxy". Perhaps "the
> willingness of
> > the sender to act..."? - "Lower value indicates willing to act as a Join
> > Proxy..." Perhaps "Lower value indicates greater willingness to act
> as..." -
> > "Values range 0 (most willing)..." --> "Values range 0x00 (most
> willing)..." -
> > In the figure, one field is called "Join Proxy lower-64". In the text,
> it has a
> > different name... - "if the Proxy Address P-flag is set, then the lower
> 64-bits
> > of the Join Proxy’s Link Layer address..." Did you mean "link-local"
> instead of
> > "Link Layer? - "the layer-2 address of any IPv6 traffic to the
> originator". Did
> > you mean "the destination layer-2 address..." ? - "if the P bit is set,
> then 64
> > bits (8 bytes) of address are present." I had trouble understanding this
> > sentence. Please consider rewriting it. - "this is an variable length
> field"
> > --> "this is a variable length field".
> >
> > Section 5.
> > - "Registry IETF IE Sub-type ID." Please cite RFC 8137 here as well.
> >
>
>

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-02 - Extended (fwd) Ines Robles: [Roll] WG adoption call for draft-richardson-6tisch-roll-enrollment-priority-

[Prof. Diego Dujovne]

+1 too.
Regards,

Diego

Le mar. 27 août 2019 à 14:12, Pascal Thubert (pthubert) 
a écrit :

> +1
>
>
> Regards,
>
> Pascal
>
> > Le 27 août 2019 à 20:09, Michael Richardson  a écrit :
> >
> >
> > This document is part of the enhanced beacon process.
> > Comments appreciated to *ADOPT*.
> >
> > 
> > ___
> > 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
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] starting WGLC for draft-ietf-6tisch-enrollment-enhanced-beacon-02

[Prof. Diego Dujovne]

I am unaware of any IPR related to this draft.

El lun., 19 de agosto de 2019 11:59, Michael Richardson 
escribió:

> Pascal Thubert (pthubert)  wrote:
> > Authors: please confirm whether any and all appropriate IPR
> > disclosures required for full conformance with the provisions of BCP
> 78
> > and BCP 79 have already been filed. If not, explain why. You may for
> > instance answer with "I'm not aware of any IPR that applies to this
> > draft" or indicate a link to an IETF disclosure.  Others: If you are
> > aware of IPR that encumbers this draft, please reply to this mail
> with
> > relevant information.
>
> I am unaware of any IPR.
>
>
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] SeqNum definition in RFC8480 (6P)

[Prof. Diego Dujovne]

Yacht,
  Let me chime in a little bit. Responses below.
Regards,

 Diego


El mié., 24 de abr. de 2019 06:24, Yasuyuki Tanaka 
escribió:

> Hi Xavi,
>
> > What is the issue you see with this?
>
> At least, there is an inconsistency in RFC8480. Here is another example:
>
> https://tools.ietf.org/html/rfc8480#section-3.2.2
>
> rfc8480>   6P Request, 6P Response, and 6P Confirmation messages for a
> given
> rfc8480>   transaction MUST share the same Version, SFID, and SeqNum
> values.
>
> Such an inconsistency could bring confusion and/or an interoperability
> issue.
>
> According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a
> special
> meaning which is "I've lost all the states completely (due to
> power-cycle)",
> although this is another case we will receive such a response as shown in
> Figure 32... Honestly, I'm not sure how valuable it is to know the peer has
> performed power-cycle, by the way.
>

As far as I can remember, it is important to know that the peer has
forgotten all the states and has lost his schedule, so all the allocated
cells with that neighbour are currently not valid anymore and should be
wiped from the local schedule.


> So, if setting 0 to SeqNum of a response is a right thing, I would add some
> text to the SeqNum definition in Section 3.2.2, to tell there is an
> exception.
>
> 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

Re: [6tisch] review of draft-ietf-6tisch-enrollment-enhanced-beacon

[Prof. Diego Dujovne]

Pascal, Michael:
 Thanks for the comments. Answers below.
Regards,

   Diego

Le lun. 25 mars 2019 à 05:47, Michael Richardson  a
écrit :

>
> Thank you for this review!
>
> Pascal Thubert (pthubert)  wrote:
> > Page2 Introduction: there?s an EDNOTE: field. It could be useful but
> > not necessary to make the proposed addition. Is the author willing
> to?
> > Or should a coauthor help?
>
> } EDNOTE: Explain why broadcasts are rare, and why we need them. What the
> } Enhanced Beacon is, and what Information Elements are, and how the IETF
> has a
> } subtype for that area.  Explain what kind of things could be placed in
> } Information Elements, how big they could be, and how they could be
> } compressed.
>
> If the WG feels that this section needs to be filled in then I will work
> with
> Diego to fill it in.Clearly less text is easier to review, but I think
> that non-6tisch reviewers will need some understanding of why we do what
> might be considered layer violations to pack all this L3 and routing
> information into a L2 object.
>
> I would prefer to write text like:
>"[XYZ] explains how the availability of the broadcast is limited.
>[ABC] details how the Enhanced Beacon is already used to do
> schedule synchronization"
>
> - One good reference for the low availability of broadcast nodes is Malisa
Vucinic et al. paper
"Broadcasting strategies in 6TiSCH networks" which mentions:
"State‐of‐the‐art approaches(2–4) address the problem by assigning
additional bandwidth; this comes with extra maintenance and energy cost.5
Using the Trickle timer6 to schedule EBs is not feasible in 6TiSCH as new
motes have no means of soliciting its reset without being synchronized with
the network."
- I think the details on the Enhanced beacon can be obtained both from
RFC8180
and from the IEEE802.15.4 standard.

Comments welcome.


> I would dearly like help from the WG on this text. Now that the
> architecture
> is more stable, perhaps they are just normative architecture document
> references?
>
>
> > Suggestion to also refer to https://tools.ietf.org/html/
> > draft-ietf-6tisch-architecture for terminology
>
> Done.
>
> > ?
>
> >At layer 3, [RFC2461] defines a mechanism by
>
> > ?
>
> > Please use RFC 4861
>
> done.
>
>
>
> > Section 1.3
> > There?s a XXX leftover. What is the intention?
>
> No idea, removed.
>
>
> >proxy priority the proxy prority value contains a number from 0 to
> >   0x7f.  Lower numbers are considered to be a higher
> preference.  A
> >   priority of 0x7f indicates that the announcer should never be
> >   considered as a viable enrollment proxy.  Lower value indicates
> >   willing to act as a Join Proxy as described in
> >   [I-D.ietf-6tisch-minimal-security].  Only unenrolled pledges
> look
> >   at this value.
>
>
> > ?
>
> > Maybe indicate first that the field indicates the willingness to act
> as
> > join proxy? Also, a typo (prority).
>
> Fixed.
>
> > P and R bits definition; though it is quite obvious, the description
> > does not say that ?R? is the RA bit and that ?P? is the Proxy Address
> > bit. Maybe use the term flag, like in? the ?P? flag?.
>
> Okay.
>
> >join-proxy lower-64 if the P bit is set, then 64 bits (8 bytes) of
> >   address are present.  The Link Layer address of the Join Proxy
> is
> >   fe80 (as for any Link Layer address), and the bits given in
> this
> >   field.
>
> > ?
>
> > I think you mean Link-Local not link layer? What about:
>
> Thank you, good catch.
>
>
> >join-proxy Interface ID if the P bit is set, then 64 bits (8
> bytes)
> > of
> >address are present. This field provides the suffix of the
> > Link_Local
> >address of the Join Proxy. The associated prefix is well-known as
> >fe80::/64.
> > ?
>
>
> >In a 6tisch network, where RPL is u
>
> > ?
> > Missing reference to RFC 6550
>
> added.
>
>
> > ?
> > 2.1.  Protocol Example
> >Here will be three examples of processing.
> > ?
> > Do you intend to fill that section?
>
> At this point, I have no example packets, so I will remove that section.
> I have posted -02 with these changes.
> What lacks now is only a decision on how much text to put in the intro to
> explain broadcasts.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] I-D Action: draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt

[Prof. Diego Dujovne]

Michael,
 I agree on putting the rank to the maximum value
to code that the network is not interested in accepting more members,
thus, keeping their internal data private.
Regards,

 Diego

Le dim. 23 sept. 2018 à 17:38, Michael Richardson  a
écrit :

>
> Georgios Z. Papadopoulos  wrote:
> > Many thanks for this work.  Going through the draft, I have a
> > comment/question :
>
> > Considering that “The containing Enhanced Beacon is not encrypted.”
> > (Section 3), is it necessary to include “rank priority” at L2 and,
> > thus, revealing this information?
>
> I consider it a concern as well.
>
> When returning from a deep sleep,  where there may be multiple
> LLNs on different PANIDs (and in 6tisch, with different schedules, even
> using
> different sets of channels),  there is a desire to know which network will
> "closer".
>
> I think that we need to understand the tradeoffs, so let's discuss
> (also in the ROLL WG!).  Perhaps a compromise is that the rank priority can
> be forced to maximum value on networks that want to keep the information
> private.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Fwd: Protocol Action: '6TiSCH Operation Sublayer Protocol (6P)' to Proposed Standard (draft-ietf-6tisch-6top-protocol-12.txt)

[Prof. Diego Dujovne]

Congratulations!

El vie., 17 de ago. de 2018 11:03, Pascal Thubert (pthubert)  escribió:

> Congratulations to the authors for the hard and excellent work on this
> draft!
>
> Pascal
>
> Début du message transféré :
>
> *Expéditeur:* The IESG 
> *Date:* 16 août 2018 à 15:37:58 UTC+2
> *Destinataire:* IETF-Announce 
> *Cc:* The IESG , , Pascal Thubert <
> pthub...@cisco.com>, <6tisch-cha...@ietf.org>, <
> draft-ietf-6tisch-6top-proto...@ietf.org>, <6tisch@ietf.org>, <
> sur...@kaloom.com>, 
> *Objet:* *Protocol Action: '6TiSCH Operation Sublayer Protocol (6P)' to
> Proposed Standard (draft-ietf-6tisch-6top-protocol-12.txt)*
>
> The IESG has approved the following document:
> - '6TiSCH Operation Sublayer Protocol (6P)'
>  (draft-ietf-6tisch-6top-protocol-12.txt) as Proposed Standard
>
> This document is the product of the IPv6 over the TSCH mode of IEEE
> 802.15.4e
> Working Group.
>
> The IESG contact persons are Suresh Krishnan and Terry Manderson.
>
> A URL of this Internet Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>
>
>
>
>
> Technical Summary
>
>   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 6P layer is formed by
>   the 6top Protocol defined in this document and 6top Scheduling
>   Function(s).  A 6top Scheduling Function (SF) decides when to add/
>   delete cells, and triggers 6P Transactions.  This document lists the
>   requirements for an SF, but leaves the definition of SFs out of
>   scope.
>
> Working Group Summary
>
>
> This document was not controversial. The design was complex due to the
> need to save exchanges and yet provide transactional outcomes.
> The next generation of the work may be done at IEEE, e.g. within IEEE Std..
> 802.12
>
> Document Quality
>
> This specification was implemented in openWSN and contiki.
> It was interop tested at the 6TiSCH F-interop in Prague:
> http://www.etsi.org/news-events/events/1197-6tisch-interop-prague-2017
> Return from experimentation is implemented in the draft
>
> Personnel
>
> Pascal Thubert is the Document Shepherd. Suresh Krishnan is the
> Responsible Area Director.
>
> ___
> 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

Re: [6tisch] draft-ietf-6tisch-6top-sfx-01 comments

[Prof. Diego Dujovne]

Lotte,
  Thank you for your comments. They are very helpful
to improve and to complete the draft before WGLC.
Do you have some preliminary results on the implementation
(or an open source implementation) to contribute to the WG?
Thank you.
Regards,

  Diego Dujovne

2018-03-07 13:48 GMT-03:00 Lotte Steenbrink :

> Dear members of the 6TiSCH working group,
>
> as with my draft-ietf-6tisch-6top-protocol-09 comments
> ,
> during the past weeks, I've attempted to implement SFX as part of my
> master's thesis. During this process, I've come across some parts of the
> Draft that seemed incomplete to me or where I was unsure if I interpreted
> them correctly. Even though the draft cut-off date for IETF101 has passed,
> I thought it might be helpful to share what the parts in question were
> before SFX goes into Working Group Last Call.
> Again, I'm grateful for any feedback and any statement of mine suggesting
> a change comes with an implicit "I'd be happy to write/suggest text for
> that".
>
> *Allocation Policy Instructions*
> *---*
> Is there a reason the Allocation policy Instructions on Page 5/6 don't
> specify exact values? E.g. I would interpret
> "If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more cells"
> to mean "If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete
> SCHEDULEDCELLS-REQUIREDCELLS cells"
> and "If SCHEDULEDCELLS SCHEDULEDCELLS is this correct?
>
> *NumCells and cellList size*
> *--*
> As far as I understand it, 6P allows the originator of an ADD or RELOCATE
> request to offer more possible cells in the celList/candidateCellList than
> actually needed (as specified by numCells). As far as I can see, SFX does
> not appear to take advantage of this feature– is this deliberate or will
> this be added in the future?
>
> *Whitelisting Policies*
> *--*
> I'm assuming that once a node sends an ADD request, it removes all
> timeOffsets proposed in the cellList from the Whitelist. When it receives a
> SUCCESS response, it then re-adds the timeOffsets of cells that weren't
> picked by the neighbor. The same applies to error responses (all suggested
> timeOffets are re-added). The same goes for DELETE and RELOCATE requests
> (but the other way round).
> Is this correct? If so, I'd propose to explicitly state this in sections
> 14 and 5.3. (or another section dedicated to sending request messages)
>
> Additionally, I'm assuming the randomly picked channelOffset should be !=
> 0. Would it make sense to mention this explicitly or is it too obvious?
>
> (Similar questions probably apply to the blacklist case, but I haven't
> implemented that one.)
>
> *Deletion policy*
> *-*
> Section 6. only describes how to select cells for an ADD request, but not
> for a DELETE or RELOCATE request.
> Are cells for a DELETE request to be selected randomly from the cells
> scheduled between Node A and B?
> Are cells for the candidateCellist of a RELOCATE request to be selected
> randomly from unused whitelisted cells, similar to the approach for ADD
> requests described in Section 6?
>
> *(Interpretation of the) Timeout value*
> *---*
> Section 7. 6P Timeout Value says "There is no measurement unit associated
> to the timeout value.". However, the 6P draft also doesn't define a
> measurement unit. How do I know if my neighbour interprets the timeout I'm
> sending them as an offset or absolute time, milliseconds, seconds, incoming
> 6P transactions or what-have-you? Is there a recommended measurement unit
> for the timeout value?
> Additionally, if 6P mandates that all SFs MUST specify a value for the 6P
> timeout, why is it up to the SF to put the timeout variable somewhere in
> their metadata field (as opposed to having a dedicated timeout octet in the
> 6P messages). I'm assuming this is to allow SFs to store timeouts in as
> many octets (or less) as they like, but imho it creates an odd dependency
> between 6P and the SF. I realize that 6P can't exist autonomously without a
> SF anyway, but in this case it mandates a value that doesn't exist in its
> own "default" messages. Personally, I'd assume there to be an 8-bit timeout
> field to the header of 6P REQUEST messages, which can then be extended in
> the metadata field, should a specific SF need more space than that.
>
> Additionally, the 6P draft says that a Scheduling Function specification "MUST
> specify a value for the 6P Timeout, or a rule/equation to calculate it.".
> Personally, I don't feel that the current content of section 8 fulfills
> this requirement, and I don't feel equipped (yet) to pick a suitable
> timeout value on my own. 

[6tisch] Submission of new version of SFX

[Prof. Diego Dujovne]

Dear all,
 I forward the submission confirmation for the -01
version of the SFX Scheduling function draft.
 Thank you.
 Regards,

  Diego Dujovne


A new version of I-D, draft-ietf-6tisch-6top-sfx-01.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:   draft-ietf-6tisch-6top-sfx
Revision:   01
Title:  6TiSCH Experimental Scheduling Function (SFX)
Document date:  2018-03-05
Group:  6tisch
Pages:  12
URL:https://www.ietf.org/internet-drafts/draft-ietf-6tisch-6top-
sfx-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sfx/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-6top-sfx-01
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
6top-sfx-01
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-
sfx-01

Abstract:
   This document defines a Scheduling Function called "Experimental
   Scheduling Function" (SFX).  SFX dynamically adapts the number of
   scheduled cells between neighbor nodes, based on the amount of
   currently allocated cells and the neighbor nodes' cell requirements.
   Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis
   the number of cell(s) to be added/deleted.  SFX uses the 6P signaling
   messages to add/delete cells in the schedule.  This function selects
   the candidate cells from the schedule, defines which cells will be
   added/deleted and triggers the allocation/deallocation process.





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.

The IETF Secretariat



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Prof. Diego Dujovne]

Thomas,
 I agree, that could be another document or it can become
a common section used by all the SFs as a bootstrap process.
Regards,

   Diego Dujovne

2017-10-31 14:40 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:

> Diego,
> I don't think that's a good idea. The SF shuld be a standalone document.
> Cutting it into piece will IMO add delays. Plus, I want the SF(s) to really
> be the end of the story, i.e. not leave other things open that are
> undefined in the SF.
> Thomas
>
> On Tue, Oct 31, 2017 at 6:36 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>> I would also separate the first part as a BCP as it happened
>> in RFC8180, to concentrate on the 6P requirements, in order
>> to provide a common structure to the SFs.
>> Regards,
>>
>>Diego Dujovne
>>
>> 2017-10-31 13:55 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:
>>
>>> That's exactly what we need to discuss in Singapore.
>>>
>>> On Tue, Oct 31, 2017 at 2:50 PM, Prof. Diego Dujovne <
>>> diego.dujo...@mail.udp.cl> wrote:
>>>
>>>> My proposal would be to merge both SFX and MSF since
>>>> they look complementary - from my point of view -.
>>>> Any comments?
>>>> Regards,
>>>>
>>>> Diego
>>>>
>>>> 2017-10-31 10:43 GMT-03:00 Prof. Diego Dujovne <
>>>> diego.dujo...@mail.udp.cl>:
>>>>
>>>>> Dear all,
>>>>>  From a fast overview of the draft:
>>>>>
>>>>> 1- The scheduling algorithm looks like a particular case of th SF0
>>>>> (now SFX)
>>>>> 2- The collision detection algorithm is similar to what is already
>>>>> stated on SF0 (now SFX) - in SF0  threshold (and before, a percentage) 
>>>>> above
>>>>> the average value is used to trigger a cell relocation event.
>>>>> 3- For the time being, both recommended values and formulas have no
>>>>> experimental
>>>>> validation, which leads to the experimental track, instead of the
>>>>> standards track, as it
>>>>> happened to SF0 to become SFX.
>>>>>
>>>>> Do you agree?
>>>>>
>>>>> Thank you.
>>>>> Regards,
>>>>>
>>>>>   Diego
>>>>>
>>>>>
>>>>>
>>>>> 2017-10-31 9:57 GMT-03:00 Tengfei Chang <tengfei.ch...@inria.fr>:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> The attached is the txt format for the draft-ietf-6tisch-6top-msf-00.
>>>>>> You can refer to this attachment for now.
>>>>>>
>>>>>> Tengfei
>>>>>>
>>>>>> On Tue, Oct 31, 2017 at 1:33 PM, Pascal Thubert (pthubert) <
>>>>>> pthub...@cisco.com> wrote:
>>>>>>
>>>>>>> Hello Tengfei :
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> For those interested, would 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.udp.cl>
>>>>>>> *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>;
>>>>>>> 6tisch@ietf.org
>>>>>>> *Subject:* Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd,
>>>>>>> 2017
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Diego, All,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Because of my mistake, I failed to submit this draft before the
>>>>>>> deadline. We are waiting for the message from the administration to see 
>>>>>>> if
>>>>>>> it's pos

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Prof. Diego Dujovne]

I would also separate the first part as a BCP as it happened
in RFC8180, to concentrate on the 6P requirements, in order
to provide a common structure to the SFs.
Regards,

   Diego Dujovne

2017-10-31 13:55 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:

> That's exactly what we need to discuss in Singapore.
>
> On Tue, Oct 31, 2017 at 2:50 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>> My proposal would be to merge both SFX and MSF since
>> they look complementary - from my point of view -.
>> Any comments?
>> Regards,
>>
>>         Diego
>>
>> 2017-10-31 10:43 GMT-03:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl
>> >:
>>
>>> Dear all,
>>>  From a fast overview of the draft:
>>>
>>> 1- The scheduling algorithm looks like a particular case of th SF0 (now
>>> SFX)
>>> 2- The collision detection algorithm is similar to what is already
>>> stated on SF0 (now SFX) - in SF0  threshold (and before, a percentage) above
>>> the average value is used to trigger a cell relocation event.
>>> 3- For the time being, both recommended values and formulas have no
>>> experimental
>>> validation, which leads to the experimental track, instead of the
>>> standards track, as it
>>> happened to SF0 to become SFX.
>>>
>>> Do you agree?
>>>
>>> Thank you.
>>> Regards,
>>>
>>>   Diego
>>>
>>>
>>>
>>> 2017-10-31 9:57 GMT-03:00 Tengfei Chang <tengfei.ch...@inria.fr>:
>>>
>>>> Hi,
>>>>
>>>> The attached is the txt format for the draft-ietf-6tisch-6top-msf-00.
>>>> You can refer to this attachment for now.
>>>>
>>>> Tengfei
>>>>
>>>> On Tue, Oct 31, 2017 at 1:33 PM, Pascal Thubert (pthubert) <
>>>> pthub...@cisco.com> wrote:
>>>>
>>>>> Hello Tengfei :
>>>>>
>>>>>
>>>>>
>>>>> For those interested, would 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.udp.cl>
>>>>> *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>; 6tisch@ietf.org
>>>>> *Subject:* Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017
>>>>>
>>>>>
>>>>>
>>>>> Diego, All,
>>>>>
>>>>>
>>>>>
>>>>> Because of my mistake, I failed to submit this draft before the
>>>>> deadline. We are waiting for the message from the administration to see if
>>>>> it's possible to submit it.
>>>>>
>>>>> I will keep you all update.
>>>>>
>>>>>
>>>>>
>>>>> My apologies for the mistake!
>>>>>
>>>>>
>>>>>
>>>>> Tengfei
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
>>>>> diego.dujo...@mail.udp.cl> wrote:
>>>>>
>>>>> Dear all,
>>>>>
>>>>>  I cannot find the text for:
>>>>>
>>>>>
>>>>>
>>>>> draft-chang-6tisch-6top-msf
>>>>>
>>>>>
>>>>>
>>>>> Can you provide a link?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>>
>>>>>   Diego
>>>>>
>>>>>
>>>>>
>>>>> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) <
>>>>> pthub...@cisco.com>:
>>>>>
>>>>> Dear all :
>>>>>
>>>>>
>>>>>
>>>>> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>>>>>
>>>>> We plac

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Prof. Diego Dujovne]

My proposal would be to merge both SFX and MSF since
they look complementary - from my point of view -.
Any comments?
Regards,

Diego

2017-10-31 10:43 GMT-03:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>:

> Dear all,
>  From a fast overview of the draft:
>
> 1- The scheduling algorithm looks like a particular case of th SF0 (now
> SFX)
> 2- The collision detection algorithm is similar to what is already stated
> on SF0 (now SFX) - in SF0  threshold (and before, a percentage) above
> the average value is used to trigger a cell relocation event.
> 3- For the time being, both recommended values and formulas have no
> experimental
> validation, which leads to the experimental track, instead of the
> standards track, as it
> happened to SF0 to become SFX.
>
> Do you agree?
>
> Thank you.
> Regards,
>
>   Diego
>
>
>
> 2017-10-31 9:57 GMT-03:00 Tengfei Chang <tengfei.ch...@inria.fr>:
>
>> Hi,
>>
>> The attached is the txt format for the draft-ietf-6tisch-6top-msf-00. You
>> can refer to this attachment for now.
>>
>> Tengfei
>>
>> On Tue, Oct 31, 2017 at 1:33 PM, Pascal Thubert (pthubert) <
>> pthub...@cisco.com> wrote:
>>
>>> Hello Tengfei :
>>>
>>>
>>>
>>> For those interested, would 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.udp.cl>
>>> *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>; 6tisch@ietf.org
>>> *Subject:* Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017
>>>
>>>
>>>
>>> Diego, All,
>>>
>>>
>>>
>>> Because of my mistake, I failed to submit this draft before the
>>> deadline. We are waiting for the message from the administration to see if
>>> it's possible to submit it.
>>>
>>> I will keep you all update.
>>>
>>>
>>>
>>> My apologies for the mistake!
>>>
>>>
>>>
>>> Tengfei
>>>
>>>
>>>
>>> On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
>>> diego.dujo...@mail.udp.cl> wrote:
>>>
>>> Dear all,
>>>
>>>  I cannot find the text for:
>>>
>>>
>>>
>>> draft-chang-6tisch-6top-msf
>>>
>>>
>>>
>>> Can you provide a link?
>>>
>>> Thank you.
>>>
>>> Regards,
>>>
>>>
>>>
>>>   Diego
>>>
>>>
>>>
>>> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com
>>> >:
>>>
>>> Dear all :
>>>
>>>
>>>
>>> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>>>
>>> We placed a draft agenda on the IETF tools site
>>>
>>> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-
>>> 17-6tisch-01/
>>>
>>> At the time of the posting it reads as follows; please let us know if we
>>> need to consider changing anything before next Monday.
>>>
>>>
>>>
>>> The chairs.
>>>
>>>
>>> Connection details
>>> --
>>>
>>> * Date: 3 November 2017  7-8am Pacific
>>> http://www.worldtimebuddy.com/?qm=1=100,12,5392171,18501
>>> 47=100=2017-11-03=14-15
>>> * Webex Meeting:
>>> https://cisco.webex.com/ciscosales/j.php?MTID=m829e5143deab3
>>> 957a95b6cdb44fff299
>>> * Meeting number (access code): 208 468 097
>>> * Meeting password: B2FVVAkM (22388256 from phones)
>>> * Material link:
>>> https://bitbucket.org/6tisch/meetings/raw/master/170908_webe
>>> x/slides_170908_webex.ppt
>>>
>>> Agenda
>>> --
>>>
>>> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>>>
>>> * Status of the work[ 5min]
>>>
>>> * IETF 100 prep   (chairs)  [15min]
>>>
>>> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Prof. Diego Dujovne]

Dear all,
 From a fast overview of the draft:

1- The scheduling algorithm looks like a particular case of th SF0 (now SFX)
2- The collision detection algorithm is similar to what is already stated
on SF0 (now SFX) - in SF0  threshold (and before, a percentage) above
the average value is used to trigger a cell relocation event.
3- For the time being, both recommended values and formulas have no
experimental
validation, which leads to the experimental track, instead of the standards
track, as it
happened to SF0 to become SFX.

Do you agree?

Thank you.
Regards,

  Diego



2017-10-31 9:57 GMT-03:00 Tengfei Chang <tengfei.ch...@inria.fr>:

> Hi,
>
> The attached is the txt format for the draft-ietf-6tisch-6top-msf-00. You
> can refer to this attachment for now.
>
> Tengfei
>
> On Tue, Oct 31, 2017 at 1:33 PM, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Hello Tengfei :
>>
>>
>>
>> For those interested, would 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.udp.cl>
>> *Cc:* Pascal Thubert (pthubert) <pthub...@cisco.com>; 6tisch@ietf.org
>> *Subject:* Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017
>>
>>
>>
>> Diego, All,
>>
>>
>>
>> Because of my mistake, I failed to submit this draft before the deadline.
>> We are waiting for the message from the administration to see if it's
>> possible to submit it.
>>
>> I will keep you all update.
>>
>>
>>
>> My apologies for the mistake!
>>
>>
>>
>> Tengfei
>>
>>
>>
>> On Tue, Oct 31, 2017 at 12:10 PM, Prof. Diego Dujovne <
>> diego.dujo...@mail.udp.cl> wrote:
>>
>> Dear all,
>>
>>  I cannot find the text for:
>>
>>
>>
>> draft-chang-6tisch-6top-msf
>>
>>
>>
>> Can you provide a link?
>>
>> Thank you.
>>
>> Regards,
>>
>>
>>
>>   Diego
>>
>>
>>
>> 2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:
>>
>> Dear all :
>>
>>
>>
>> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>>
>> We placed a draft agenda on the IETF tools site
>>
>> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-17-6tisch-01/
>>
>> At the time of the posting it reads as follows; please let us know if we
>> need to consider changing anything before next Monday.
>>
>>
>>
>> The chairs.
>>
>>
>> Connection details
>> --
>>
>> * Date: 3 November 2017  7-8am Pacific
>> http://www.worldtimebuddy.com/?qm=1=100,12,5392171,18501
>> 47=100=2017-11-03=14-15
>> * Webex Meeting:
>> https://cisco.webex.com/ciscosales/j.php?MTID=m829e5143deab3
>> 957a95b6cdb44fff299
>> * Meeting number (access code): 208 468 097
>> * Meeting password: B2FVVAkM (22388256 from phones)
>> * Material link:
>> https://bitbucket.org/6tisch/meetings/raw/master/170908_webe
>> x/slides_170908_webex.ppt
>>
>> Agenda
>> --
>>
>> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>>
>> * Status of the work[ 5min]
>>
>> * IETF 100 prep   (chairs)  [15min]
>>
>> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min]
>>
>> * draft-chang-6tisch-6top-msf   (Tengfei Chang) [20min]
>>
>> * Any Other Business, IEEE status[QS]
>>
>>
>>
>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>>
>>
>> --
>>
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - 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
>>
>>
>>
>>
>>
>> --
>>
>> Chang Tengfei,
>>
>> Pre-Postdoctoral Research Engineer, Inria
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Agenda, 6TiSCH WG interim, November 3rd, 2017

[Prof. Diego Dujovne]

Dear all,
 I cannot find the text for:

draft-chang-6tisch-6top-msf

Can you provide a link?
Thank you.
Regards,

  Diego

2017-10-31 6:35 GMT-03:00 Pascal Thubert (pthubert) :

> Dear all :
>
>
>
> *Note: Due to EU going CET this WE, this meeting is at 3PM CET!*
>
> We placed a draft agenda on the IETF tools site
>
> https://datatracker.ietf.org/doc/agenda-interim-2017-6tisch-17-6tisch-01/
>
> At the time of the posting it reads as follows; please let us know if we
> need to consider changing anything before next Monday.
>
>
>
> The chairs.
>
>
> Connection details
> --
>
> * Date: 3 November 2017  7-8am Pacific
> http://www.worldtimebuddy.com/?qm=1=100,12,5392171,
> 1850147=100=2017-11-03=14-15
> * Webex Meeting:
> https://cisco.webex.com/ciscosales/j.php?MTID=
> m829e5143deab3957a95b6cdb44fff299
> * Meeting number (access code): 208 468 097
> * Meeting password: B2FVVAkM (22388256 from phones)
> * Material link:
> https://bitbucket.org/6tisch/meetings/raw/master/170908_
> webex/slides_170908_webex.ppt
>
> Agenda
> --
>
> * Note-Well, Blue Sheets, Scribes, Agenda Bashing   [ 5min]
>
> * Status of the work[ 5min]
>
> * IETF 100 prep   (chairs)  [15min]
>
> * draft-ietf-6tisch-minimal-security (Malisa Vucinic)   [15min]
>
> * draft-chang-6tisch-6top-msf   (Tengfei Chang) [20min]
>
> * Any Other Business, IEEE status[QS]
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Sheperd's WGLC review for draft-ietf-6tisch-6top-protocol-08

[Prof. Diego Dujovne]

All,
Let me chime in. See my coments inline.

Thanks,

  Diego

2017-09-29 9:12 GMT-03:00 Thomas Watteyne :

> Thanks Pascal for the feedback. @Xavi, would you have a second to turn
> those suggestions into issue on the bitbucket repo?
>
> On Fri, Sep 29, 2017 at 12:31 PM, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Dear authors:
>>
>>
>>
>> All in all, I think the document is ready but believe that a pass on
>> language from a native person may help.
>>
>>
>>
>> Also, the document should include a terminology where all the terms are
>> defined, e.g. NumCandidates and so on.
>>
>>
>>
>> Still, Please find my comments, with a [PT] tag associated with text
>> snippets, below:
>>
>>
>>
>> 
>>
>>
>>
>> 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.
>>
>>
>>
>> [PT] that’s too much text on SF which is out of scope. Enough to say that
>> the 6top sublayer comprises the 6P protocol defined here, and a SF that
>> “decides when to add/delete cells, and triggers 6P Transactions”
>>
>> This must be repeated in the intro to position 6P vs. 6top vs. SF
>>
>

According to the 6P draft,
The SF has currently 4 main tasks/functions:
- Decide when to add/delete cells
- Decide when to relocate cells
- Keep up-to date statistics on cells
- Define every transaction timeout

I think that if specific items are mentioned in the
introduction, either all or none of them should
be mentioned.



>
>>
>> 
>>
>>
>>
>> 1.  Introduction
>>
>>
>>
>>All communication in a 6TiSCH network is orchestrated by a schedule
>>
>>[RFC7554].  This specification defines the 6top Protocol (6P), part
>>
>>of the 6TiSCH Operation sublayer (6top).  6P allows a node to
>>
>> [PT] that’s concise! Please introduce that the schedule indicates
>> transmission cells in the [slotOffset,channelOffset] CDU matrix and point
>> at the terminology draft and RFC 7554 for more information.
>>
>> You’ll be needing this a few lines below.
>>
>>
>>
>>communicate with a neighbor to add/delete TSCH cells to one another.
>>
>>This results in distributed schedule management in a 6TiSCH network.
>>
>>
>>
>> 
>>
>>
>>
>>In the context of this specification, all the cells used by 6top are
>>
>>soft cells.  Hard cells can be used for example when "hard-coding" a
>>
>>schedule [RFC8180].
>>
>>
>>
>> [PT] Also ref the 6TiSCH architecture.
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>The 6P messages exchanged between nodes A and B during a 6P
>>
>>Transaction SHOULD be exchanged on dedicated cells between A and B.
>>
>>If no dedicated cells are scheduled between nodes A and B, shared
>>
>>cells MAY be used.
>>
>>
>>
>> [PT] Define dedicated, the reader does not necessarily know what is meant
>> here. Do we need a terminology?
>>
>>
>>
>>
>>
>> 
>>
>>
>>
>>
>>
>>A 6P Transaction can consist of 2 or 3 steps.  An SF MUST specify
>>
>>whether to use 2-step transactions, 3-step transactions, or both.
>>
>>
>>
>> [PT] Hum, the fact that 2 step and 3 steps are meant to enable
>> respectively the requester or the responder to allocate the cells should be
>> said clearly here, before 3.1.1.
>>
>> When the reader is here, he does not figure why there are 2 models.
>>
>
It must be specified that this is a fixed definition of the SF by design,
and it cannot be changed dynamically, so this
item must be specified on the SF requirements list.




>
>>
>> 
>>
>>
>>
>>
>>
>> 3.1.1.  2-step 6P Transaction
>>
>>
>>
>>Figure 4 shows an example 2-step 6P Transaction.  In a 2-step
>>
>>transaction, node A selects the candidate cells.  Several elements
>>
>>are left out to simplify understanding.
>>
>>
>>
>>
>>
>>
>>
>> +--+   +--+
>>
>> |  Node A  |   |  Node B  |
>>
>> ++-+   +-++
>>
>>  |   |
>>
>>  | 6P ADD Request|
>>
>>  |   Type = REQUEST  |
>>
>>  |   Code = ADD  |
>>
>>  |   SeqNum   = 123  |
>>

Re: [6tisch] Regarding IPR on draft-ietf-6tisch-6top-protocol

[Prof. Diego Dujovne]

No, I'm not aware of any IPR that applies to this draft

Le mardi 26 septembre 2017, Pascal Thubert (pthubert) 
a écrit :

> Authors, Contributors, WG,
>
>
>
> As part of the preparation for WG Adoption Call:
>
>
>
> Are you aware of any IPR that applies to drafts identified above?
>
>
>
> Please state either:
>
>
>
> "No, I'm not aware of any IPR that applies to this draft"
>
> or
>
> "Yes, I'm aware of IPR that applies to this draft"
>
>
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see
> RFCs 3669, 5378 and 8179 for more details)?
>
>
>
> If yes to the above, please state either:
>
>
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>
> or
>
> "No, the IPR has not been disclosed"
>
>
>
> If you answer no, please provide any additional details you think
> appropriate.
>
>
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next stage
> until a response has been received from each author and listed contributor.
> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.
>
>
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under the
> IETF IPR rules which encourages you to notify the IETF if you are aware of
> IPR of others on an IETF contribution, or to refrain from participating in
> any contribution or discussion related to your undisclosed IPR. For more
> information, please see the RFCs listed above and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>
>
> Thank you,
>
> 6TiSCH WG Chairs
>
>
>
> PS Please include all listed in the headers of this message in your
> response.
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Fw: Qin comments on SF0

[Prof. Diego Dujovne]

Thomas,
  Yes, I got this e-mail (June 9th).
Regards,

 Diego


2017-06-21 8:13 GMT-04:00 Thomas Watteyne :

> Diego,
> Can you confirm you got this e-mail? One thing that has worked well in the
> past is to track issue raised in either the IETF issue tracker, or the
> tracker part of the repo of our draft.
> Just wanting to make sure we are not forgetting about comments.
> Thomas
>
> On Fri, Jun 9, 2017 at 5:02 PM, Qin Wang  wrote:
>
>> Hi Diego,
>>
>> I'm not sure if you got this email. So, I re-send it.
>>
>> Thanks
>> Qin
>>
>>
>> On Monday, May 1, 2017 5:22 PM, Qin Wang  wrote:
>>
>>
>> Dear authors,
>>
>> I read through SF0 (v4). The following is my comments.
>>
>> 2. Introduction
>> ü   “The Scheduling Algorithm collects the cell *allocation/deletion*
>> requests from the   neighbors and the number of cells which are currently
>> under usage.” ==> addition/deletion? allocation/deallocation?
>>
>> 4.  SF0 Triggering Events
>> ü  What is “cell allocation/deallocation process with the neighbor”? The
>> trigger event is not clear.
>>
>> 5.  SF0 Cell Estimation Algorithm
>> ü  What is incoming cells and outgoing cells? Are they Rx cells and Tx
>> cells, respectively?
>> ü  What is “used cells”? Is it same as “scheduled cells”? If not, how to
>> count used cells.
>>
>> 6.  SF0 Allocation Policy
>> ü  “The number of cells to be *scheduled/deleted*” ==> “added/deleted”?
>> ü  “3. If SCHEDULEDCELLS*<=*REQUIREDCELLS, add one or more cells.” ==>
>> “3. If SCHEDULEDCELLS> ü  When and how the initial value of SCHEDULEDCELLS will be set? The
>> initialization should include not only setting SCHDULEDCELLS equal to
>> SOFTHRESH, but also adding SOFTHRESH cells into schedule for starting the
>> state machine described in Fig.1.
>>
>> 7.  Rules for CellList
>> ü  “verifying that the slot offset and channel offset are not occupied
>> and choose channelOffset randomly for each cell” ==> “verifying that the
>> slot offset is not occupied and choose channelOffset randomly for each cell”
>>
>> 10.  Node Behavior at Boot
>> ü  Should the initialization of SCHEDULEDCELLS happen at boot?
>>
>> If you have any question regarding it, please feel free to contact me.
>>
>> Thanks
>> Qin
>> ___
>> 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
>>
>>
>
>
> --
> ___
>
> 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
> ___
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Timeout implementation on 6P/SF0

[Prof. Diego Dujovne]

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 <qinwang6...@yahoo.com>:

> 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 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...@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 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 <xvilajos...@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
> 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 <l...@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,*
> *Lijo Thomas *
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.or g <6tisch-boun...@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ática y Telecomunicaciones
> Facultad de Ingeniería - 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
> <https://www.f

Re: [6tisch] Timeout implementation on 6P/SF0

[Prof. Diego Dujovne]

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 <xvilajos...@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
> 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 <l...@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,*
>>
>> *Lijo Thomas *
>>
>>
>>
>>
>>
>> *From:* 6tisch [mailto:6tisch-boun...@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ática y Telecomunicaciones
>> Facultad de Ingeniería - 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
>>
>>
>
>
> --
> Dr. Xavier Vilajosana
> Wireless Networks Lab
>
> *Internet Interdisciplinary Institute (IN3)Professor*
> (+34) 646 633 681 <+34%20646%2063%2036%2081>
> xvilajos...@uoc.edu <usu...@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]
> ­
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

[6tisch] Timeout implementation on 6P/SF0

[Prof. Diego Dujovne]

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ática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] comments SF0

[Prof. Diego Dujovne]

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 taken
> 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 details
> 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 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 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 

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-04.txt

[Prof. Diego Dujovne]

Dear all,
 I have changed the status of SF0 to Experimental
and posted revision -04.
Regards,

   Diego

A new version of I-D, draft-ietf-6tisch-6top-sf0-04.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:   draft-ietf-6tisch-6top-sf0
Revision:   04
Title:  6TiSCH 6top Scheduling Function Zero (SF0)
Document date:  2017-04-28
Group:  6tisch
Pages:  12
URL:https://www.ietf.org/internet-drafts/draft-ietf-6tisch-6top-
sf0-04.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-04
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-6tisch-
6top-sf0-04
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-
sf0-04

Abstract:
   This document defines a Scheduling Function called "Scheduling
   Function Zero" (SF0).  SF0 dynamically adapts the number of allocated
   cells between neighbor nodes, based on the amount of currently
   allocated cells and the neighbor nodes' cell requirements.  Neighbor
   nodes negotiate in a distributed neighbor-to-neighbor basis the
   number of cell(s) to be added/deleted.  SF0 uses the 6P signaling
   messages to add/delete cells in the schedule.  This function selects
   the candidate cells from the schedule, defines which cells will be
   added/deleted and triggers the allocation/deallocation process.





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.

The IETF Secretariat




-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

[6tisch] SF0 Performance paper

[Prof. Diego Dujovne]

Dear all,
 As I mentioned during today's interim,
there is a new publication (2017) from authors
currently not related to SF0 that shows SF0
performance in an experimental platform
compared to their own proposal.


http://www.sciencedirect.com/science/article/pii/S092054891730106X

Regards,

 Diego Dujovne

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] nits on draft-ietf-6tisch-6top-sf0-02

[Prof. Diego Dujovne]

Thomas,
 During the last Webex I commented that
I used these comments to modify and correct
the draft. I eliminated (almost) every instance of
"effectively used cell" and fixed the problems
raised by Randy.
Regards,

  Diego

2017-03-28 9:31 GMT-03:00 Thomas Watteyne :

> @Diego, @Authors,
> Any comments?
> Thomas
>
> On Sun, Mar 5, 2017 at 2:13 PM, Yasuyuki Tanaka <
> yasuyuki9.tan...@toshiba.co.jp> wrote:
>
>> Nice comments!
>>
>> I also want to see the definition of "effectively used cell" and
>> how to calculate PDR.
>>
>> In addition, I don't think that we would count the number of
>> cells used for 6P in terms of SF0. Is it correct? In any case,
>> some text on how SF0 should handle traffic or cell usage by 6P
>> would be helpful.
>>
>> Best,
>> Yatch
>>
>>
>> On 2017/03/05 11:20, Randy Turner wrote:
>>
>>> Hi All,
>>>
>>> After reading the current SF0 document, I had a few nits that I thought
>>> I would pass along - hope they’re helpful.
>>>
>>>
>>> Section 2: Introduction
>>>
>>> (The Scheduling Algorithm)
>>>
>>> “…under effective use…”   the choice of wording seems unorthodox.
>>>
>>> Suggest the following  “A portion of these allocated cells will be
>>> effectively utilized by neighbors, while the remaining cells can be
>>> over-provisioned to handle unanticipated increases in cell requirements”
>>>
>>> (The Relocation Algorithm)
>>>
>>> “Allocated cells may experiment packet loss” should be “Allocated cells
>>> may experience packet loss…”
>>>
>>>
>>>
>>> Section 4: SF0 Triggering Events
>>>
>>> 1. “…change in the current number of used cells”  - could this be
>>> paraphrased to say “…a change in the number of required cells”  ?
>>>
>>>
>>>
>>> Section 5: SF0 Estimation Algorithm
>>>
>>> The Cell Estimation Algorithm steps, # 2 - What is an “effectively” used
>>> cell?  Could this just say “Collect the current number of used cells” ?
>>>
>>> There is actually quite a bit of emphasis in this document on the idea
>>> of an “effectively used cell” - perhaps we should explain the concept of an
>>> effectively used cell (or a reference if it’s already defined) - I was
>>> curious why the term “effective” is used so often?  In the “Cell Estimation
>>> Algorithm” Step #2, the text reads:
>>> “Collect the current number of effectively used cells” — which would
>>> seem to imply that ineffectively used cells wouldn’t be included in this
>>> step.  This may seem a too literal interpretation, I’m just looking for
>>> clarity as to whether or not the term “effective” or “effectively” is
>>> really needed in the doc.
>>>
>>>
>>> Section 11: Relocating Cells
>>>
>>> Just for completeness, I would emphasize how PDR is calculated, or
>>> include a reference to some other document if defined elsewhere
>>>
>>>
>>>
>>>
>>> Thanks for this work!
>>> Randy
>>> ___
>>> 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
>>
>
>
>
> --
> ___
>
> 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
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-03.txt

[Prof. Diego Dujovne]

For your information, there is a new version of SF0 available.
Regards,

   Diego Dujovne


A new version of I-D, draft-ietf-6tisch-6top-sf0-03.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:   draft-ietf-6tisch-6top-sf0
Revision:   03
Title:  6TiSCH 6top Scheduling Function Zero (SF0)
Document date:  2017-03-13
Group:  6tisch
Pages:  12
URL:https://www.ietf.org/internet-drafts/draft-ietf-6tisch-6top-
sf0-03.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-
sf0-03

Abstract:
   This document defines a Scheduling Function called "Scheduling
   Function Zero" (SF0).  SF0 dynamically adapts the number of allocated
   cells between neighbor nodes, based on the amount of currently
   allocated cells and the neighbor nodes' cell requirements.  Neighbor
   nodes negotiate in a distributed neighbor-to-neighbor basis the
   number of cell(s) to be added/deleted.  SF0 uses the 6P signaling
   messages to add/delete cells in the schedule.  This function selects
   the candidate cells from the schedule, defines which cells will be
   added/deleted and triggers the allocation/deallocation process.





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.

The IETF Secretariat




-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] 6P "design team" session this Friday, same time as interim meeting

[Prof. Diego Dujovne]

Dear all,
  From the part of the meeting I could attend,
I could not detect an agreement on the timeout calculation,
as 6P requires. Can we discuss this on the ML?
Regards,

 Diego

2016-12-16 17:05 GMT-03:00 Simon Duquennoy :

> Hi all,
>
> Thanks for an fruitful discussion today!
>
> I wanted to follow up on Nicola's thoughts about adding a final 6P
> Confirmation to all transactions.
> There is a fundamental difference in having a 2-way vs 3-way transaction:
> * 2-way: at the end, the initiator A either (1) commits but does not
> know B's state or (2) knows both agreed to abort.
> * 3-way: at the end, the initiator A either (1) aborts but does not
> know B's state or (2) knows both agreed to commit.
>
> In the 2-way case, the initiator never has the guarantee of a successful
> commit.
> In the 3-way case, a SF could choose to re-attempt a transaction
> hoping to reach an agreement to commit. The SF can retry as many times
> as it sees fit, and CLEAR should it not reach an agreement.
>
> Details below:
>
> 2-way transaction:
> PoV of A:
> * Aborts if not getting Response:
>   => Sends no ACK. Knows B also aborts. <<< agree to abort
> * Commits if getting Response:
>   => Sends an ACK. Does not know B's final state.   <<< !uncertainty!
> PoV of B:
> * Aborts if Response not ACKed:
>   => Does not know A's final state. <<< !uncertainty!
> * Commits if Response ACKed:
>   => Knows A also committed.<<< agree to commit
>
> 3-way transaction:
> PoV of A:
> * Aborts if Confirmation not ACKed:
>   => Does not know B's final state. <<< !uncertainty!
> * Commits if Confirmation ACKed:
>   => Knows B also committed.<<< agree to commit
> PoV of B:
> * Aborts if not getting Confirmation:
>   => Sends no ACK. Knows A also aborts. <<< agree to abort
> * Commits if getting Confirmation:
>   => Sends an ACK. Does not know A's final state.   <<< !uncertainty!
>
> Thanks,
> Simon
>
>
> On Thu, Dec 15, 2016 at 5:03 PM, Tengfei Chang 
> wrote:
> > @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> à reponse/confirmation. L2 ACK doesn’t carry any 6P meaning
> >
> > I agree L2 ACK doesn't carry any 6P meaning. But the node indeed commits
> the
> > transaction (adding cell in schedule) after the ACK is sent out/received.
> >
> > [slide-21]
> >
> > ppt> [Q] Are the following sentences correct? They allow a pair of nodes
> > ppt> to open two transactions in parallel. I think these transactions
> > ppy> might cause inconsistency in their schedule generations.
> >
> > draft> Only a single 6P Transaction between two neighbors, in a given
> > draft> direction, can take place at the same time.
> > draft> (snip)
> > draft> Nodes A and B MAY support having two transactions going on at
> > draft> the same time, one in each direction.
> >
> >
> > ppt>  Here is a simple example in which nodes update their schedule
> >
> > ppt>  generation counters after receiving a MAC-level ACK for a 6P
> >
> > ppt>  Response frame:
> >
> > ppt>  Step-1: Node A Send Request  (GAB=0, GBA=0) : Queued
> >
> > ppt> Step-2: Node B Send Request  (GAB=0, GBA=0) : Queued
> >
> > ppt>  Step-3: Node B Recv Request : Send MAC-ACK
> >
> > ppt> Step-4: Node B Send Response (GAB=0, GBA=0) : Queued
> >
> > ppt>  Step-5: Node A Recv Request : Send MAC-ACK
> >
> > ppt> Step-6: Node A Send Response (GAB=0, GBA=0) : Queued
> >
> > ppt>  Step-7: Node A Recv Response: Send MAC-ACK
> >
> > ppt>  Step-8: Node B Update GTX/GRX   : (GTX=0, GRX=1)
> >
> > ppt>  Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect
> Inconsistency
> >
> >
> >
> > This is a good point. So this is called because the GAB/GBA is prepended
> > early.
> > At the implementation view, this could be solved to add GAB/GBA at when
> the
> > queued packet has already being chosen to sent on a cell. This will look
> > like the ASN in EB.
> >
> > Tengfei
> >
> > On Wed, Dec 14, 2016 at 9:21 PM, Yasuyuki Tanaka
> >  wrote:
> >>
> >> Thank you, Thomas.
> >>
> >> Let me add comments on a couple of the ppt slides in advance, which
> >> could save time of the coming meeting, I hope...:
> >>
> >>   The ppt sides Thomas provided:
> >>
> >> https://bitbucket.org/6tisch/meetings/raw/
> c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/
> slides_161209_webex.ppt
> >>
> >> 
> 
> >>
> >> (6P unclarities 2 [1/4], slide-19)
> >>
> >> ppt> Section 4.2.2: 

Re: [6tisch] Call for adoption of draft-richardson-6tisch-dtsecurity-secure-join as WG document

[Prof. Diego Dujovne]

+1

El nov 23, 2016 10:06 AM, "Xavi Vilajosana Guillen" 
escribió:

> Hi, I also support this draft as a zero touch approach to enable secure
> join in 6TiSCH.
>
> regards,
> X
>
> 2016-11-23 8:55 GMT+01:00 Pascal Thubert (pthubert) :
>
>> Dear all :
>>
>> The sense of the room at the WG meeting at IETF 97 in Seoul was that
>> draft-richardson-6tisch-dtsecurity-secure-join and
>> draft-vucinic-6tisch-minimal-security could be combined as a staged join
>> process, the former being optional in the case of a PSK, and that the two
>> documents could be adopted as WG docs.
>>
>> We are now confirming this on the ML and calling for adoption of
>> draft-richardson-6tisch-dtsecurity-secure-join as WG document.
>>
>> The call will be closing in on Friday, December 9th.
>>
>> Please consider the draft carefully and reply to this mail expressing
>> support or disagreement, and in either case, justification for the vote and
>> suggestions are appreciated.
>>
>> The chairs,
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> Dr. Xavier Vilajosana Guillén­
> Research Professor
> Wireless Networks Research Group
> Internet Interdisciplinary Institute (IN3)
> Universitat Oberta de Catalunya­
>
> +34 646 633 681| xvilajos...@uoc.edu­ | Skype­: xvilajosana
> http://xvilajosana.org
> http://wine.rdi.uoc.edu/
>
> Parc Mediterrani de la Tecnologia
> Av. Carl Friedrich Gauss, 5. Edifici B3
> 08860 Castelldefels (Barcelona)
>
>
>
> ­
>
> ___
> 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

Re: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request to old parents

[Prof. Diego Dujovne]

I agree witb Yatch: On Step 1, keep the original CLEAR command at
boot time.

Step 2 is OK for me:
In fact, the only way SF0 would detect that the node is
no longer available or that RPL has decided a parent change
is that there will be no more effectively used cells towards
that neighbour, so only the OVERPROVISION number of
cells will be allocated (maybe plus SF0THRESH).
Given this condition, SF0 will generate a CLEAR command,
thus reducing the number of allocated cells to zero.

Regards,

   Diego





step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by
possibly adding a 4.3.X section:

4.3.X. Disconnecting from a neighbor

   If the SF realizes connection to a particular neighbor is no longer
   needed (for example a change in parent by the routing protocol),
   the SF MAY send a CLEAR request to that neighbor to speed up the
   cleanup process of the cells allocated with that neighbor.


2016-11-22 15:50 GMT-03:00 Yasuyuki Tanaka :

> Hi all,
>
> Here is my opinion:
>
> step 1: one suggestion to keep the original sentence explaining what
> to do in SF0 after the system booting-up or restart. That is,
> no change on draft-ietf-6tisch-6top-sf0-02#section-10.
>
> step 2: +1
>
> Thanks!
> Yatch
>
>
> On 2016/11/22 8:16, Thomas Watteyne wrote:
>
>> In thread "Node Behavior at Boot in SF0" (https://www.ietf.org/mail-arc
>> hive/web/6tisch/current/msg04883.html), we ended up discussing the
>> following paragraph
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:
>>
>>In order to define a known state after the node is restarted, a CLEAR
>>command is issued to each of the neighbor nodes to enable a new
>>allocation process.  The 6P Initial Timeout Value provided by SF0
>>should allow for the maximum number of TSCH link-layer retries, as
>>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
>>REMARK: The initial timeout is currently under discussion.
>>
>> The suggestion on the table is to:
>>
>> step 1. Change https://tools.ietf.org/html/dr
>> aft-ietf-6tisch-6top-sf0-02#section-10 to:
>>
>>The 6P Initial Timeout Value provided by SF0
>>should allow for the maximum number of TSCH link-layer retries, as
>>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
>>REMARK: The initial timeout is currently under discussion.
>>
>> step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by
>> possibly adding a 4.3.X section:
>>
>> 4.3.X. Disconnecting from a neighbor
>>
>>If the SF realizes connection to a particular neighbor is no longer
>>needed (for example a change in parent by the routing protocol),
>>the SF MAY send a CLEAR request to that neighbor to speed up the
>>cleanup process of the cells allocated with that neighbor.
>>
>> I'm hereby opening a call for WG consensus. Please +1 or comment/suggest.
>> The chairs will summarize on Fridat 25 Nov.
>>
>> Thomas
>>
>> --
>> ___
>>
>> 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
>>
>>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] Shared / Dedicated cell policy on SF0

[Prof. Diego Dujovne]

Yakusuki,
   We currently assume that:
- we have no information about the generated traffic from the application
- we do not know which part of the incoming traffic is routed to which
neighbour.

Example: If a both a TX cell and a Shared cell are requested as incoming
to the node, we do not know to which neighbour these cells will be routed,
or if the incoming traffic destination is the node itself.

As a consequence, since the only true source of information is the effective
number of outgoing cells, our default behavior is to allocate dedicated TX
cells
to the specific neighbour.

I think the reason to use TX or Shared cells as a default, is covered by
Thomas' answer.

Thank you.
Regards,

  Diego

2016-11-16 8:33 GMT-03:00 Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp>:

> Hi Diego,
>
> diego> b) if we keep working with the initial assumption, and do not
> diego> allow any shared cells to be scheduled by SF0.
>
> Why is scheduling shared cells not allowed by the initial assumption?
> I'm a relative newcomer to 6TiSCH and not sure about the initial
> assumption...
>
> To me, it seems that scheduling shared cells is more sensible in
> Neighbor-to-Neighbor Scheduling than dedicated cells. I would say that
> the SHARED cell bit in the CellOptions field should be always on when
> the field is used for CMD_ADD.
>
> A pair of devices in a 6P conversation have no idea if cells they are
> scheduling are truly dedicated. In general, cells scheduled with 6P
> are possibly shared with multiple TX devices. In other words, I think
> it'd be better to always perform CCA on a cell scheduled with 6P.
>
> Best,
> Yatch
>
>
> On 2016/10/31 22:23, Prof. Diego Dujovne wrote:
>
>> Dear all,
>>  SF0 has assumed until now that it was
>> only working on dedicated cells, but 6P now provides
>> the possibility to use shared cells.
>>
>>  I would like to hear your thoughts on the
>> following alternatives:
>> a) if we allow shared cells to be used SF0, how to
>> establish a policy on which type of cells to allocate.
>> Currently, SF0 observes only the incoming number of
>> cell allocation requests and effectively used cells
>> to calculate the number of required cells.
>> b) if we keep working with the initial assumption, and
>> do not allow any shared cells to be scheduled by SF0.
>>
>> A quick solution would be to define two different instances
>> of SF0, one for shared cells and the other for dedicated
>> ones.
>> Regards,
>>
>>  Diego
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - Universidad Diego Portales - Chile
>> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
>> (56 2) 676 8125
>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Prof. Diego Dujovne]

Thomas,
 It is not on my slides, since the default
behavior (issue a CLEAR command) did not
change from -01 to -02. I can raise the issue
during the presentation.
Regards,

Diego

2016-11-16 12:06 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:

> Diego,
> Fine for me. Could you bring it up during the WG meeting tomorrow?
> Thomas
>
> On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>> Yasuyuki, Thomas,
>>  I suggest to keep the CLEAR command
>> after reboot/failure.
>> Regards,
>>
>>Diego
>>
>> 2016-11-16 11:05 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:
>>
>> @Tengfei,
>> Does that suggestion work for you or should we create an issue on SF0?
>> Thomas
>>
>> On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka <
>> yasuyuki9.tan...@toshiba.co.jp> wrote:
>>
>> Hi Tengfei,
>>
>> I think an assumption there is that a node has no state with its
>> neighbors just after booting up or restarting. On the other hand, a
>> neighbor of them may have cells allocated for the node. 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 restarted, the SF0 says:
>>
>>In order to define a known state after the node is restarted, a CLEAR
>>command is issued to each of the neighbor nodes to enable a new
>>allocation process.  The 6P Initial Timeout Value provided by SF0
>>should allow for the maximum number of TSCH link-layer retries, as
>>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#
>> ref-I-D.ietf-6tisch-6top-protocol>].  TODO/
>>REMARK: The initial timeout is currently under discussion.
>>
>>
>> A little suggestion 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, Inria
>>
>>
>> ___
>> 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
>>
>>
>>
>>
>> --
>> ___
>>
>> 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
>>
>>
>>
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - Universidad Diego Portales - Chile
>> www.ingenieria.udp.cl
>> (56 2) 676 8125
>>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Prof. Diego Dujovne]

Yasuyuki, Thomas,
 I suggest to keep the CLEAR command
after reboot/failure.
Regards,

   Diego

2016-11-16 11:05 GMT-03:00 Thomas Watteyne :

> @Tengfei,
> Does that suggestion work for you or should we create an issue on SF0?
> Thomas
>
> On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka <
> yasuyuki9.tan...@toshiba.co.jp> wrote:
>
>> Hi Tengfei,
>>
>> I think an assumption there is that a node has no state with its
>> neighbors just after booting up or restarting. On the other hand, a
>> neighbor of them may have cells allocated for the node. 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 restarted, the SF0 says:
>>>
>>>In order to define a known state after the node is restarted, a CLEAR
>>>command is issued to each of the neighbor nodes to enable a new
>>>allocation process.  The 6P Initial Timeout Value provided by SF0
>>>should allow for the maximum number of TSCH link-layer retries, as
>>>defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol <
>>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#r
>>> ef-I-D.ietf-6tisch-6top-protocol>].  TODO/
>>>REMARK: The initial timeout is currently under discussion.
>>>
>>>
>>> A little suggestion 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, Inria
>>>
>>>
>>> ___
>>> 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
>>
>
>
>
> --
> ___
>
> 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
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] SF0 Cell Estimation Algorithm (draft-ietf-6tisch-6top-sf0-02)

[Prof. Diego Dujovne]

2016-11-11 17:14 GMT-03:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>:

> Yasuyuki,
>   -02 version does not take into account symmetry.
> In fact, we do not specify which type of cells (RX,TX) we
> are allocating, we only say that we need to allocate them as
> an introduction to the section.
>   We implicitly assume that we are allocating TX
> traffic (which is RX from the point of view of the neighbour).
> The opposite sense is correct: If the neighbour needs TX traffic,
> it is RX for the node.
>   We do not specify on the draft where (i.e. from which
> neighbour)
> the incoming traffic comes from. In fact, the incoming traffic can arrive
> from any neighbour. However, if we assume that we are using RPL, all the
> traffic from the child nodes is forwarded to the parent in the TX sense,
> while downstream traffic would be parent->node->slave.
>  IMHO, I believe you are right when you say that taking into
> account only the outgoing traffic is a good estimator on the number of
> required cells, since it includes not only the locally generated traffic
> but also the
> traffic from the neighbours traversing the node to that neighbour.
> Furthermore, it would be more accurate (and overprovisioning could be
> smaller)
> because we assume also that we are not using track nor flow identifiers to
> map incoming traffic from the other nodes to the neighbours.
>  I think the symmetry interpretation comes from
> the idea that we are measuring the incoming cell requests from
> a specific neighbour and then adding the outgoing number of cells
> to the same neighbour and calculate the total amount of required cells.
> But we still have to differentiate between TX and RX cells.
> Hope this helps.
> Let me know your thoughts about it.
> Regards,
>
> Diego Dujovne
>
>
>
>
>
>
> 2016-11-11 14:20 GMT-03:00 Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp
> >:
>
>> Hi all,
>>
>> I'd appreciate it if someone could help me understand SF0 Cell
>> Estimation Algorithm mentioned in draft-ietf-6tisch-6top-sf0-02...
>>
>> https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5
>>
>> What I've read from the draft is that the Cell Estimation Algorithm
>> tries to have at least as many TX cells to a neighbor as RX cells
>> which has been allocated for the neighbor as requested. It seems the
>> algorithm assumes the communication triggering SF0 is symmetric.
>>
>> This idea explains why REQUIREDCELLS is given "by adding the current
>> number of effectively used cells and the new incoming cells
>> requirement." In the draft, cells requested to the allocation policy
>> by the cell estimation algorithm are always TX. The numbers of
>> SCHEDULEDCELLS and REQUIREDCELLS are only about TX cells.
>>
>> Is it correct? If this is the case, I wonder where the assumption,
>> communication with a neighbor is symmetric, comes from.
>>
>> Supposing communication is asymmetric, where a node which has
>> allocated RX cells for a neighbor rarely sends data to it, TX cell
>> allocation triggered by an incoming cell requirement could not only be
>> in vain but also cause unnecessary 6P transactions. With this
>> scenario, it seems better that the estimation algorithm does not to
>> take into account "incoming cell requirements."  I may overlook
>> something...
>>
>> I have another thing to ask, but I'd like to clarify the above first.
>>
>> Best,
>> Yatch
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>
>
>
> --
> DIEGO DUJOVNE
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl
> (56 2) 676 8125
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

[Prof. Diego Dujovne]

Nicola,
 I answer below.
Regards,

   Diego

2016-11-02 12:35 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:

> Diego, Tengfei,
>
> I'll provide comments to each of you.
>
> @Diego: I believe that the change in the estimation algorithm does not
> change the fact that both OTF and SF0 give as output a number of cells to
> add/delete, and this is the point I'm discussing on. If we agree on this
> simple evidence (OTF and SF0 give as output a number of cells to
> add/delete), I don't see why the reasoning related to the ouput of OTF
> should not apply to the reasoning related to SF0 output. So I don't get
> really your issue.
>

What I'm saying is that the number of required cells could change when you
measure the requested cells from the application (an assumption no longer
valid) to the number of effectively used cells (which depends on the
aggregate number of effectively used cells by the node itself plus the ones
used by the forwarded traffic from the neighbors on this particular link)


>
> @Tengfei: the thing you are talking about (a hint on the number of cells
> to be added/deleted) was not expected neither by 6top nor OTF. In fact,
> what you are proposing was already present as idea in a paper on OTF. Now
> we have 6P and SF0. 6P inherits much from 6TOP. Some of the 6TOP features
> not present in 6P are now under the domain of SF0. SF0 inherits both from
> 6TOP and OTF. So the change from 6TOP,OTF to 6P,SF0 does not imply that SF0
> has to specify a specific number of cells to be added/deleted. We wanted
> the protocols to be as general as possible. I don't think that writing down
> a specific way of computing the number of cells to be added/deleted would
> help the generality we want to express as standard.
>
> But there could be something else I'm not considering. Please, don't
> hesitate to share here your thoughts.
>

Nicola, we may suggest a value, without being it mandatory.



>
> Nicola
>
>
> 2016-11-02 16:00 GMT+01:00 Tengfei Chang <tengfei.ch...@gmail.com>:
>
>> Hi Nicola, Diego,
>>
>> I see. Thanks for all your explanation!
>>
>> It would be very helpful if we can see some recommended number of cell or
>> advice how to choose the number of cell in the draft.
>> As Sixtop left lots of details in SF, my thought is SF should give more
>> specific information or clues for developer/implementer to implement.
>> Of course, those information will come out from real experiments.
>>
>> Thanks for all you replying!
>>
>> Tengfei
>>
>>
>> On Wed, Nov 2, 2016 at 3:42 PM, Prof. Diego Dujovne <
>> diego.dujo...@mail.udp.cl> wrote:
>>
>>> Nicola,
>>>I agree with your comment, but the cell estimation
>>> algorithm changed: we now estimate the number of required
>>> cells from the number of requested cells (to add or delete)
>>> and the number of effectively used cells. What is still not clear
>>> to me is if the simulation results from the OTF paper is still valid
>>> given this change. To enable the cell estimation algorithm without
>>> packet loss, we need to guarantee always a small amount of
>>> overprovisioning.
>>>   Let me bring the lost text (from OTF) back to SF0.
>>>   Regards,
>>>
>>>  Diego
>>>
>>> 2016-11-02 11:36 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:
>>>
>>>> Hi Tengei,
>>>>
>>>> the problem you are rising is that you would like to see a number of
>>>> cells to add/delete when comparing required and deleted cells.
>>>>
>>>> The ancestor of SF0, namely OTF, used to specify the following sentence:
>>>>
>>>> The number of soft cells to be scheduled/deleted for bundle resizing
>>>>is out of the scope of this document and implementation-dependant.
>>>>
>>>> In fact, we wanted to let that choice being implementation specific.
>>>>
>>>> What you are proposing (the exact number of cells to add or delete) was
>>>> already implemented in the 6tisch simulator, and it is in fact something
>>>> that has already been used and tested in the following papers:
>>>>
>>>> Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless
>>>> Industrial Networks, IEEE Sensors Journal, 2015
>>>>
>>>> Muraoka et al., Simple Distributed Scheduling with Collision Detection
>>>> in TSCH Networks, IEEE Sensors Journal, 2016
>>>>
>>>> But, a

Re: [6tisch] [6TISCH] RELOCATE command in sixtop?

[Prof. Diego Dujovne]

Pascal,
The relocation process from SF0 is meant
also to detect collisions after random allocation, among
other sources of packet loss, such as narrowband
interference or noise.
Regards,

 Diego

2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) :

> Hello Tengfei;
>
>
>
> this looks very useful in the context of the minimal cell allocation
> (Xavi’s random appropriation and collision detection).
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei
> Chang
> *Sent:* mercredi 2 novembre 2016 15:47
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop?
>
>
>
> All,
>
>
>
> I would like to propose an idea to add a new command called RELOCATE
> command in sixtop.
>
> This RELOCATE sixtop command will contains the cells to be added and
> removed in single packet.
>
>
>
> Without RELOCATE command, the relocation is done through adding one cell
> first then deleting one cell.
>
> With RELOCATE command, once the sixtop transaction for relocation
> successes, the relocation process is done.
>
>
>
> There are several benefit from RELOCATE:
>
>
>
> 1.save overhead of relocation process.
>
> 2. avoid the influence of relocation on SF0. It requires SF0 to take the
> relocation into consideration if the cell 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
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0

[Prof. Diego Dujovne]

Nicola,
   I agree with your comment, but the cell estimation
algorithm changed: we now estimate the number of required
cells from the number of requested cells (to add or delete)
and the number of effectively used cells. What is still not clear
to me is if the simulation results from the OTF paper is still valid
given this change. To enable the cell estimation algorithm without
packet loss, we need to guarantee always a small amount of
overprovisioning.
  Let me bring the lost text (from OTF) back to SF0.
  Regards,

 Diego

2016-11-02 11:36 GMT-03:00 Nicola Accettura :

> Hi Tengei,
>
> the problem you are rising is that you would like to see a number of cells
> to add/delete when comparing required and deleted cells.
>
> The ancestor of SF0, namely OTF, used to specify the following sentence:
>
> The number of soft cells to be scheduled/deleted for bundle resizing
>is out of the scope of this document and implementation-dependant.
>
> In fact, we wanted to let that choice being implementation specific.
>
> What you are proposing (the exact number of cells to add or delete) was
> already implemented in the 6tisch simulator, and it is in fact something
> that has already been used and tested in the following papers:
>
> Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless
> Industrial Networks, IEEE Sensors Journal, 2015
>
> Muraoka et al., Simple Distributed Scheduling with Collision Detection in
> TSCH Networks, IEEE Sensors Journal, 2016
>
> But, as already said, this is just a way you can allocate cells. I guess
> we don't want to restrict that setting to a particular algorithm choice.
>
> Hope this helps.
>
> Nicola
>
> 2016-11-02 14:59 GMT+01:00 Tengfei Chang :
>
>> Hi All,
>>
>> I am reading the SF0-02 version which is just released few days ago.
>>
>> In the SF0 Allocation Policy section, the policy said
>>
>>1.  If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more
>>cells.
>>2.  If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do
>>nothing.
>>3.  If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells.
>>
>>
>>
>> Personally thinking, add/delete one cells may call the sixtop many times
>> which is not efficiency, add/delete more cells is not clear to the
>> implementer.
>> I guess there is a decision to say when to add one cell and when to add
>> more cells. But I didn't find it in SF0 draft.
>> Is there any reason why we doesn't say specific number of cells?
>>
>> If no, I think we can add/remove the number of cells to make sure the
>> scheduled cells equals to the required cells plus half of SF0THRESH, which
>> will help stabilize a little bit of the SF0, in case the sixtop is calling
>> too often.
>>
>> Which means: if SCHEDULEDCELLS<=REQUIREDCELLS:
>>
>> 1. when there is no cell in the schedule add one cell
>> 2. when there is at least one cell in schedule, add
>> REQUIREDCELLS-SCHEDULEDCELLS+(SF0THRESH+1)/2 number of cells
>>
>> if REQUIREDCELLS<(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 Research Engineer, Inria
>>
>> ___
>> 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
>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] SF Timeout calculation (Ticket #53)

[Prof. Diego Dujovne]

Nicola,
   I created a new thread to discuss this item.
Can you continue there so as separate the topics?
Thank you.
Regards,

   Diego

2016-10-31 19:29 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:

> Diego,
>
> defining priorities about the management of packets is implementation
> specific, I guess. But I can be wrong.
>
> To be honest, from what I saw in practical implementations, the best is to
> give the highest priority to 6P packets both on shared and dedicated cells,
> because they are in charge to enlarge/reduce bandwidth starting from
> 'minimal'.
>
> Data will be always be created and, if you don't give priority to 6P
> negotiations, they will quickly fill up queues while congesting the small
> bandwidth available. Data must be able to travel only if the network is
> sufficiently capable - if there are dedicated cells. To get dedicated cells
> you need first 6P negotiations.
>
> If the network has sufficient bandwith (dedicated cells have been
> allocated very quickly), data will use the average bandwidth and there will
> not be many negotiations.
>
> I know it's counter-intuitive: if you give more priority to 6P packets you
> will in fact allow data to stay very comfortable in the dedicated cells
> allocated.
>
> Nicola
>
>
> 2016-10-31 20:48 GMT+01:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>
> :
>
>> Nicola,
>> I would try to focus on the draft, however, let me answer
>> briefly
>> the shared/dedicated point of view below.
>> Regards,
>>
>>Diego
>>
>> 2016-10-31 15:18 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:
>>
>>> Hi Diego,
>>>
>>> thank you for your answer too.
>>>
>>> However there are two points I would like to point out.
>>>
>>> First, the mac-layer ack is in fact the TSCH ack, that travels on the
>>> air during the same timeslot of the data packet. It is sent if the data
>>> packet is unicast, either on shared or on dedicated cells. The 6P ACK I'm
>>> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it
>>> requires its own TSCH ack from B to A.
>>>
>>
>> First, I do not expect packets which are not Unicast during a
>> negotiation. What the SF needs to calculate the
>> timeout is any type of signalling confirming that the A->B request packet
>> has arrived to B. If this signal is
>> a different packet, it will take longer to arrive, but its meaning is not
>> different from what we need to start the timeout countdown.
>> So, if there is no time during the timeslot to bring upstream (to the SF)
>> the MAC ACK, then, it will do it in the next transmission opportunity,
>> which may happen in the next available slot. But the timeout countdown will
>> not start until that event happens.
>> In the way back, (the request response from B to A) there will be a MAC
>> ACK too, which will be in turn brought upstream (to the SF) in the same way
>> as it was brought the request from A to B, if there is no time in the
>> current timeslot, it will be done during the next transmission opportunity.
>>
>>
>>>
>>> Second, I'm totally not aligned on "...dedicated cells are for data and
>>> shared cells for any kind of signalling and/or negotiation." and I believe
>>> this is not the distinction between those types of cells.
>>>
>>> Shared or dedicated cells can be used either for signaling and/or data.
>>>
>>
>> I understand your point on the flexibility to use any of them for
>> different purposes, but I would prioritize higher reliability (dedicated
>> cells) for data, while leaving negotiations for shared cells. As a matter
>> of fact, 6P now allows SFs to allocate either type of cells.
>>
>>
>>>
>>> 'Minimal'. as an example, has got a single shared cell. One can run
>>> minimal without any other more sophisticated scheduling technique just
>>> using that shared cell for both signaling and data. The same is possible if
>>> someone uses a dynamic schedule and uses also dedicated cells. I don't see
>>> any reason for forbidding dedicated cells to vehiculate both signaling and
>>> data. The difference is that in shared cells there's contention.
>>>
>>
>> I see that a balance on the schedule is needed  to address both
>> scalability and reliability. You can base your whole scheduling on shared
>> or dedicated cells, it is up to the SF now to decide where to expand and to
>> decide which ty

Re: [6tisch] SF Timeout calculation (Ticket #53)

[Prof. Diego Dujovne]

Nicola,
   One recent inconsistency check on 6P is the
Schedule Generation, defined on the 6top protocol
draft on:

4.3.11.  Generation Management

section. Maybe this helps reducing the inconsistency
you are mentioning without increasing the timeout.
Regards,

  Diego


2016-10-31 19:09 GMT-03:00 Nicola Accettura <nick.accett...@gmail.com>:

> Qin, Diego,
>
> I'll try to explain better my point of view.
>
> Referring to the very helpful scheme that Qin presented, I would say that
> time between t3 and t5 will happen almost instantaneously with respect to
> the timeslot duration, since those are operations triggered by the correct
> reception of an ADD request by node B.
>
> The problem stands out in calculating the time between t5 and t6, this is
> the timeout calculation we should focus on. Since the time between t3 and
> t5 is very small, it does not change the following reasoning to say that we
> want to compute the timeout as function of [t3...t6]. So, my point of view
> starts by the same premises as Diego's.
>
> What I'm worried about is the value to assign to this timeout. Let's
> forget by now about the 6P ACK (maybe it's better to open another thread
> for that later).
>
> I guess that the aim is that we don't want the ADD response to arrive when
> the timeout is expired.
>
> If the ADD response arrives after the timeout, the MAC frame containing
> the 6P ADD response will be acked anyway. This will produce a disagreement
> on the scheduled cells between A and B. Node A, although it received the 6P
> ADD answer, it will consider that answer out of time and it will not add
> any TX cell. At the same time, node B will add RX cells, because it was
> acknowledged by A for the correct delivery of the 6P ADD response. Node A,
> since it feels not satisfied (still no allocated cells), will continue
> asking for new cells to B. Cells available will terminate very quickly on B
> if there are many motes competing to get bandwidth to B.
>
> This happens if the timeout is shorter than the unpredictable time we want
> to estimate.
>
> If the timeout is long enough for containing the maximum of that
> unppredictable time, i.e., the time interval [t3...t6], the 6P ADD answer
> will always arrive while node A is waiting for the answer. If it does not
> arrive in this maximum time, it will never arrive.
>
> Let's evaluate that maximum. Timeslot long 10 ms, slotframe 101 timeslots,
> maxRetries 3. As in Qin example. There is also the first try, so TXATTEMPTS
> = maxRetries + 1 = 4.
>
> Each try to send a packet happens randomly in the current backoff
> interval. In the worst case, the backoff time is chosen in the biggest
> backoff interval [0, 2^macMaxBE - 1]. In the really worst case, node B will
> choose to transmit in 2^macMaxBE shared cells. If macMaxBE is 4 (as in
> OpenWSN, but 7 according to the IEEE802.15.4e standard), the time to
> transmit the packet just the first time could be in 2^4 = 16 shared slots.
> In other words, if there is only one shared cell, according to 'minimal',
> that time will be around 16 seconds. This is the worst case, I know, but we
> want to be sure that timeout does not expire before the actual time that
> node B can take to ship the ADD response to A.
>
> 16 seconds is just the time for sending a packet. That must be multiplied
> by TXATTEMPTS = 4. So the timeout should be more than 1 minute long. If it
> expires and node A has not received the 6P ADD response, it means that it
> won't receive that 6P ADD response later, and, as a consequence, there will
> be no inconsistency.
>
> The formula that I have in mind for the timeout calculation is:
>
> timeout = 2^macMaxBE * TXATTEMPT [# executed shared cells]
>
> and I would let the unity of measure be the number of shared cells. In
> other words, if timeout comes to be 64, this means that the timeout will
> expire just after the 64th shared cell.
>
> I'm not expressing the timeout in seconds, because the number of shared
> cells per slotframe could be more than one. In fact, the backoff mechanism
> is only computed on shared cells.
>
> If then is still preferable to express the timeout in seconds, and
> assuming that there is a single shared cell in a slotframe, the timeout
> formula should look like the following:
>
> timeout = 2^macMaxBE * TXATTEMPT * Slotframe_length_in_seconds [seconds]
>
> Do you see why I'm saying that the timeout that does not produce
> inconsistencies is very long?
>
> What do you feel is incorrect in my approach?
>
> Nicola
>
>
>
>
>
> 2016-10-31 22:05 GMT+01:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl>
> :
>
>> Qin,
>>Well, my scheme t

[6tisch] Shared / Dedicated cell policy on SF0

[Prof. Diego Dujovne]

Dear all,
 SF0 has assumed until now that it was
only working on dedicated cells, but 6P now provides
the possibility to use shared cells.

 I would like to hear your thoughts on the
following alternatives:
a) if we allow shared cells to be used SF0, how to
establish a policy on which type of cells to allocate.
Currently, SF0 observes only the incoming number of
cell allocation requests and effectively used cells
to calculate the number of required cells.
b) if we keep working with the initial assumption, and
do not allow any shared cells to be scheduled by SF0.

A quick solution would be to define two different instances
of SF0, one for shared cells and the other for dedicated
ones.
Regards,

 Diego

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] SF Timeout calculation (Ticket #53)

[Prof. Diego Dujovne]

Nicola,
I would try to focus on the draft, however, let me answer
briefly
the shared/dedicated point of view below.
Regards,

   Diego

2016-10-31 15:18 GMT-03:00 Nicola Accettura :

> Hi Diego,
>
> thank you for your answer too.
>
> However there are two points I would like to point out.
>
> First, the mac-layer ack is in fact the TSCH ack, that travels on the air
> during the same timeslot of the data packet. It is sent if the data packet
> is unicast, either on shared or on dedicated cells. The 6P ACK I'm
> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it
> requires its own TSCH ack from B to A.
>

First, I do not expect packets which are not Unicast during a negotiation.
What the SF needs to calculate the
timeout is any type of signalling confirming that the A->B request packet
has arrived to B. If this signal is
a different packet, it will take longer to arrive, but its meaning is not
different from what we need to start the timeout countdown.
So, if there is no time during the timeslot to bring upstream (to the SF)
the MAC ACK, then, it will do it in the next transmission opportunity,
which may happen in the next available slot. But the timeout countdown will
not start until that event happens.
In the way back, (the request response from B to A) there will be a MAC ACK
too, which will be in turn brought upstream (to the SF) in the same way as
it was brought the request from A to B, if there is no time in the current
timeslot, it will be done during the next transmission opportunity.


>
> Second, I'm totally not aligned on "...dedicated cells are for data and
> shared cells for any kind of signalling and/or negotiation." and I believe
> this is not the distinction between those types of cells.
>
> Shared or dedicated cells can be used either for signaling and/or data.
>

I understand your point on the flexibility to use any of them for different
purposes, but I would prioritize higher reliability (dedicated cells) for
data, while leaving negotiations for shared cells. As a matter of fact, 6P
now allows SFs to allocate either type of cells.


>
> 'Minimal'. as an example, has got a single shared cell. One can run
> minimal without any other more sophisticated scheduling technique just
> using that shared cell for both signaling and data. The same is possible if
> someone uses a dynamic schedule and uses also dedicated cells. I don't see
> any reason for forbidding dedicated cells to vehiculate both signaling and
> data. The difference is that in shared cells there's contention.
>

I see that a balance on the schedule is needed  to address both scalability
and reliability. You can base your whole scheduling on shared or dedicated
cells, it is up to the SF now to decide where to expand and to decide which
type of traffic goes where. Before, there was the assumption of having only
a single best-effort track. Now we have two type of cells to decide on at
the SF. It is not specified yet on the SF0 draft, but a decision on this
matter must be taken.


>
> I would add that it could be possible to piggyback 6P signaling with data
> from upper layers, if there is space in the MTU. It is the encapsulation
> that makes the distinction between data and 6P signaling. Data go
> encapsulated within the IEEE802.15.4e packet payload, while 6P goes into
> the payload IEs, and these two payloads can coexist in the same
> IEEE802.15.4e frame.
>

I expect seeing opportunistic piggybacking instead of reserving a whole new
cell only for negotiation. In fact, the new cell must be negotiated itself
through the SF. Again, this may be a implementation specific, but it would
reduce power consumption.


>
> Thoughts?
>
> Nicola
>
>



-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] SF Timeout calculation (Ticket #53)

[Prof. Diego Dujovne]

aller. At this point, I would say that the unity of
>> measure of the timeout should be the number of executed shared cells, so
>> that the timeout can be safely be proportional just to the product of
>> TXATTEMPTS and the maximum backoff window.
>>
>> Yes, this causes to have a very long timeout, with possible (and actually
>> frequent) desynchronizations. Especially when the network is forming, all
>> nodes will ask for dedicated cells, many 6P packets will get lost.
>> Keepalives will be triggered, but this worsen the situation. Everything is
>> very very bad.
>>
>> Is that possible to have a shorter timeout?
>>
>> My answer is 'yes'. But we need something else: a 6P ACK.
>>
>> In fact, assume that A sent a request, B acked at MAC layer. Then B
>> (maybe after many tries, if the responses have been lost, and this is
>> possible in the 'minimal' shared cell due to collisions in big networks) is
>> finally able to send an answer that is correctly received by A and A sends
>> an ack at mac layer. B adds cells as RX and expects A to open the same
>> cells as TX.
>>
>> 'Good!' one would say.
>>
>> Wrong! Node A has acknowledged at MAC layer the correct reception of the
>> answer by B but will process the 6P packet after that. If the timeout is
>> too short, that packet will be considered out of time. And the TX cells
>> will not be allocated. With some RX cells open on node B.
>>
>> One can think of a timeout to garbage collect on B. But I'm not sure this
>> would be very efficient, there's the probability of false positive.
>>
>> A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX
>> side after receiving the mac layer ack from A. A will open the TX side
>> after sending the mac layer ack, it the 6P response was in time. It will
>> send the 6P ack possibly in the newly created dedicated cell, so
>> decongesting the shared cell of 'minimal'. If B receives the 6P ack, it
>> will be sure that the RX side is open completely without possible
>> impairment with the node A schedule knowledge.
>>
>> Instead, if the 6P response was out of time, A will not send any 6P ack,
>> will not open the TX side. B will not receive any 6P ack within a timeout
>> (that can be the same length as that starting on the A side after the
>> reception of the mac layer ack to the request packet) and when that expires
>> will delete the RX cells that were 'half' opened.
>>
>> With this, it is not possible to get suspicious cells allocations on the
>> RX side. There's still the possibility that a TX side is open with the RX
>> side not open. But for that, 6P or SF will manage a relocation.
>>
>> Think about the 6P packet as the third part of a 3-way-handshake.
>>
>> Of course, it's obvious that I'm strongly in favor of a 6P ack
>> definition, more than having a big timeout.
>>
>> Does it make sense?
>>
>> Nicola
>>
>>
>> 2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl
>> >:
>>
>> Dear all,
>>Yesterday, we had a discussion about ticket #53
>> from the issue tracker, on the way to calculate the
>> SF0 timeout value.
>>There is current a proposal to calculate the timeout
>> on SF0 between the arrival of the MAC-layer ACK for the
>> request packet and the arrival of the response packet.
>> In order to achieve this calculation, the 6P protocol must
>> signal the arrival of the request ACK packet so as to start
>> the timer countdown.
>>Using this method, we avoid very long timeouts set
>> to the max value of the number of TXATTEMPTS and the
>> maximum backoff value.
>> Graphically:
>>
>> SF|REQUEST|   |timer-|RESPONSE|
>>   ^
>> 6P |REQUEST|  | |RESPONSE|
>> MAC LAYER   |REQUEST| |ACK||RESPONSE| |ACK|
>>
>> I would like to know if your thougthts about this idea.
>> Thank you.
>> Regards,
>>
>>  Diego
>>
>> --
>> DIEGO DUJOVNE
>> Profesor Asociado
>> Escuela de Informática y Telecomunicaciones
>> Facultad de Ingeniería - 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
>> <https://www.ietf.org/mailman/listinfo/6tisch>
>>
>>
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>


-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

[6tisch] SF Timeout calculation (Ticket #53)

[Prof. Diego Dujovne]

Dear all,
   Yesterday, we had a discussion about ticket #53
from the issue tracker, on the way to calculate the
SF0 timeout value.
   There is current a proposal to calculate the timeout
on SF0 between the arrival of the MAC-layer ACK for the
request packet and the arrival of the response packet.
In order to achieve this calculation, the 6P protocol must
signal the arrival of the request ACK packet so as to start
the timer countdown.
   Using this method, we avoid very long timeouts set
to the max value of the number of TXATTEMPTS and the
maximum backoff value.
Graphically:

SF|REQUEST|   |timer-|RESPONSE|
  ^
6P |REQUEST|  | |RESPONSE|
MAC LAYER   |REQUEST| |ACK||RESPONSE| |ACK|

I would like to know if your thougthts about this idea.
Thank you.
Regards,

Diego

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

[6tisch] Fwd: New Version Notification for draft-ietf-6tisch-6top-sf0-01.txt

[Prof. Diego Dujovne]

Dear all,
 I have submitted a new version of the SF0 draft
to fulfill the pending changes after the discussions on the
ML and interim calls.
Regards,

Diego

A new version of I-D, draft-ietf-6tisch-6top-sf0-01.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:   draft-ietf-6tisch-6top-sf0
Revision:   01
Title:  6TiSCH 6top Scheduling Function Zero (SF0)
Document date:  2016-07-08
Group:  6tisch
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-ietf-6tisch-6top-sf0-01.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-sf0/
Htmlized:   https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-sf0-01

Abstract:
   This document defines a 6top Scheduling Function called "Scheduling
   Function Zero" (SF0).  SF0 dynamically adapts the number of reserved
   cells between neighbor nodes, based on the currently allocated
   bandwidth and the neighbour nodes' requirements.  Neighbor nodes
   negotiate in a distributed neighbor-to-neighbor basis the cell(s) to
   be added/deleted.  SF0 uses the 6P signaling messages to add/delete
   cells in the schedule.  Some basic rules for deciding when to add/
   delete cells and for selecting the cells to be added/deleted within
   the schedule are also provided.





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.

The IETF Secretariat




-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - 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

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

[Prof. Diego Dujovne]

Qin,
  You are right. The metadata field is a good place
to use for specific details which are not available
on the errors. I agree.
Regards,

  Diego

2016-05-25 10:47 GMT-04:00 Qin Wang <qinwang6...@yahoo.com>:

> Hi Diego,
>
> I understand your concern and  your proposal to have two return codes
> corresponding to no enough resource and candidate cells in Lock status. But
> I think SF is better place to handle it. For example,  in Metadata of
> response message, 1-bit Flag can be used to distinguish (1) No Enough
> Resource and (2) Candidate Cells in Lock Status. Because SF analyze the ADD
> Request Message and prepare Response Message, it should not difficult for
> SF to provide the value of the 1-bit Flag.
>
> What do you think?
>
> Thanks
> Qin
>
>
> On Tuesday, May 24, 2016 11:29 AM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>
> Xavi, all:
>   Going back on what you proposed and the revised
> text, the ony difference I see between a specific error on concurrent
> transactions and the busy error, is the possibility to choose between
> different retry periods and the number of retries by the SF:
> If a child desperately needs new cells, and the only problem
> is concurrency, a short retry period and a high number of retries may
> be the reaction, while if the error is busy due to resource
> (=processor/storage)
> constraints, then the reaction would be a longer retry period, or even
> to give up the transaction.
>  However, for the sake of simplicity, keeping the busy error
> response does the job in a more generic way.
>  Regards,
>
> Diego
>
>
> 2016-05-24 10:18 GMT-04:00 Xavier Vilajosana <
> xvilajos...@eecs.berkeley.edu>:
>
> Looks good to me!
>
> ===
> A node MAY support concurrent 6P Transactions from different neighbors.
> In this case the cells involved in the ongoing 6P transaction MUST be
> locked until the transaction finishes. For example, in Figure 1, node C can
> have a different ongoing 6P Transaction with nodes B and E.
>
> In case a node does not have enough resources to handle concurrent 6P
> Transactions from different neighbors or if the cells requested are locked,
> it MUST reply to that second request with a 6P Response with return code
> IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a
> retry mechanism, as decided by the Scheduling Function.
> ===
>
> X
>
> 2016-05-24 13:39 GMT+02:00 Thomas Watteyne <thomas.watte...@inria.fr>:
>
> Lijo,
>
> Looks good to me. A tiny typo:
>
> ===
> A node MAY support concurrent 6P Transactions from different neighbors.
> In this case the cells involved in the ongoing 6P transaction MUST be
> locked until the transaction finishes. For example, in Figure 1, node C can
> have a different ongoing 6P Transaction with nodes B and E.
>
> In case a node does not have enough resources to handle concurrent 6P
> Transactions from different neighbors or if the cells requested are locked,
> it MUST reply to that second request with a 6P Response with return code
> IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a
> retry mechanism, as decided by the Scheduling Function.
> ===
>
> Any further comments/suggestions?
>
> Thomas
>
> On Tue, May 24, 2016 at 8:16 AM, Lijo Thomas <l...@cdac.in> wrote:
>
> Hi Thomas,
>
> I feel that we should group the RC_BUSY cases.
>
> My suggestion : >>>
>
> A node MAY support concurrent 6P Transactions from different neighbors.  In
> this case the cells involved in the ongoing 6P transaction MUST be locked
> until the transaction finishes. For example, in Figure 1, node C can have a
> different ongoing 6P Transaction with nodes B and E.
>
> In case a node does not have enough resources to handle concurrent 6P
> Transactions from different neighbors or if the cells requested are
> locked, it MUST reply to that second request with a 6P Response with return
> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement
> a retry as decided by the Scheduling Function
>
> >>>>>>>
>
> Does it make sense ..
>
> *Thanks & Regards,*
> *Lijo Thomas *
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 23 May 2016 18:03
> *To:* Lijo Thomas
> *Cc:* 6tisch@ietf.org; Prof. Diego Dujovne; Xavier Vilajosana
>
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
> All,
>
> We have reached a consensus, in summary:
> - a 6P transaction is not infinitely fast, we n

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

[Prof. Diego Dujovne]

Xavi, all:
  Going back on what you proposed and the revised
text, the ony difference I see between a specific error on concurrent
transactions and the busy error, is the possibility to choose between
different retry periods and the number of retries by the SF:
If a child desperately needs new cells, and the only problem
is concurrency, a short retry period and a high number of retries may
be the reaction, while if the error is busy due to resource
(=processor/storage)
constraints, then the reaction would be a longer retry period, or even
to give up the transaction.
 However, for the sake of simplicity, keeping the busy error
response does the job in a more generic way.
 Regards,

Diego


2016-05-24 10:18 GMT-04:00 Xavier Vilajosana <xvilajos...@eecs.berkeley.edu>
:

> Looks good to me!
>
> ===
> A node MAY support concurrent 6P Transactions from different neighbors.
> In this case the cells involved in the ongoing 6P transaction MUST be
> locked until the transaction finishes. For example, in Figure 1, node C can
> have a different ongoing 6P Transaction with nodes B and E.
>
> In case a node does not have enough resources to handle concurrent 6P
> Transactions from different neighbors or if the cells requested are locked,
> it MUST reply to that second request with a 6P Response with return code
> IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a
> retry mechanism, as decided by the Scheduling Function.
> ===
>
> X
>
> 2016-05-24 13:39 GMT+02:00 Thomas Watteyne <thomas.watte...@inria.fr>:
>
>> Lijo,
>>
>> Looks good to me. A tiny typo:
>>
>> ===
>> A node MAY support concurrent 6P Transactions from different neighbors.
>> In this case the cells involved in the ongoing 6P transaction MUST be
>> locked until the transaction finishes. For example, in Figure 1, node C can
>> have a different ongoing 6P Transaction with nodes B and E.
>>
>> In case a node does not have enough resources to handle concurrent 6P
>> Transactions from different neighbors or if the cells requested are locked,
>> it MUST reply to that second request with a 6P Response with return code
>> IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement a
>> retry mechanism, as decided by the Scheduling Function.
>> ===
>>
>> Any further comments/suggestions?
>>
>> Thomas
>>
>> On Tue, May 24, 2016 at 8:16 AM, Lijo Thomas <l...@cdac.in> wrote:
>>
>>> Hi Thomas,
>>>
>>>
>>>
>>> I feel that we should group the RC_BUSY cases.
>>>
>>>
>>>
>>> My suggestion : >>>
>>>
>>>
>>>
>>> A node MAY support concurrent 6P Transactions from different neighbors.
>>> In this case the cells involved in the ongoing 6P transaction MUST be
>>> locked until the transaction finishes. For example, in Figure 1, node C can
>>> have a different ongoing 6P Transaction with nodes B and E.
>>>
>>>
>>>
>>> In case a node does not have enough resources to handle concurrent 6P
>>> Transactions from different neighbors or if the cells requested are
>>> locked, it MUST reply to that second request with a 6P Response with return
>>> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement
>>> a retry as decided by the Scheduling Function
>>>
>>>
>>>
>>> >>>>>>>
>>>
>>>
>>>
>>> Does it make sense ..
>>>
>>>
>>>
>>> *Thanks & Regards,*
>>>
>>> *Lijo Thomas *
>>>
>>>
>>>
>>>
>>>
>>> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Thomas
>>> Watteyne
>>> *Sent:* 23 May 2016 18:03
>>> *To:* Lijo Thomas
>>> *Cc:* 6tisch@ietf.org; Prof. Diego Dujovne; Xavier Vilajosana
>>>
>>> *Subject:* Re: [6tisch] New error type for concurrent transactions on
>>> 6top protocol draft
>>>
>>>
>>>
>>> All,
>>>
>>>
>>>
>>> We have reached a consensus, in summary:
>>>
>>> - a 6P transaction is not infinitely fast, we need to guarantee
>>> atomicity of the cell reservation process
>>>
>>> - In case of concurrent transactions involving the same cells on a
>>> particular node, that node need to be able to "lock" access to those cells
>>> during a particular 6P transaction.
>>>
>>> - in case node A initiates a 6P 

Re: [6tisch] My adoption-time review of SFO

[Prof. Diego Dujovne]

Pascal, Anand:
What I would propose is SF1 for this purpose.
Regards,

  Diego

2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> I like this view, Anand.
>
>
>
> Can we achieve that without getting complex?
>
>
>
> Pascal
>
>
>
> *From:* S.V.R.Anand [mailto:an...@ece.iisc.ernet.in]
> *Sent:* jeudi 19 mai 2016 08:17
> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com>; Prof. Diego Dujovne
> <diego.dujo...@mail.udp.cl>
> *Cc:* 6tisch@ietf.org; draft-dujovne-6tisch-6top-...@tools.ietf.org
>
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Hi Pascal,
>
> I agree with your view. We certainly seem to require a service sub-layer
> that
> provides link layer abstraction by offering ways of obtaining links with
> desired properties that the user might want.
>
> For instance, the user might want to ask this sub-layer for a provision of
> desired number of links being made available at certain time intervals. The
> time intervals can be specified, say, in terms of delay bounds. One can use
> this link layer feature for several possible use cases, including (i)
> meeting
> delay requirements at coarse or fine grain level (ii) power savings (iii)
> improving data aggregation and so forth. The mapping of this requirement to
> precise cell management functionality will then be handled by the lower
> layer
> 6P and SF mechanisms.
>
> I am not sure how we can fit the above sub-layer in the current scheme of
> things. Let me know if I am making sense.
>
> Anand
>
> On Friday 13 May 2016 09:20 PM, Pascal Thubert (pthubert) wrote:
>
> Hell Diego,
>
>
>
> My point is that a SF should operate on a number of units of
> transmissions,  which happen to be cells in our case.
>
> SF should indicate to 6top that there is a need to change for more of less
> of these units.
>
> But the fact that one of these units is mapped to a particular slot offset
> / channel offset should not be its business. I see it as a layer violation…
>
> What if for instance the SF is in the root? Should it really manage down
> to the cell?
>
>
>
> Pascal
>
>
>
> *From:* Prof. Diego Dujovne [mailto:diego.dujo...@mail.udp.cl
> <diego.dujo...@mail.udp.cl>]
> *Sent:* vendredi 13 mai 2016 17:08
> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com> <pthub...@cisco.com>
> *Cc:* draft-dujovne-6tisch-6top-...@tools.ietf.org; 6tisch@ietf.org
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Dear all,
>
> During today's webex call, I presented a slide where
>
> the comments below were going to be addressed on the next
>
> version of the draft.
>
> However, I raised the point about:
>
> Ø  4.  Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> -> This section is recommended by the 6top-protocol draft, and AFAIK it
> defines which cells are offered and which are selected for allocation.
>
>
>
>
>
> Ø  7.  Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
> -> This section is also recommended by the 6top-protocol draft, and it
> should include any type of pre-configuration and expected initial state on
> the SF.
>
> -> From the comment from Pascal on today's webex: "What if a node has a
> big storage and it can keep all configuration after a crash?" The SF can
>
> use that info to reconstruct all the configuration and recover instead of
> issuing a clear command. However, there must be a timeout period for
> recover;
> if this timeout expires, then all the cells from the crashed node shall be
> released.
>
>
>
>
> Rules for CellList and Node Behaviour at boot are
> recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
> protocol-00
>
>
>
> 2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:
>
> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø   This document addresses the requirements for a scheduling function
>
>listed in [I-D.wang-6tisch-6top-sublayer 
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>],
>  Section 4.2, and fo

Re: [6tisch] New error type for concurrent transactions on 6top protocol draft

[Prof. Diego Dujovne]

Lijo, Xavi:
  I would like to point out that the idea of having
another type of error is to differentiate the lack of processing/storage
power to complete a new transaction from the concurrent transaction
condition, giving a better clue of what is going on to the requesting
node and to enable to calculate a different retry interval for each case.
A transaction should not take more than 3 exchanges, so this should
be the retry period for the concurrent case.

To be brief:

RC_BUSY: "I am overloaded"

CT_ERROR: "I have very few available cells remaining, try on the next cycle"

Regards,

   Diego Dujovne


2016-05-18 9:23 GMT-04:00 Lijo Thomas <l...@cdac.in>:

> Hi Xavi,
>
>
>
> Thanks for the detailed one.
>
>
>
> Yes I am of the opinion of using the same RC_BUSY itself, but at the same
> time we should modify the text as indicated by you, so that locking
> mechanisms are clearly mentioned. Also it  states the options for retry in
> case of concurrent transactions.
>
>
>
> With the keyword RC_BUSY, one expects that the node is indulge in a 6P
> transaction currently and can go for a retry.  But in the draft it says
> RC_BUSY with no resources available. It is bit confusing.
>
>
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 18 May 2016 17:52
> *To:* Lijo Thomas
> *Cc:* 6tisch@ietf.org; Prof. Diego Dujovne
>
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hi,
>
>
>
> the current 6top draft v00 says:
>
>
>
>A node MAY support concurrent 6P Transactions from different
>
>neighbors.  In this case, in Figure 1, node C can have a different
>
>ongoing 6P Transaction with nodes B and E.  In case a node does not
>
>have enough resources to handle concurrent 6P Transactions from
>
>different neighbors, when it receives a 6P Request from a neighbor
>
>while already handling a different request from a different neighbor,
>
>it MUST reply to that second request with a 6P Response with return
>
>code IANA_6TOP_RC_BUSY.
>
>
>
> This indicates that if there aren't enough resources to handle the
> transaction it responds with the RC_BUSY.
>
>
>
> If we want to further clarify the case of locking the cells in the
> candidate list we can add a text like
>
>
>
> "The cells in a candidate list are locked in the schedule until the
> transaction has finished or the cells definitely allocated. Upon completion
> of the transaction the non-allocated cells are released and can be used for
> other transactions. During a concurrent transaction, the cells advertised
> in a cell list MUST not overlap to cells advertised to other neighbors
> concurrently. In case that the a node has not enough resources to handle
> the concurrent transactions as some cells are locked, the code
> IANA_6TOP_RC_BUSY MUST be returned to one or more of the requesting nodes
> enabling them to retry."
>
>
>
> In this case we use RC_BUSY again, but as proposed by Diego we may decide
> to use another error code to differentiate this case. IMHO RC_BUSY is
> enough though.
>
>
>
> what do you think?
>
> X
>
>
>
>
>
>
>
>
>
>
>
> 2016-05-18 12:39 GMT+02:00 Lijo Thomas <l...@cdac.in>:
>
> Hi Xavi/Diego,
>
>
>
> Can’t we use the RC_BUSY rather than CT_ERROR  for the case of Concurrent
> transactions.
>
>
>
> The scheduling function may decide for a retry when a RC_BUSY is received
> , so how we can differentiate the usage of CT_ERROR and RC_BUSY.
>
>
>
> Is it the backoff time that accounts.
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 14 May 2016 18:34
> *To:* Prof. Diego Dujovne
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hi Diego,
>
>
>
> What I propose is to lock in the schedule the cells that are being sent in
> the candidate list, this means that 1) if there are other cells available
> in the schedule, the node may still be able to propose another
> (non-overlapping) candidate list. thus still supporting concurrency and 2)
> only in the case that the remaining free cells are those in the candidate
> list, the error code you propose will be used to enable a retry.
>
>
>
> hope this is clear now!
>
> X
>
>

Re: [6tisch] My adoption-time review of SFO

[Prof. Diego Dujovne]

Pascal,
   The question here is who is doing cell accounting.
AFAIK, 6P had to guarantee transactions and SF had to
do the accounting by directly managing the cells by their
identification. This is explained (at least) on the example
from Figure 4, section 4.1.1, step 1, on page 6 of the
6top-protocol draft:

 1.  The SF running on node A selects 3 candidate cells.

So the SF decides which are the candidates for the CellList.
On the same example, on step 3:

3.  The SF running on node B selects 2 of the 3 cells in the CellList
   of the 6P ADD Request.  Node B sends back a 6P Response to node
   A, indicating the cells it selected.

So the SF on the other end selects which of the candidates should be chosen.

This process is better explained on section 4.3.6: Adding cells.

Now, suppose the SF does the accounting only
on the amount of cells per bundle (assuming a bundle is
a one-way link against a neighbour) and 6P manages
the cell IDs:
The conflict here comes from the relocation
algorithm, which keeps statistics on individual (and identified)
cells to relocate them in case the PDR drops below a certain
threshold.
According to the 6top-protocol draft, this is a task which
corresponds to the SF too.

Furthermore, SFs are part of the 6top protocol and not another
layer, so there is theoretically no layer violation there.

What do you think?

Regards,

  Diego




2016-05-13 12:50 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> Hell Diego,
>
>
>
> My point is that a SF should operate on a number of units of
> transmissions,  which happen to be cells in our case.
>
> SF should indicate to 6top that there is a need to change for more of less
> of these units.
>
> But the fact that one of these units is mapped to a particular slot offset
> / channel offset should not be its business. I see it as a layer violation…
>
> What if for instance the SF is in the root? Should it really manage down
> to the cell?
>
>
>
> Pascal
>
>
>
> *From:* Prof. Diego Dujovne [mailto:diego.dujo...@mail.udp.cl]
> *Sent:* vendredi 13 mai 2016 17:08
> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com>
> *Cc:* draft-dujovne-6tisch-6top-...@tools.ietf.org; 6tisch@ietf.org
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Dear all,
>
> During today's webex call, I presented a slide where
>
> the comments below were going to be addressed on the next
>
> version of the draft.
>
> However, I raised the point about:
>
> Ø  4.  Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> -> This section is recommended by the 6top-protocol draft, and AFAIK it
> defines which cells are offered and which are selected for allocation.
>
>
>
>
>
> Ø  7.  Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
> -> This section is also recommended by the 6top-protocol draft, and it
> should include any type of pre-configuration and expected initial state on
> the SF.
>
> -> From the comment from Pascal on today's webex: "What if a node has a
> big storage and it can keep all configuration after a crash?" The SF can
>
> use that info to reconstruct all the configuration and recover instead of
> issuing a clear command. However, there must be a timeout period for
> recover;
> if this timeout expires, then all the cells from the crashed node shall be
> released.
>
>
>
>
> Rules for CellList and Node Behaviour at boot are
> recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
> protocol-00
>
>
>
> 2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:
>
> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø   This document addresses the requirements for a scheduling function
>
>listed in [I-D.wang-6tisch-6top-sublayer 
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>],
>  Section 4.2, and follows
>
>the recommended outline from Section 4.3 
> <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.
>
>
>
> I would expect that this doc is the reference for SF and is the one that
> requests the creation of the SF registry by IANA (text to be added in the
> IANA section).
>

Re: [6tisch] My adoption-time review of SFO

[Prof. Diego Dujovne]

Dear all,
During today's webex call, I presented a slide where
the comments below were going to be addressed on the next
version of the draft.
However, I raised the point about:

Ø  4.  Rules for CellList



Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
think, in this document.



-> This section is recommended by the 6top-protocol draft, and AFAIK it
defines which cells are offered and which are selected for allocation.





Ø  7.  Node Behavior at Boot



Again this is describing 6P not SF0 behavior. Note that the clear should be
done at link up in case

-> This section is also recommended by the 6top-protocol draft, and it
should include any type of pre-configuration and expected initial state on
the SF.
-> From the comment from Pascal on today's webex: "What if a node has a big
storage and it can keep all configuration after a crash?" The SF can
use that info to reconstruct all the configuration and recover instead of
issuing a clear command. However, there must be a timeout period for
recover;
if this timeout expires, then all the cells from the crashed node shall be
released.


Rules for CellList and Node Behaviour at boot are
recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
protocol-00

2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) :

> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø   This document addresses the requirements for a scheduling function
>
>listed in [I-D.wang-6tisch-6top-sublayer 
> ],
>  Section 4.2, and follows
>
>the recommended outline from Section 4.3 
> .
>
>
>
> I would expect that this doc is the reference for SF and is the one that
> requests the creation of the SF registry by IANA (text to be added in the
> IANA section).
>
> This reference to sublayer should go away since we are not promoting the
> draft at the moment – or should we be doing so?
>
>
>
>
>
>
>
> Ø
>
> Ø  3.1.  SF0 Triggering Events
>
> Ø
>
> Ø We RECOMMEND SF0 to be triggered at least by the following events:
>
>
>
> The term ‘We’ is probably inappropriate. Better formulate this like “ It
> is RECOMMENDED that…”
>
>
>
> Also shouldn’t there be an event when:
>
>
>
> -Connectivity to the neighbor is lost. A L3 Link down event
> should free up resources. The question for 6P is how both sides agree at
> the same time that the link is down.
>
> -A threshold of unused time slots is reached so they should be
> freed
>
>
>
>
>
> Ø   6.  If the RAB is less than the Minimum Remaining Bandwidth (MRB),
>
>Add MRB to the NOB: NOB=NOB+MRB
>
>
>
> Shouldn’t this be
>
>NOB=MRB
>
>
>
>
>
>
>
> Ø  4.  Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> Ø  7.  Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
>
>
>
>
>
>
> Ø  11.  Examples
>
> Ø
>
> Ø TODO
>
> Ø
>
> Ø  12.  Implementation Status
>
>
>
> These sections probably belong to annexes
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
>
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] New error type for concurrent transactions on 6top protocol draft

[Prof. Diego Dujovne]

Dear all,
   I proposed today to add a new type of error
for CellList proposal during the transaction. The idea
follows the solution proposed today at the Webex call
by Xavi to define a lock when two concurrent cell
requests arrive to the node.
For example, if node B requests a cell from A,
and during this transaction node C requests a new
cell from A, send a  Concurrent Transaction "CT_ERROR"
so C knows there may still be resources available and
retry later instead of giving up.

Do you think this should solve the problem?

Regards,

  Diego



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Remote Mentoring: Internet Draft Review Team: 6tisch: Portugese / English

[Prof. Diego Dujovne]

Nalini,
 I can help with this draft, you can send them
my email address to start the discussion. I'm not in
Brazil (I'm in Chile), but we may be able to arrange
a videoconf if necessary, given that we do not have
a huge time difference.
 Regards,

Diego Dujovne

2016-04-28 11:46 GMT-03:00 :

> Roll / 6tisch / 6lo People,
>
> We are forming teams of new-ish people to start working together to review
> drafts and pose comments on the list.
>
> The second team in this set of WGs to be formed is comprised of 2 people
> from Brazil.  They wish to study drafts in the 6lo/ 6tisch/ roll WGs.  The
> discussions will be conducted in Portugese or English.
>
> The first draft they are reading is:
>
>
> draft-ietf-6tisch-minimal-15.
>
> They are to read the draft and have 5 questions ready for discussion.
> (They have started.) The questions can be either things they do not
> understand, things they think need to be clearer in the draft or need to be
> fixed.
>
> I will take either of the following, please let me know.
>
> 1.  If you will be able to help them in Brazil time zone in a webinar in
> Portugese / English.  Commitment is one hour per month live and some email
> contact.
>
> 2.  If you will be able to help them via email support only.
>
> Please help, if you can.
>
> BTW, the Spanish DNSOP team has a mentor & is started.
>
> Thank you all very much.
>
>
> Nalini Elkins
> IETF Mentoring Team
> Inside Products, Inc.
> www.insidethestack.com
> (831) 659-8360
>
> ___
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Prof. Diego Dujovne]

I agree with Xavi and Pascal on the use of the token:

- To enable future concurrent requests
- To enable retries.

However, in another thread Tengfei proposed that the SF should
take care of retries and 6P only respond to SFs as "OK" or "FAIL"
transaction.

Regards,

 Diego

2016-03-09 14:27 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> Never seen a stupid question from you, Qin : )
>
>
>
> I agree with you actually.
>
>
>
> By “As it goes, it also enables to avoid the serialization of requests
> but I agree that is a non goal today.” I meant that the child will
> probably serialize hos requests, iow wait for one completion before it asks
> 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 mars 2016 16:48
> *To:* Pascal Thubert (pthubert) <pthub...@cisco.com>
> *Cc:* Tero Kivinen <kivi...@iki.fi>; 6tisch@ietf.org; Prof. Diego Dujovne
> <diego.dujo...@mail.udp.cl>; Tengfei Chang <tengfei.ch...@gmail.com>
> *Subject:* Re: [6tisch] 6P and Sf0 issue: Token to identify transactions
> in 6P
>
>
>
> Pascal,
>
>
>
> I can see your point. Token is useful for Parent to distinguish Retry from
> new Request by the Child.
>
>
>
> But, I have a stupid question: is it reasonable to allow the Child to ask
> more cells before it gets Response to what it already asked?
>
>
>
> Thanks
>
> Qin
>
>
>
> On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>
>
> Hello Qin:
>
>
>
> Token 1 needs to be the same as token 2 when it is a retry. That's the
> whole point.
>
>
>
> In your second case, say this is a child asking for a cell:
>
>
>
> - If this is a time out because the response from the parent was lost, the
> parent should respond with the same cell as in the lost message.
>
>
>
> - But if the child got the response and still needs more bandwidth, then
> the parent needs to allocate a second cell.
>
>
>
> How does the parent know?
>
>
>
> The main point of the sequence number is to be able to correlate the
> retry.
>
>
>
> As it goes, it also enables to avoid the serialization of requests but I
> agree that is a non goal today.
>
> Regards,
>
>
>
> Pascal
>
>
> Le 8 mars 2016 à 22:10, Qin Wang <qinwang6...@yahoo.com> a écrit :
>
> Hi all,
>
>
>
> I'm not convinced that token is necessary yet. From the discussion in the
> last WG meeting, we have agreed that the Token is used in the 6P message
> exchange between neighbors. Based on the agreement, let's consider the two
> following scenarios.
>
>
>
> (1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response
> from nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB,
> and receive Response(token=2) from nodeB.
>
>
>
> (2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB
> before Timeout. Then nodeA send ADD_Request to nodeB again, and receive
> Response from nodeB.
>
>
>
> The question is if it is possible for nodeA to receive Response(token=1)
> from nodeB later in (1). Since nodeA will send the second ADD_Request after
> Timeout, I don't think it could happen. If I'm correct, I think the two
> sequences function similarly. Thus, I wonder if it is necessary to have the
> Token
>
>
>
> What do you think?
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
> On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>
>
> Oh yes, Tero,
>
> we agree on the bottom line and on your points.
>
> Cheers,
>
> Pascal
>
>
> > -Original Message-
> > From: Tero Kivinen [mailto:kivi...@iki.fi]
> > Sent: mardi 8 mars 2016 15:50
> > To: Pascal Thubert (pthubert) <pthub...@cisco.com>
> > Cc: Tengfei Chang <tengfei.ch...@gmail.com>; 6tisch@ietf.org; Prof.
> Diego
> > Dujovne <diego.dujo...@mail.udp.cl>
> > Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions
> in 6P
> >
> > Pascal Thubert (pthubert) writes:
> > > But this is another discussion entirely. It is about the transaction
> > > that associates new timeslots to a bundle and why we need a
> > > correlator, or transaction ID. I was explaining that if the parent
> > > wait for the ack to allocate a slot that was negotiated, and there is
> > > no flow

Re: [6tisch] SF0 - Cell reclamation by RPL parent

[Prof. Diego Dujovne]

Anand,
   Let me comment inline below.
Regards,

  Diego

2016-03-07 7:36 GMT-03:00 S.V.R.Anand :

> Hi Diego and others,
>
> Since we are discussing about the message transactions in SF0, this mail
> is with
> respect to the RPL parent, the cell donor.
>
> There are situations where the RPL parent might want to apply a cell
> reclamation
> and, depending on the context, a reallocation policy dynamically. This
> results in one or more cells that
> have been given to its children are reclaimed by the RPL parent due to
> various
> reasons as below.
>
> - The child node is out of the network, or child and parent cannot reach
> each other,
>   after the 6P add cell transaction is complete, thereby delete cell
> operation is not
>   being transacted. Cell reclamation helps in "cell garbage" collection.
>
>
I was thinking on the neighbour list management. If a neighbour is deleted,
all the cells
belonging to the link with that neighbour shall be deleted too. Is there a
specification on
which entity maintains the neighbour list?



> - As add cell requests arrive asynchronously from its children, an RPL
>   parent implementing certain fairness objective might re-appropriate the
> cells
>   that have already alloted its children, especially during a resource
> crunch.
>

Bandwidth requests are managed by SFs; an SF running on a Parent can
trigger
a deletion event as needed. The starving applications on the top layer
should
react accordingly. The problem here is that the SFs react given certain
statistics
and events, but there is no current connection with other modules which may
reclaim cells.
This raises another point: The cell list should be kept and maintained at
the
6P level, or at the SF? Do we allow for multiple SFs on the same node?
Do we allow only different SFs in a per-neighbour basis (so each link is
managed
by only one SF)?


>
> - Referring to the following text in 4.2.5 of the 6tisch architecture
> document,
>
>   "...Note that a PCE is expected to have precedence in the allocation, so
> that  an RPL parent
> would only be able to obtain portions that are not in-use by the PCE."
>
>   It may be that, an RPL parent might have to relinquish its own cells if
>needed by PCE any time. In such a scenario, the RPL parent may be
> forced to
>   reclaim the cells given to its children.
>
> While the first case is relatively less complex, the latter two cases are
> problematic as these cases can lead to (i) potential race conditions, say
> between PCE and SF0 operations, and (ii) a cascading effect across several
> RPL
> parents down the DODAG. Currently, there is no mechanism defined to address
> this problem.
>
> I suppose the above text extends beyond SF0.
>

As far as I know, we are using chunks allocated to the RPL Parents by the
PCE to
schedule cells requested by SFs. The main assumption here is that the PCE
will
distribute chunks among the RPL Parents and not reclaim them back. However,
it is only an assumption. As I noticed above, cell list maintenance should
be transferred
to 6P if another module can add/delete cells concurrently.



>
> In light of the above use cases and the associated problems, do you think
> it is a
> good idea to include an appropriate message in SF0 for reclaiming the
> cells by
> the RPL parent ? or are we inviting new set of problems by doing so ?
>
>
My question here is: Who is going to send this message? RPL? PCE through
CoAP?
Can we leave this to Chunk negotiation, which is currently out of scope of
this draft?



> Will be happy to receive your inputs.
>
> Anand
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

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

[Prof. Diego Dujovne]

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

  Diego


2016-03-04 7:55 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> Hello Diego:
>
>
>
> One suggestion would be that when a node attempts to join, the parent
> immediately grants a set of cells for the join process from a limited pool
> (to avoid DDOS). These cells are to be released at the end of the join and
> are there to boost the bandwidth for that critical phase.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* jeudi 3 mars 2016 17:12
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] 6P and Sf0 issue: 6top protocol behaviour at boot
>
>
>
> Dear all,
>
> Although it was discussed, there is no specification
>
> on the 6top behaviour at boot. The discussion point here is if the
>
> 6top messages shall be transmitted on minimal cells until
>
> the slotframe 1 (SFR1) has been populated enough to support
>
> the transactions.
>
>   - The use of minimal is optional. In case minimal is used,
>
> the decision on when to switch is out of scope?
>
>   - In case minimal is not used, shall we specify another
>
> mechanism to enable 6top to transmit messages?
>
> Thanks!
>
> Regards,
>
>  Diego Dujovne
>
>
> --
>
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: Statistics for SFs and Relocation

[Prof. Diego Dujovne]

Pascal,
   Agreed. Then we should add a
new SHOULD item at the end of the

"4.2.  Requirements for an SF"

section on the 6TiSCH Operation Sublayer (6top) draft
to include statistics.

Regards,

  Diego

2016-03-04 8:21 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> I’d support that, Diego
>
>
>
> If the visible operation of the device depends on it and that influences
> the interoperation, it is good to document a base way of doing things.
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* jeudi 3 mars 2016 20:26
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] 6P and Sf0 issue: Statistics for SFs and Relocation
>
>
>
> Dear all,
>
>Given the requirements to build SFs exposed
>
> in the 6tisch sublayer draft, there is no specification
>
> on how to obtain the statistics and calculate and build
> the metrics used to decide when to add/delete/relocate
>
> cells. The draft asks only for the set of rules.
>
>   SF0 defines an algorithm using specific values
>
> as thresholds and rules for adding/removing cells and
> uses PDR and a simple decision rule to decide which
> cell to relocate.  However, this may not be the case
> for the other (possibly more complex) SFs, where
> metrics based on statistics could be included.
>
>Shall we include a section on the description
>
> of how to calculate the specific statistics used on each
>
> SF, or just leave this out of scope to the implementer?
>
> My point of view is that statistics should be specified
>
> in order to be able to interoperate between different
>
> implementations of the same SF.
>
> What do you think?
>
> Thank you,
>
>   Diego Dujovne
>
>
>
>
> --
>
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>



-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P and Sf0 issue: IANA IDs

[Prof. Diego Dujovne]

Pascal,
  Acknowledge. Let's discuss tomorrow
on choice 2, as you mentioned.
Thank you.
Regards,

   Diego



2016-03-04 8:06 GMT-03:00 Pascal Thubert (pthubert) <pthub...@cisco.com>:

> Hello Diego:
>
>
>
> You need a IANA section where you detail which registries you create and
> which you add to.
>
> Then you need to enumerate the entries that you need, as you do below.
>
>
>
> You may suggest values to help interop till you make RFC, but the IANA
> will have the final word and implementations may need to be updated.
>
>
>
> In this particular case, we have discussed where the IE space comes from
> but I have not seen a final conclusion on that. In particular (quoting
> Thomas in the attached mail) we have on the table “*Choice 2, the ID is
> allocated to IETF via IANA. There is a defined process to obtain a Payload
> Group ID (http://www.ieee802.org/15/ANA.html
> <http://www.ieee802.org/15/ANA.html>), it basically starts with a formal
> request from an IANA officer.  There are only 8 addresses left before going
> onto extended addresses, so we really need to make sure that each of the 8
> addresses will be properly used.*”
>
>
>
> If we are sure we’ll need the ID regardless of this particular draft, then
> we may issue a short draft to request it from IANA. As Thomas indicated, we
> need a very solid justification. It would be good to discuss this at the
> interim next Friday to prepare for any request / question to the 6TiSHC SG
> or WG15 who are meeting in Macao the week after.
>
>
>
> CC’ing Brian in case I missed something?
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Prof.
> Diego Dujovne
> *Sent:* jeudi 3 mars 2016 17:54
> *To:* 6tisch@ietf.org
> *Subject:* [6tisch] 6P and Sf0 issue: IANA IDs
>
>
>
> Dear 6tisch chairs,
>
> I would like to know which are the steps
>
> to request IDs to IANA, since we need at least the following
>
> ones:
>
>
> IANA_IETF_IE_GROUP_ID
> IANA_6TOP_SUBIE_ID
> IANA_6TOP_6P_VERSION
> 6P command identifiers
> 6P Return Codes
> IANA_SFID_SF0
>
> Are they independent of the draft/RFC status? Do we have
>
> to wait until the drafts get into the standardization track?
>
>
>
> Regards,
>
>Diego Dujovne
>
>
>
>
>
> --
>
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>
>
> -- Message transféré --
> From: Thomas Watteyne <thomas.watte...@inria.fr>
> To: "pat.kin...@kinneyconsultingllc.com" <
> pat.kin...@kinneyconsultingllc.com>
> Cc: "Pascal Thubert (pthubert)" <pthub...@cisco.com>
> Date: Mon, 22 Feb 2016 15:05:42 +
> Subject: Re: [6tisch] IEEE 802.15 6T Interest Group responses to IETF
> 6tisch requests
> Pat,
> I suggest we discuss this at the meeting this Friday. I will start a
> thread on the ML. OK for me to copy-paste the following:
>
> *The best way to determine which of these alternatives to use is to define
> what is required of the IE and how is it used:*
>
> *Choice 1, the vendor specific ID is already defined in the standard and
> needs no further action from 6tisch.  It uses the Payload IE Group ID = 0x2
> followed by 3 octets of the Vendor’s OUI.  Two options here are to request
> an OUI from the IEEE RAC, or request a company ID from the IEEE RAC.
> Regardless, the vendor specific ID adds 3 octets to the IE, which is not a
> problem if the IE is seldom used, such as configuring the network.*
>
> *Choice 2, the ID is allocated to IETF via IANA. There is a defined
> process to obtain a Payload Group ID (http://www.ieee802.org/15/ANA.html
> <http://www.ieee802.org/15/ANA.html>), it basically starts with a formal
> request from an IANA officer.  There are only 8 addresses left before going
> onto extended addresses, so we really need to make sure that each of the 8
> addresses will be properly used.*
>
> *Choice 3, the ESDU IE is meant to send a message to another node, it has
> no inherent formatting, the other node must already understand how to use
> the information.*
>
> *If the 6tisch group chooses choice 2, we’ll need a request from IANA.*
>
> Thomas
>
> On Fri, Jan 29, 2016 at 1:48 AM, pat.kin...@kinneyconsultingllc.com <
> pat.kin...@kinneyconsultingllc.com> wrote:
>
>> Thanks for your reply Thomas;
>>
>> Firstly, as far as the formatting goes, it would be good for the group to
>> entertain any ot

Re: [6tisch] 6P and Sf0 issue: Examples of error handling

[Prof. Diego Dujovne]

Tengfei,
  So, taking into account your proposal, the SF should configure
the Retry
Limit and handle the retries at SF layer, leaving 6P to deal only with
transactions:
either they are complete and successful or failed and rolled back (even in a
timeout case).
  Retries shall not be 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>:

> Hello Diego,
>
> *For IANA_6TOP_CMD_ROLLBACK command: *
>
> I think I understand what you are trying to solve. But using 
> IANA_6TOP_CMD_ROLLBACK
> has another issue: how to decide when to send the command. I think this is
> the same question for setting the value of 6P_TIMEOUT.
> Also if a transaction timeout because of bad link quality or lost
> connection, sending another packet is not a good idea.
>
> *For Retry handling:*
>
> First, I think whether retry or not is a decision made by scheduling
> function. For 6P, it just forwards this message to upper layer (such as SF0)
>
> If retries are required, I think it makes sense that retrying within a
> transaction.
>
> What do you think?
>
> Tengfei
>
> On Thu, Mar 3, 2016 at 9:41 PM, Prof. Diego Dujovne <
> diego.dujo...@mail.udp.cl> wrote:
>
>> Dear all,
>>One of the sections I would like to add to
>> the SF0 draft is the examples of error handling.
>>
>> One example could be Timeout handling:
>> When a transaction times out, either a packet is lost,
>> the destination node lost connectivity or it is too busy
>> to answer on time.
>> Consequence: The transaction, in any stage, should
>> be rolled back by both ends.
>> Here, both nodes are expected to Timeout.
>> Section 3.6.2 of the sublayer draft "Aborting a
>> 6P transaction", cannot be used, since in this case
>> there is no response.
>> I propose to issue a rollback command such as
>> "IANA_6TOP_CMD_ROLLBACK" to the destination
>> node using the same token from the original transaction,
>> and do not wait for an answer.
>> This enables the source node to try a new transaction
>> before the destination node times out, thus reducing
>> delay.
>>
>> Would you agree in adding this command to reduce
>> delay?
>>
>> Another issue should be Retry handling, in case of
>> timeout.
>> Do we allow retries within a transaction?
>> If we allow retries, the maximum number of retries before
>> considering a transaction failed should be configured on
>> the SF.
>>
>> Thank you.
>> Regards,
>>
>> Diego Dujovne
>>
>>
>> --
>> DIEGO DUJOVNE
>> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
>> Facultad de Ingeniería UDP
>> www.ingenieria.udp.cl
>> (56 2) 676 8125
>>
>> ___
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6P and Sf0 issue: Piggybacking data packet with IE confirmation

[Prof. Diego Dujovne]

Dear all,
Given that there is parent preference in cell
selection, a child-initiated transaction triggers a three-step
exchange:
1- Child sends request to Parent with whitelist/blacklist of slotoffsets
2- Parent selects cells
3- Child acknowledges and finishes the transaction

The main idea is to enable an optional Piggybacking of the IE on a
data packet to reduce the number of transmitted packets, but there
are latency concerns when the (data) traffic is low.

Is it worth to enable this option given the added complexity?

Regards,

Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Prof. Diego Dujovne]

Dear all,
In order to continue the discussion we left
unfinished at the Interim meeting in March 26th, I
will open a number of threads to take action on several
pending issues for the drafts:

draft-wang-6tisch-6top-sublayer-04 (which will be renamed to 6top-protocol)
draft-dujovne-6tisch-6top-sf0-00

- Regarding the use of a Token to identify transactions on
the 6top protocol, there was a proposal on the call to add
an 8-bit field to the packet header.

Do you agree with this solution?

Regards,

  Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Agenda for January 8th, 2016 interim call, 6TiSCH WG

[Prof. Diego Dujovne]

Thomas,
 Yeap, just re-checking them now.
Regards,

 Diego

2016-01-08 11:00 GMT-03:00 Thomas Watteyne :

> reminder, 6TiSCH interim meeting in 1 hour
>
> On Tue, Jan 5, 2016 at 5:48 PM, Pascal Thubert (pthubert) <
> pthub...@cisco.com> wrote:
>
>> Dear all: Please find below a tentative agenda for the next interim
>> call, including connection through webex, voice and etherpad. Connection
>> details
>>
>>- Date: 7-8AM Pacific:
>>
>> http://www.worldtimebuddy.com/?qm=1=100,12,5392171,1850147=100=2016-01-08=15-16
>>- Webex link:
>>
>> https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a
>>- Meeting number: 203 137 703
>>- Meeting password: sixtus
>>- Audio connection:
>>   - +1-866-432-9903 Call-in toll-free number (US/Canada)
>>   - 0120.312271 Japan Toll -Free
>>- Etherpad Link:
>>http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true
>>
>> Agenda
>>
>> ·Administrivia *[2min]*
>>
>>- Approval agenda
>>   - Approval minutes last call
>>   - rechartering news
>>
>> ·PlugTest *[15min]*
>>
>>- Venue info
>>   - Walk-through tests
>>
>> ·Minimal Draft *[25min]*
>>
>>- concluding lass call on abstract / intro
>>   - impacts on main text
>>   - BCP or not BCP ?
>>
>> ·Next steps *[15min]*
>>
>>- draft 6P protocol
>>   - draft SF0
>>
>> ·AOB *[1min]*
>>
>>
>>
>> Comments and suggestions welcome!
>>
>> Pascal, for the chairs.
>>
>>
>>
>> ___
>> 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
>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Minutes, 27 November 2015 interim, 6TiSCH WG

[Prof. Diego Dujovne]

Pascal,
   I would correct the time [16:57] for [7:57].
Regards,

Diego

2015-11-27 13:43 GMT-03:00 Pascal Thubert (pthubert) :

> Note: timestamps in PST.
> Connection details
>
>- Date: 7-8AM Pacific
>- Webex link:
>
> https://cisco.webex.com/ciscosales/j.php?MTID=md64a0958ae4154c0553f056bf42b756a
>- Webex Recording:
>
> https://cisco.webex.com/ciscosales/lsr.php?RCID=593dfc3212814becb59dd237f7804d5b
>- Wiki: https://bitbucket.org/6tisch/meetings/wiki/150925_webex
>- Slides:
>
> https://bitbucket.org/6tisch/meetings/src/master/151127_webex/slides_151127_webex.ppt
>
> Taking notes *(using Etherpad)*
>
>- Diego Duvojne
>- Thomas Watteyne
>- Michael Richardson
>- Pascal Thubert
>- Tengfei Chang
>
> Present *(alphabetically)*
>
>1. Thomas Watteyne
>2. Pascal Thubert
>3. C-Y Lee
>   1. Call-in User_4 (did)
>4. Diego Dujovne
>5. Jonathan Munoz
>6. lavanya (didn't identify him/herself)
>7. Malisa Vucinic
>8. Michael Richardson
>9. Michel Veillette
>10. Nicola Accettura
>11. Pat Kinney
>12. Sedat Gormus
>13. Tengfei Chang
>14. Xavi Vilajosana
>15. Zhuo Chen
>
> Action Items
>
>- Pascal to publish Architecture draft update
>- Xavi to pubish Minimal draft update
>- Chairs to propose new charter to responsible A-D (Brian)
>- Thomas to push adoption e-mails to the 6TiSCH ML
>- Zhuo to kick a ML discussion on whether P2P routing and HbH
>scheduling apply to IP forwarding, G-MPLS, or both
>
> Agenda
>
>- Administrivia *[2min]*
>   - Approval agenda
>   - Approval minutes last call
>- Charte Update *[15min]*
>- Minimal Support: status *[15min]*
>- Architecture: status and directions *[15min]*
>- 6lo drafts (BBR and 6LoRH) *[10min]*
>- AOB *[1min]*
>
> Minutes
>
> ·*[07.??]* Meeting starts Agenda change: Propose Xavi to start
> first. No opposition, approved. Minimal is first.
>
> ·[07.06] Minimal Support: status *[15min]*
>
>- large list of issues created in bitbucket
>   - last issue (#3) needs to be discussed
>   - Xavi goes through summary of all changes. Made changes following
>   the recommendation from the reviewers
>  - editorial changes
>  - changes to RPL
>  - what happens if the network is not multi-hop
>   - intended status: no
>   - [Michael] no intended surveys, but BCPs ("profile") say that,
>   "when using protocol X in context Y, you SHOULD use parameters Z". This 
> is
>   for operators rather than implementors. Minimal says you to use RPL, 
> which
>   you would not implement if you were just using IEEE802.15.4e. AD asked
>   whether this will be used beyond a plugtest.
>   - [Pascal] node requirements for IPv6 is informational, it does not
>   mandate behaviors. Just information about the mote; but doesn't use 
> "MUST".
>   Minimal draft does say you need to compute the RPL rank according. That
>   draft is what this is specified, so it's not just setting parameters. 
> Think
>   we are beyond informational.
>   - [Malisa] agreed with Pascal & Michael, would make sense to
>   publish as standards track. The DTLS profile that is a similar scope, is
>   intended to be published as standards track.
>   - [Michael] RFC6434 list RFCs that you are expected you should look
>   at. RFC6434 should not have been informational. Strictly speaking,
>   informational are not standards.
>   - [Michael] we have a BCP number, but no informational numbers.
>   - [Thomas] Consensus on Standards track. How do we proceed? We are
>   building on top of it Default setup on top of it.
>   - [Michael] A good answer. We have not articulated that.
>   - [Thomas] It is important to publish this. Standard track. RPL
>   rank no anywhere else. This is the spec.
>   - [Pascal] Nobody wants informational, better standard track.
>   Recommendation for developers than for deployers.
>   - [Thomas] Discuss on the ML.
>   - [Pascal] To get an RFC number, highly respected. Already
>   implemented, tested.
>   - [Thomas] Anything else? X: Publish it.
>   - [Thomas] Send it to the ML and send a note.
>   - [Pascal] Copy the link to the diff to see the changes. Thanks.
>   Great work.
>- [07.25] Charter Update *[15min]*
>   - [Pascal] Starts discussion on Charter. We are closing
>   Architecture and Minimal. Plan: Architecture and Minimal published, 
> start a
>   new charter.
>   - [Pascal] Charter: Is a contract with the IESG, 5 elements. 6top
>   sublayer, 6top protocol. Lots of work on IEEE, there is a 6tisch 
> interest
>   group. The plan is go to standards track and then go to IEEE for next 
> gen.
>   Second item: Scheduling Function. We intend to keep SF at the IETF. SF0
>   standards 

[6tisch] Comments on the 6top-sublayer and 6top-sf0 drafts

[Prof. Diego Dujovne]

Dear all,
   Regarding the discussion on the 6top-sublayer and the
6top-sf0 drafts, I would like to point out two items:

- First, If there is a preference for the parent's
schedule over the child, I think the transaction should be started
always from the parent side, but requested (maybe) from the child node.
The problem I see there is that we must define a cell direction indicator
to allocate the cells. Until now, we were managing allocation in a
neighbour-to-neighbour basis, so the one requesting allocation defined
the direction, as Thomas pointed out.

Example: Given two nodes, A and B, neighbours:

If A starts an allocation request towards B, then, it is expected that A
wants
to send traffic to B, so the direction is implicit.

Now, If A is the child and B the parent, A requires cells in the A->B
direction:
A asks B to allocate cells, in the A->B direction; then B starts an
allocation
request to A asking for cells in the A->B direction.

If we do not specify the direction, then, the cell will be allocated in the
opposite
direction. (B->A).

One further item: I assume that we must always use RPL for 6tisch, and that
the RPL DODAG is already formed before SF0 starts sending requests to 6top.

- Second: I agree with Pascal on adding a sequence number to keep
track of transactions. This increases reliability on top of the already
established non-concurrent transactions+timeout philosophy.
I'm only worried about the overhead of this approach (longer
packet and transaction sequence number storage and verification)

What do you think on the former comments?

Thank you.
Regards,

Diego

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Fwd: New Version Notification for draft-dujovne-6tisch-6top-sf0-00.txt

[Prof. Diego Dujovne]

-- Forwarded message --
From: 
Date: 2015-10-19 18:08 GMT-03:00
Subject: New Version Notification for draft-dujovne-6tisch-6top-sf0-00.txt


A new version of I-D, draft-dujovne-6tisch-6top-sf0-00.txt
has been successfully submitted by Diego Dujovne and posted to the
IETF repository.

Name:   draft-dujovne-6tisch-6top-sf0
Revision:   00
Title:  6TiSCH 6top Scheduling Function Zero (SF0)
Document date:  2015-10-19
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-dujovne-6tisch-6top-sf0-00.txt
Status:
https://datatracker.ietf.org/doc/draft-dujovne-6tisch-6top-sf0/
Htmlized:   https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-00


Abstract:
   This document defines a 6top Scheduling Function called "Scheduling
   Function Zero" (SF0).  SF0 dynamically adapts the number of reserved
   cells between neighbor nodes, based on the specific application's
   bandwidth requirements and the network condition.  Neighbor nodes
   negotiate in a distributed neighbor-to-neighbor basis the cell(s) to
   be added/deleted.  SF0 uses the 6P signaling messages to add/delete
   cells in the schedule.  Some basic rules for deciding when to add/
   delete cells and for selecting the cells to be added/deleted within
   the schedule are also provided.





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.

The IETF Secretariat




-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] new term: 6top "Scheduling Function"

[Prof. Diego Dujovne]

Dear all,
  I agree on the term "Scheduling Function"
Regards,

 Diego Dujovne

2015-10-12 13:24 GMT-03:00 Xavier Vilajosana 
:

> Hello,
>
> I support the term Scheduling Function (SF) and once we reach consensus I
> will update the draft.
>
> regards,
> Xavi
>
> 2015-10-12 13:41 GMT+02:00 Thomas Watteyne :
>
>> All,
>>
>> At the call on Friday, some of your indicated that the term "6top
>> Objective Function" (6OF) introduced in
>> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 is too
>> close to RPL's OF, and might lead to confusion.
>>
>> During the call, we agreed on the term "Scheduling Function" (SF).
>>
>> I hence ask the authors of
>> https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 to change
>> the term. Please raise further comments about this terminology in the next
>> 24h.
>>
>> Thomas
>>
>> ___
>> 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
>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] security section in minimal

[Prof. Diego Dujovne]

It is OK for me.
+1

Diego

2015-05-11 4:19 GMT-03:00 Maria Rita PALATTELLA 
maria-rita.palatte...@uni.lu:

  Hi Xavi, (all)

 the suggested text covers all the discussed we have been having so far.

 and it is in line with the scope of minimal.

 THUS, +1 from my side.

 Thanks!

 Maria Rita





 *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Pascal
 Thubert (pthubert)
 *Sent:* Monday, May 11, 2015 8:03 AM
 *To:* Tengfei Chang; Xavier Vilajosana
 *Cc:* 6tisch@ietf.org
 *Subject:* Re: [6tisch] security section in minimal



 Looks good to me, Xavi.



 Cheers,



 Pascal



 *From:* 6tisch [mailto:6tisch-boun...@ietf.org 6tisch-boun...@ietf.org] *On
 Behalf Of *Tengfei Chang
 *Sent:* lundi 11 mai 2015 07:43
 *To:* Xavier Vilajosana
 *Cc:* 6tisch@ietf.org
 *Subject:* Re: [6tisch] security section in minimal



 +1. I agree with description of the text.



 Tengfei



 On Mon, May 11, 2015 at 12:24 PM, Xavier Vilajosana 
 xvilajos...@eecs.berkeley.edu wrote:

 Dear all,



 after the last call we would like to close the security section in
 minimal. We wrapped up all comments from the previous days and from the
 meeting and here is our proposal:



 This draft assumes the existence of two cryptographic keys, K1 and

 K2.  EBs SHOULD be authenticated with key K1.  DATA, ACKNOWLEDGEMENT, and
 MAC COMMAND frame types SHOULD be authenticated and encrypted with key K2.
 For early interoperability, K1 MAY be set to 6TiSCH minimal15.  K2 SHOULD
 be a randomly generated high entropy cryptographic key.  Key distribution
 is out of scope.



 I would like to encourage everybody to see if this texts covers all what
 we want for minimal, and provide consensus. We need to move forward.



 kind regards,

 Xavi


 ___
 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




-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch