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

Simon Duquennoy <simonduq@sics.se> Fri, 25 November 2016 11:04 UTC

Return-Path: <simon.duquennoy@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C5512A340 for <6tisch@ietfa.amsl.com>; Fri, 25 Nov 2016 03:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8G8M8gadl7V for <6tisch@ietfa.amsl.com>; Fri, 25 Nov 2016 03:04:18 -0800 (PST)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1555D129E4F for <6tisch@ietf.org>; Fri, 25 Nov 2016 02:52:52 -0800 (PST)
Received: by mail-wm0-x243.google.com with SMTP id g23so7404967wme.1 for <6tisch@ietf.org>; Fri, 25 Nov 2016 02:52:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=N7T83EQkGoJaOOwYIRaSY/Czoken/XBcG6XXgYAqTG8=; b=OcM6V+5NyBdh9mJdjxDCZx/34Mv0Cc/tFxyXrucm2L5uHBSuh8ojb5BFUX/K8rwJgp 3pPWaRvV8B5YIxzPJqLoLGcestciEkMdvQxNY/ki7MXkFF56w50cbp1uL1gKQCJOdGsn RsxJgtuGSo7KSZFIdQIM4BfHwN2PodwIL842PB6giwIa0gbw46l+QLVwSV7qS2vvLzTd ULc7O66o+voUKpEQ/SYXzQgHnEOQVSOWqwh5p9HE4h0WJKLuZ3Qs9E0v5g8QPQx/gXfC SiruteX5a7WpYBewzu81jf/XX3QZ3JQ7F3dSnW/3GiY+mA0XWvUCzjzoJD8maxjdHlWs U/Pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=N7T83EQkGoJaOOwYIRaSY/Czoken/XBcG6XXgYAqTG8=; b=WQHxQ++pISC/5uEGbJrphgD4kNWMtR0WeIqm9Yj5nFhgc2r9SkRuglmnvn127MnJLx VLO7Y+XOXUEI6UN+xCxqUCFIC97JSykFwBhrq2u0CpqBHvlH8zzAqcZ4IXFYrHA4MBMt VA5h1CbdZy3wYoyk1TJkshEbgdnwOAAAbzBBAxRDBjia2+FxUIOpKZ9Bcbw5iMJdCVBu L5uXe2PCcGl70YYsdkTvnzlaEkPZVTIUzrtI+5QaUBXD6xmZ6G1KZU4+BR7gTijkvDaB J0mnAwuFn5/8iOyIv5nyqQY6KdzCngJ9/jb45q82J4LHSns/FHJ6lrn9cKnx7eDLMndO aRdQ==
X-Gm-Message-State: AKaTC032RZeok6PR/l9Osa0ekRNNJzt+ELlDcZPKqSSe5usvq3Pb5htiFK/oLOmLK7jICCUo9R/6sYOnXqbg8w==
X-Received: by 10.194.146.228 with SMTP id tf4mr6792050wjb.183.1480071170531; Fri, 25 Nov 2016 02:52:50 -0800 (PST)
MIME-Version: 1.0
Sender: simon.duquennoy@gmail.com
Received: by 10.80.153.12 with HTTP; Fri, 25 Nov 2016 02:52:49 -0800 (PST)
In-Reply-To: <F085911F642A6847987ADA23E611780D54389B30@hoshi.uni.lux>
References: <CAC9+vPjw+KzHwkRzTQqKcYVZ3M=_FK20OzMRUEZYnzqhzvK1YQ@mail.gmail.com> <bf9efb9569ac450cbbf7f2acbc568630@XCH-RCD-001.cisco.com> <F085911F642A6847987ADA23E611780D543875D3@hoshi.uni.lux> <54938BEE-8747-4459-A26B-44E8AFCC1D1D@kinneyconsultingllc.com> <CADJ9OA8ctNW-SZYZQxfMLgqgHZ4SQC3dfQkDNVH1gQepKLnpLQ@mail.gmail.com> <F085911F642A6847987ADA23E611780D54389B30@hoshi.uni.lux>
From: Simon Duquennoy <simonduq@sics.se>
Date: Fri, 25 Nov 2016 11:52:49 +0100
X-Google-Sender-Auth: XC5EwN55r1Wajgvu_sCmXxOBhS0
Message-ID: <CAMxvJtKbDYgyo63-jV38QZqtkJAEV_DqMKiY9+AUNjc=22K=vw@mail.gmail.com>
To: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>
Content-Type: multipart/alternative; boundary="089e01177bed5ca9ad05421dec39"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Vo8qguSfCs1X9w0GGhxInGtsxig>
Cc: Thubert Pascal <pthubert@cisco.com>, Xavi Vilajosana Guillen <xvilajosana@uoc.edu>, 6tisch <6tisch@ietf.org>, Thomas Watteyne <thomas.watteyne@inria.fr>, "pat.kinney@kinneyconsultingllc.com" <pat.kinney@kinneyconsultingllc.com>
Subject: Re: [6tisch] Adding CCA to the terminology draft
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2016 11:04:23 -0000

Hi Maria Rita,

Great :) There is only one thing I disagree with: the redefinition of
bundles. The TrackID aspect is very important in defining bundles IMO.

Best,
Simon


On Fri, Nov 25, 2016 at 11:39 AM, Maria Rita PALATTELLA <
maria-rita.palattella@uni.lu> wrote:

> 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
>
> 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
>
> c) terms related to other RFCs, drafts, not 6TiSCH specific
>
> - ARO
> - DAR/DAC
> - EAR
> - NEAR
>
> d) Generic Terms, not really needed for understanding 6TiSCH
>
> - Communication Paradigm
> - Interaction Model
> - Interference Domain
> - NME
> - GMPLS
> - MAC
> - QoS
>
> e) terms introduced but afterward not used anymore (such those related to
> the queue model)
>
> - I-MUX module
> - MUX module
> - Operational network key
>
>
> 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."
>
> 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."
>
>
> 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 [thomas.watteyne@inria.fr]
> *Sent:* Tuesday, November 22, 2016 7:45 PM
> *To:* pat.kinney@kinneyconsultingllc.com
> *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, pat.kinney@kinneyconsultingllc.com <
> pat.kinney@kinneyconsultingllc.com> 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
>> pat.kinney@kinneyconsultingllc.com
>>
>> On 22, Nov2016, at 5:57, Maria Rita PALATTELLA <
>> maria-rita.palattella@uni.lu> 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) [pthubert@cisco.com]
>> *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:6tisch-bounces@ietf.org <6tisch-bounces@ietf.org>]
>> *On Behalf Of *Xavi Vilajosana Guillen
>> *Sent:* mardi 22 novembre 2016 11:58
>> *To:* Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>; tisch <
>> 6tisch@ietf.org>
>> *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*­
>>
>>
>> +34 646 633 681| xvilajosana@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
>>
>>
>
>
> --
> _______________________________________
>
> 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
>
>