Re: [6tisch] Comments on draft-ietf-6tisch-msf-00

Xavi Vilajosana Guillen <xvilajosana@uoc.edu> Fri, 31 August 2018 12:54 UTC

Return-Path: <xvilajosana@uoc.edu>
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 11281130E4F for <6tisch@ietfa.amsl.com>; Fri, 31 Aug 2018 05:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu
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 S9jvpEnJNzrg for <6tisch@ietfa.amsl.com>; Fri, 31 Aug 2018 05:53:59 -0700 (PDT)
Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 7FF1D130E48 for <6tisch@ietf.org>; Fri, 31 Aug 2018 05:53:58 -0700 (PDT)
Received: by mail-lf1-x12e.google.com with SMTP id z11-v6so9882372lff.9 for <6tisch@ietf.org>; Fri, 31 Aug 2018 05:53:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EctYTxNHql96RQhDqB/Ga3uViTyG5tJM0wbFmC3F+ik=; b=Jnmp1R+5ruYt9tgZXsYkhsvb3v6KD+shEI2jTuQ8GsdYnsE05/u7gu1yfMFYM92oQb oVUfHFHbz9rRr15aAqaGMorTCnEJRZxLCvxfVLd8bFCcz1hdSXRQkHgELIA4t5t7oU4q C0NQPW6nuK50jI/7uw8I7OnJpi5wKTP5JaoAs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EctYTxNHql96RQhDqB/Ga3uViTyG5tJM0wbFmC3F+ik=; b=UMkby74lb8WcXHM7r5Q4id6LbM7LySg9ZsKT+FL7uwd4eBYj3Gd2fa8nbYjzuWY8H5 TERGAjc44iHKqebOz6R2V3JP+ObIDUotnvZ26ZfBERed87Jy3VFy3iGitI38+hsmubCJ /eLRoJQPN4UiEoU5V+dMepn+VVcm36rAOFX78i/weVFkHwaFZwf8nMznlQNGLf1VhxG7 m91BisVM0mdzRGvqwY/wJZIZt24XqZtQbwgzWRV7ghMhU7FVlcu9py7RRlRENbCnGW7Q Wvrau25g3BULIkfsaJWLZsebQ7o5e/Mw9JJ/u8OxCRM44YEsnVSWEZzlUAvboH+7RlQb CQMQ==
X-Gm-Message-State: APzg51DKbzfX1dhDKl9R2Tl3vyx6464EAYvndX5k3Leu//q6ObbtD7+q /j4e1VVV5bi8uOKsTSx6WILx0zXvApoJWpl/ssOFgA==
X-Google-Smtp-Source: ANB0VdYh/Y7u2mSI8miRAnHykT9Jb/caGU1TdAg2oqNtx9GRtVYupBU7MZPsJ85b/3X46K71TEbujImjNuBG9ngRk6E=
X-Received: by 2002:a19:8d45:: with SMTP id p66-v6mr10118355lfd.44.1535720036388; Fri, 31 Aug 2018 05:53:56 -0700 (PDT)
MIME-Version: 1.0
References: <AB8128C5-C5A4-4E1D-95E5-66ED6A98A1F8@inria.fr> <CAMxvJt+b=pDKz7Tsm1ZXtTsggp1eEiuj9eoKPAz7HNKww=c_Rw@mail.gmail.com>
In-Reply-To: <CAMxvJt+b=pDKz7Tsm1ZXtTsggp1eEiuj9eoKPAz7HNKww=c_Rw@mail.gmail.com>
From: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Date: Fri, 31 Aug 2018 14:53:45 +0200
Message-ID: <CAC9+vPgkks2MxcVew2ip1uS4ot=gxRwpg+QLyRx-8SipB1fw9g@mail.gmail.com>
To: Simon Duquennoy <simon.duquennoy@ri.se>
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003e658e0574baaf6e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/3SrQj7LXzfFZUSEYasWcwGSrFRM>
Subject: Re: [6tisch] Comments on draft-ietf-6tisch-msf-00
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.27
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, 31 Aug 2018 12:54:03 -0000

Hi Yatch, thanks so much for the review.

I jump in complementing Simon´s answer.

Missatge de Simon Duquennoy <simon.duquennoy@ri.se> del dia dv., 31 d’ag.
2018 a les 10:27:

> On Fri, Aug 24, 2018 at 1:52 PM Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
> wrote:
>
>> Hi authors,
>>
>> Congratulations on this great work!
>>
>>   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00
>>
>> I'm sharing my comments on the draft; major comments are followed by minor
>> comments.
>>
>> * discussion: when to schedule autonomous TX cells to neighbors
>>
>> According to Section 4, a join proxy (JP) needs to schedule an autonomous
>> TX
>> cell to a node (pledge) who wants to join the network. Thanks to this, a
>> join
>> process can be done with the autonomous cells of the JP and pledge. These
>> autonomous cells make the network formation faster.
>>
>> However, from the view point of security, it'd be better to avoid
>> installing any
>> state for an unauthenticated/unauthorized node. In this particular case,
>> the
>> join proxy shouldn't schedule the autonomous cell to the pledge.
>>
>> We would need some discussion in "Security Considerations" section if we
>> allow
>> JPs to install autonomous TX cells to their pledges.
>>
>
> I fully agree this needs further discussion. In the worst case we might
> have to move back the join traffic to the minimal cell, yes.
>
>
>>
>> * question: why do we need a separate slotframe for MSF?
>>
>> MSF avoids using slot offset 0 for its autonomous cells and its dedicated
>> cells
>> anyway. The length of Slotframe 1 for MSF is the same as Slotframe 0
>>
>> draft> (Section 3)
>> draft> As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF
>> MUST
>> draft> schedule cells from Slotframe 1, while Slotframe 0 is used for
>> traffic
>> draft> defined in the Minimal 6TiSCH Configuration.
>> draft> (...)
>> draft> The first time offset is skipped to avoid colliding with the
>> minimal cell
>> draft> in Slotframe 0.
>>
>> draft> 8.  Rules for CellList
>> draft>
>> draft> (snip)
>> draft>    o  The slotOffset value of any cell in the CellList MUST NOT be
>> the
>> draft>       same as the slotOffset of the minimal cell (slotOffset=0).
>>
>
> The draft currently says the slotframes SHOULD (not MUST) have the same
> value.
> The rationale for allowing different value is to have more flexible
> dimensioning, and better adjust to more broadcast-intensive or
> unicast-intensive networks.
>
>
>>
>> * question: parameters for SAX
>>
>> What values are used for L and R in SAX? It'd be nice to have an example
>> or a
>> test vector in the draft in order to validate a SAX implementation used
>> for
>> MSF. This is critical for interoperability.
>>
>
> Thanks for pointing out, will fix in next version.
>
>
>>
>> * minor comment 1
>>
>> draft> (Section 1)
>> draft> The end state of the join process is that the node is synchronized
>> to the
>> draft> network, has mutually authenticated to the network, has identified
>> a
>> draft> preferred routing parent, has scheduled one default unicast cell
>> to/from
>> draft> each of its neighbors.
>>
>> The latter part of this sentence seems not to be accurate.
>>
>> After the join process, the node (pledge) has the following cells:
>>
>> - the minimal cell defined by RFC 8180
>> - one autonomous RX cell
>> - autonomous TX cells to its JP
>>
>> This doesn't fit "one default unicast cell to/from each of its neighbors."
>>
>
> Got it, thanks.
>
>
>>
>> * minor comment 2
>>
>> draft> (Section 2)
>> draft> A node implementing MSF MUST implement the Minimal 6TiSCH
>> Configuration
>> draft> [RFC8180], which defines the "minimal cell", a single shared cell
>> draft> providing minimal connectivity between the nodes in the network.
>>
>> 'MUST' here sounds too strong... Some may want to use MSF with a base
>> schedule
>> other than one defined RFC 8180 with full understands on implications by
>> not
>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>
>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
>> document or not.
>>
>
> MSF assumes the presence of the minimal cell, but might be able to run
> without the full RFC8180.
> Happy to hear what others think
>

XV>> MSF needs at least one pre-existing cell in the schedule so a node can
receive/send EBs and form/join into the network. To ensure this we enforce
RFC8180. I think that if someone else implements any other policy there
won't be conflict with the existence of a minimal cell as RFC8180 only
recommends default values which can be overriden.

>
>
>>
>> * minor comment 3
>>
>> draft> (Section 2)
>> draft> 2.  DODAG Information Objects (DIOs), defined by [RFC6550].  These
>> are
>> draft> broadcast frames.
>>
>> A DIO can be sent in a unicast frame.
>>
>> rfc6550> 8.3.  DIO Transmission
>> rfc6550> (...)
>> rfc6550> When a node receives a unicast DIS message with a Solicited
>> Information
>> rfc6550> option and matches the predicates of that Solicited Information
>> option,
>> rfc6550> it MUST unicast a DIO to the sender in response.
>>
>> So, that sentence could be...
>>
>>        2.  DODAG Information Objects (DIOs), defined by [RFC6550].
>> Broadcasted
>>        DIOs are sent over the minimal cell.
>>
>> Or, it would be fine to say just "broadcast frames are (always) sent in
>> the
>> minimal cell", although there is text which doesn't agree with this
>> proposal:
>>
>> draft> 5.1.  Adapting to Traffic
>> draft> (...)
>> draft> Autonomous cells are used indistinguishably together with dedicated
>> draft> cells, for broadcast or unicast traffic with the target neighbor.
>>
>
> Agree, I think we should simply send all broadcast to the minimal cell.
>
>
>>
>> * minor comment 4
>>
>> The following part seems to me an implementation-specific optimization.
>> And it
>> is beyond of the scope of this draft. Basically, this idea is about how
>> to use
>> the minimal cell efficiently; it's not directly related to how to use
>> cells
>> scheduled by MSF.
>>
>> draft> (Section 2)
>> draft> Because the minimal cell is SHARED, the back-off algorithm defined
>> in
>> draft> [IEEE802154-2015] is used to resolve collisions.  To ensure there
>> is
>> draft> enough bandwidth available on the minimal cell, a node
>> implementing MSF
>> draft> SHOULD enforce the following rules for broadcast frames:
>> draft> ...
>>
>
> I'll let other co-authors answer on that one
>

XV> here we place a SHOULD and not a MUST. We want to make sure the network
works as if there is over-use of the minimal cell collapses. We think this
should be said here so an adopter is aware of the limitations and
implements a working measure.

>
>
>>
>> * minor comment 5
>>
>> The phrase of "After joining" in the explanation of step 3 should be
>> "After
>> deciding a JP to use"? At this step 3, "joining" is not done..
>>
>> draft> (Section 4)
>> draft> 4.4.  Step 3 - Setting up Autonomous Unicast Cells
>> draft>
>> draft>    After joining, nodes MUST set up their autonomous unicast
>> cells, as
>> draft>    described in Section 3.  This enables unicast communication in
>> draft>    Slotframe 1, until more cells are added with 6P as defined in
>> draft>    Section 5.
>> draft>
>> draft> 4.5.  Step 4 - Join Request/Response
>>
>
> Good catch, will fix in next version
>
>
>>
>> * minor comment 6
>>
>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
>> section?
>>
>
> I'll let other co-authors answer
>

XV> I think this was though to handle pagination when the LIST command is
received. This is, define what are the cells to return when a list command
is requesting cells from a particular offset.

>
>
>>
>> That's all!
>>
>
> Thanks a lot Yatch!
> Simon
>
>
>>
>> Best,
>> Yatch
>>
>> _______________________________________________
>> 6tisch mailing list
>> 6tisch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
xvilajosana@uoc.edu <usuari@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]
­