Re: [6tisch] Adding CCA to the terminology draft

[Thomas Watteyne <[e-mail]>]

Cool

On Fri, Dec 9, 2016 at 3:30 PM, Maria Rita PALATTELLA <
[e-mail]> wrote:

> Thomas, I will join the call.
> Sure, I can shortly summarize the current discussion.
> I also believe there is no real need to have slides.
> Maria Rita
> ------------------------------
> *From:* Thomas Watteyne [[e-mail]]
> *Sent:* Friday, December 09, 2016 3:17 PM
> *To:* Pascal Thubert (pthubert)
> *Cc:* Maria Rita PALATTELLA; [e-mail]; 6tisch;
> Xavi Vilajosana Guillen
>
> *Subject:* Re: [6tisch] Adding CCA to the terminology draft
>
> Maria Rita,
> Will you be on the call in 45min? Can you provide us with a quick update
> on what was agreed upon? No slides needed I believe, unless you want to put
> some together quickly and present from your computer.
> Thomas
>
> On Fri, Nov 25, 2016 at 12:10 PM, Pascal Thubert (pthubert) <
> [e-mail]> wrote:
>
>>
>>
>> Hello Maria Rita
>>
>>
>>
>> *From:* Maria Rita PALATTELLA [mailto:[e-mail]]
>> *Sent:* vendredi 25 novembre 2016 11:40
>> *To:* Thomas Watteyne <[e-mail]>;
>> [e-mail]
>> *Cc:* Pascal Thubert (pthubert) <[e-mail]>; 6tisch <
>> [e-mail]>; Xavi Vilajosana Guillen <[e-mail]>
>> *Subject:* RE: [6tisch] Adding CCA to the terminology draft
>>
>>
>>
>> Thomas, all,
>>
>> I have gone through the list of terms in the terminology draft, and I
>> agree there are some terms that we MAY want to DELETE.
>>
>> In particular:
>>
>> a) terms specifying forwarding models, defined in the architecture draft,
>> but never used afterward in any other draft. And moreover not in the
>> current std. scope of 6TiSCH
>>
>> - 6F: IPv6 Forwarding
>> - FF: 6LoWPAN Fragment Forwarding
>> - TF: Track Forwarding
>>
>> *[Pascal] agree to remove*
>>
>>
>>
>>
>> b) confusing terms
>>
>> - CDU matrix - concept related to chunk, but never used, and it created a
>> lot of confusion in the group in the past. We can keep chunk, without the
>> need of CDU
>>
>> *[Pascal] I’d keep that one, we have not really started the work related
>> to it, may be useful*
>>
>>
>>
>>
>> c) terms related to other RFCs, drafts, not 6TiSCH specific
>>
>> - ARO
>> - DAR/DAC
>> - EAR
>> - NEAR
>>
>>
>>
>> *[Pascal] agree to remove*
>>
>>
>>
>> d) Generic Terms, not really needed for understanding 6TiSCH
>>
>> - Communication Paradigm
>> - Interaction Model
>> - Interference Domain
>> - NME
>> - GMPLS
>> - MAC
>> - QoS
>>
>> *[Pascal] agree to remove*
>>
>>
>> e) terms introduced but afterward not used anymore (such those related to
>> the queue model)
>>
>> - I-MUX module
>> - MUX module
>> - Operational network key
>>
>> *[Pascal] agree to remove*
>>
>>
>>
>> Moreover, we could also simply:
>>
>> i) the definition of bundle, currently quite long, by keeping only the
>> first part:
>>
>> "A group of equivalent scheduled cells, i.e. cells identified by
>> different [slotOffset, channelOffset], which are scheduled for a same
>> purpose, with the same neighbor, with the same flags, and the same
>> slotframe. The size of the bundle refers to the number of cells it
>> contains. For a given slotframe length, the size of the bundle translates
>> directly into bandwidth. A bundle represents a half-duplex link between
>> nodes, one transmitter and one or more receivers, with bandwidth that
>> amounts to the sum of the cells in the bundle."
>>
>> *[Pascal] The latter sentence is incorrect; like a schedule, a bundle is
>> a local abstraction and it is not a concern of this node whether it is a
>> sole sender or listenenr on it.*
>>
>> “ A bundle is a local abstraction that represents a half-duplex link for
>> either sending or receiving, with bandwidth that amounts to the sum of the
>> cells in the bundle."
>>
>>
>> ii) the current definition of deterministic network:
>>
>> "A Deterministic Network supports traffic flows with communication
>> patterns that are known a priori. Thus, routing paths and communication
>> schedules can be computed in advance, in a fashion similar to a railway
>> system, to avoid losses due to packet collisions, and to perform global
>> optimizations across multiple flows.  A deterministic network can allocates
>> the required resources (buffers, processors, medium access) along the
>> multi-hop routing path at the precise moment the resources are needed."
>>
>> with the following: " In the context of 6TiSCH, a network where the
>> packet delivery rate, end-to-end latency and energy consumption of the
>> nodes can be predicted."
>>
>>
>> *[Pascal] We can never guarantee a PDR : ) I’d say that the generic
>> concept is defined in
>> https://tools.ietf.org/html/draft-ietf-detnet-architecture
>> <https://tools.ietf.org/html/draft-ietf-detnet-architecture> and that with
>> 6TiSCH it is implemented by reserving Tracks which guarantee an end to end
>> latency and optimize the PDR for well-characterized flows*
>>
>>
>>
>> Finally, can someone in the 6TiSCH-security team provide some explenation
>> of the "Operational Network" definition:
>>
>> "A IEEE802.15.4e network whose encryption/authentication keys are
>> determined by some algorithms/protocols. There may be network-wide group
>> keys, or per-link keys."
>>
>> It is not so clear the link between the term and its definition. Thanks.
>>
>> Once the group agree in applying the proposed changes, I can update the
>> draft accordingly.
>> Thank you.
>>
>> Best Regards,
>> Maria Rita
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> ------------------
>>
>> *From:* Thomas Watteyne [[e-mail]]
>> *Sent:* Tuesday, November 22, 2016 7:45 PM
>> *To:* [e-mail]
>> *Cc:* Maria Rita PALATTELLA; Thubert Pascal; 6tisch; Xavi Vilajosana
>> Guillen
>> *Subject:* Re: [6tisch] Adding CCA to the terminology draft
>>
>> Thanks Maria Rita for agreeing to add the term. Can I ask you to do the
>> edit in the repo?
>>
>>
>>
>> About last call, while I agree with the definitions in there, we MAY want
>> to remove some, or at least do a sanity check. Maria Rita, could I ask you
>> to go through the list and make some recommendations?
>>
>>
>>
>> Thomas
>>
>>
>>
>> On Tue, Nov 22, 2016 at 2:25 PM, [e-mail] <
>> [e-mail]> wrote:
>>
>> I think that we need to remember that in some cases CCA is necessary for
>> minimal, such as shared slots, but also when there are multiple instances
>> of 6tisch being used by non-coordinated entities.
>>
>>
>>
>> Regardless, "In the TSCH mode, backoff is calculated in shared links, so
>> the CSMA-CA aUnitBackoffPeriod  is not used.”  The CCA mode may be
>> enabled for TSCH by the TSCH-MODE.request where the TschMode may be enabled
>> and also the TschCca may be enabled
>>
>>
>>
>> Pat Kinney
>>
>> *Kinney Consulting LLC*
>>
>> IEEE 802.15 WG vice chair, SC chair
>>
>> ISA100 co-chair, ISA100.20 chair
>>
>> O: +1.847.960.3715
>>
>> [e-mail]
>>
>>
>>
>> On 22, Nov2016, at 5:57, Maria Rita PALATTELLA <
>> [e-mail]> wrote:
>>
>>
>>
>> Xavi,
>>
>> sure, we can add CCA among the terms.
>>
>> Pascal, about the last call for the terminology draft, I believe we can
>> go for it.
>>
>> Maybe we only need to check first if there are new terms coming from the
>> 6P and SF0 drafts (but I doubt, because we checked already last time), or
>> from the latest security related drafts (draft-vucinic-6tisch-minimal-security,
>> and draft-richardson-6tisch-dtsecurity-secure-join).
>>
>> @Malisa and Michael: do you see any term missing? you would like to add?
>>
>> Thank you
>> Maria Rita
>>
>>
>>
>> ------------------------------
>>
>> *From:* Pascal Thubert (pthubert) [[e-mail]]
>> *Sent:* Tuesday, November 22, 2016 12:28 PM
>> *To:* Xavi Vilajosana Guillen; Maria Rita PALATTELLA; tisch
>> *Subject:* RE: [6tisch] Adding CCA to the terminology draft
>>
>> That would be good.
>>
>>
>>
>> Also: as discussed at the IETF meeting, we also need to trigger last call
>> for the terminology draft, which will cause minimal to be held for
>> publication otherwise.
>>
>>
>>
>> Maria-Rita, do you think we are ready for that?
>>
>>
>>
>> Take care,
>>
>>
>>
>> Pascal
>>
>>
>>
>> *From:* 6tisch [mailto:[e-mail] <[e-mail]>]
>> *On Behalf Of *Xavi Vilajosana Guillen
>> *Sent:* mardi 22 novembre 2016 11:58
>> *To:* Maria Rita PALATTELLA <[e-mail]>; tisch <
>> [e-mail]>
>> *Subject:* [6tisch] Adding CCA to the terminology draft
>>
>>
>>
>> Dear Maria Rita,
>>
>>
>>
>> I would like to suggest adding the following definition to the
>> terminology draft so we can point to it from minimal.
>>
>>
>>
>> CCA: Clear Channel Assessment. Mechanism defined in <xref
>> target="IEEE802154-2015"/>, section 6.2.5.2. In a TSCH network, CCA can
>> be used to detect other radio networks in vicinity. Nodes listen before
>> sending to detect other ongoing transmissions. Because the network is
>> synchronized, CCA cannot be used to detect colliding transmission within
>> the same network.
>>
>>
>>
>> let me know if this is possible.
>>
>> thanks!
>>
>> X
>>
>>
>>
>> --
>>
>> *Dr. Xavier Vilajosana Guillén*­
>>
>> Research Professor
>> Wireless Networks Research Group
>>
>> Internet Interdisciplinary Institute (IN3)
>>
>> *Universitat Oberta de Catalunya*­
>>
>>
>>
>> [phone]| [e-mail]­ | 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>>
>>
>> --
>>
>> _______________________________________
>>
>>
>>
>> Thomas Watteyne, PhD
>>
>> Research Scientist & Innovator, Inria
>>
>> Sr Networking Design Eng, Linear Tech
>>
>> Founder & co-lead, UC Berkeley OpenWSN
>>
>> Co-chair, IETF 6TiSCH
>>
>>
>>
>> www.thomaswatteyne.com
>>
>> _______________________________________
>>
>
>
>
> --
> _______________________________________
>
> Thomas Watteyne, PhD
> Research Scientist & Innovator, Inria
> Sr Networking Design Eng, Linear Tech
> Founder & co-lead, UC Berkeley OpenWSN
> Co-chair, IETF 6TiSCH
>
> www.thomaswatteyne.com
> _______________________________________
>



-- 
_______________________________________

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

www.thomaswatteyne.com
_______________________________________