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]
- [6tisch] Comments on draft-ietf-6tisch-msf-00 Yasuyuki Tanaka
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-00 Simon Duquennoy
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-00 Xavi Vilajosana Guillen
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-00 Yasuyuki Tanaka
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-00 Yasuyuki Tanaka
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-00 Simon Duquennoy