Re: [6tsch] comments unpublished draft-vilajosana-6tisch-minimal-00.txt

Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> Tue, 01 October 2013 04:01 UTC

Return-Path: <xvilajosana@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2121521F9A99 for <6tsch@ietfa.amsl.com>; Mon, 30 Sep 2013 21:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level:
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP2fcPlPAFrJ for <6tsch@ietfa.amsl.com>; Mon, 30 Sep 2013 21:01:20 -0700 (PDT)
Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id B431E21F9AA1 for <6tsch@ietf.org>; Mon, 30 Sep 2013 21:01:07 -0700 (PDT)
Received: by mail-pb0-f41.google.com with SMTP id rp2so6516594pbb.14 for <6tsch@ietf.org>; Mon, 30 Sep 2013 21:01:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aIBCyL+5xRoBat0xHw1JxDpiA+b1DF4cf1vyNcoTGsA=; b=dyCdT4WE4kq2FOG46N1xC2jaBydFHag30Eax2vGqgjN9Z3hLx2qSOEuq5r54gCwMza ieKlafhFM4T4/6H5kwfSGPk8YW4VRsUt7kMojLOAorJLgR3gn/9My6z4x8Qx/YWpg7Np YbQKufcfEKHZ/iqQopb4le9eW8Ytdc2dUNZnTOs4N3JIFr0CVm1vtt36C4Gbi37BF2aw +9/UYQjVEbVwLRRXRjARHXNIVlw2hA16eyqLb2sQxwXJnED57on9pyn9559yiGN7Wt3i DoFoWqOooDicExog9Zxf6UWCk+Bcs5cLv73ahdde55GOeSBEV44l8Q3I5c8zkTZ8XQwK t5+g==
X-Gm-Message-State: ALoCoQm5rLGHtXH1QmyssxT0miU2U7v9sXLqdLBHwXVsc4xrfrQArjzlzJfw3my9cxXgcfX3GHyb
MIME-Version: 1.0
X-Received: by 10.68.215.38 with SMTP id of6mr27283206pbc.14.1380600067389; Mon, 30 Sep 2013 21:01:07 -0700 (PDT)
Received: by 10.70.34.44 with HTTP; Mon, 30 Sep 2013 21:01:07 -0700 (PDT)
In-Reply-To: <CADJ9OA_NJsv_DC=UtVyA8V_Tp0Y7f2cdM33NvwMPUfCyPYQq1w@mail.gmail.com>
References: <CADJ9OA_NJsv_DC=UtVyA8V_Tp0Y7f2cdM33NvwMPUfCyPYQq1w@mail.gmail.com>
Date: Mon, 30 Sep 2013 21:01:07 -0700
Message-ID: <CALEMV4ZNZQXyBNf+_Zvx6jk9+=XupwgHQSiCDAYLTck0sdCsbQ@mail.gmail.com>
From: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=001a1134663898057d04e7a600a1
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] comments unpublished draft-vilajosana-6tisch-minimal-00.txt
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: xvilajosana@eecs.berkeley.edu
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2013 04:01:24 -0000

thanks Thomas for the exhaustive review! I will address your comments
tomorrow.

regards,
Xavi


On Mon, Sep 30, 2013 at 8:58 PM, Thomas Watteyne <watteyne@eecs.berkeley.edu
> wrote:

> Xavi, Kris,
>
> Per the last 6TiSCH webex on Friday, I reviewed the unpublished version
> of draft-vilajosana-6tisch-minimal-00, in particular the file
> https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src/3ead236bdc563747fea826e8d632fd99f3bb868e/draft-vilajosana-6tisch-minimal-00.txt?at=master.
> You will find the remarks below.
>
> Thomas
>
> ----
>
> Remarks:
>
>    1. In the abstract, you might consider indicating that the minimal
>    configuration can be used for more than interop testing. Example rewording:
>    "This minimal mode of operation can be used during network bootstrap, as a
>    fallback mode of operation when no dynamic scheduling solution is available
>    or functioning, or during early interoperability testing and development".
>    2. Similarly, I would highlight these cases also in the introduction,
>    maybe providing one sentence per case. A reference
>    to draft-ietf-roll-rpl-industrial-applicability might be appropriate at
>    that point.
>    3. "[IEEE802154e] provides a mechanism whereby the details of
>    slotframe length, timeslot timing, and channel hopping pattern are
>    communicated to a node during initial synchronization". I believe the EB
>    can also indicate the cells to use.
>    4. "the radio of the nodes remains off." You might want to indicate
>    that those 95 timeslots are available for a dynamic scheduling solution.
>    5. in the "Minimal schedule overview" figure, why "TxRxS" and not
>    simply "TxRx"?
>    6. "All scheduled cells in the minimal schedule are configured as Hard
>    cells [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top]
>    since reallocation is not considered in that simple approach." That's not
>    strictly true if we consider a dynamic scheduling approach can schedule the
>    remaining 95 slots. Maybe specify that the cell allocated by this document
>    are hard cells, but that this does not necessarily apply to any additional
>    cells scheduled by a dynamic scheduling solution.
>    7. Unscheduled cells should not occupy any memory -> Unscheduled cells
>    SHOULD NOT occupy any memory
>    8. the transmissions is considered failed at the MAC layer, and the
>    upper layer needs to be notified -> the transmissions is considered failed
>    and the MAC layer MUST notify the upper layer
>    9. 2.4.  Time Slot timing is redundant
>    with draft-watteyne-6tsch-tsch-lln-context. We could consider moving the
>    diagram and text to that draft, and leave just the table in this draft,
>    together with a reference to the draft-watteyne-6tsch-tsch-lln-context.
>    Thoughts welcome.
>    10. "this document recommends to hard-code the different durations to
>    the values listed below." This it not strictly true, since the intro says
>    that one can dynamically learn through the EB. Please say the same in this
>    text.
>    11. it is recommended to sent EBs at least once every 10s -> a mote
>    SHOULD send an EB every 10s
>    12. EBs must be sent with the Beacon IEEE802.15.4 frame type -> EBs
>    MUST be sent with the Beacon IEEE802.15.4 frame type
>    13. "this document recommends that they carry the following
>    Information Elements (IEs)". Since nodes can either hard-code or learn on
>    the fly, I believe the list of IEs is a MUST.
>    14. Section 3 contains the value of all fields. Please specify that
>    this is redundant with [IEEE802.15.4e]
>    and [I-D.watteyne-6tsch-tsch-lln-contex], and provided here for clarity.
>    15. In 3.1.2., what's the value of Join Priority?
>    16. "each node SHOULD indicate the schedule in each EB through a Frame
>    and Cell IE". Per discussion above, maybe MUST?
>    17. please give each neighbor statistics a name, e.g. numTx
>    18. "Neighbour address". Which address? EUI, IPv6, both?
>    19. Per last call use timestamp rather than ASN in "Timestamp when
>    that neighbour was heard for the last time. This can be based on the ASN
>    counter or any other time base."
>    20. "Connectivity statistics (RSSI, LQI, etc),". I would simply RSSI,
>    since LQI is not well defined.
>    21. "Each node selects at least one time parent amongst its known
>    neighbours." I suggest "Each node MUST select a time source neighbor among
>    the neighbors in its RPL routing parent set"
>    22. PAN coordinator is an old term. Let's use the term DAG root.
>    23. "it is NOT allowed" -> "is MUST NOT" (NOT cannot be used alone)
>    24. "start advertising the network" -> "send EBs"
>    25. I would remove "e.g RSSI when the EB has been received as no other
>    metrics are available at that moment"
>    26. Strictly speaking, "time parent" does not exist. Please use the
>    term "time source neighbor"
>    27. "A backup time parent can also be selected (as required by RPL and
>    described in Section 7.1 following the same rule)." It is unclear how that
>    backup is used. What you could say is that, if connectivity to the time
>    source neighbor is lost, a new time source neighbor MUST be chosen among
>    the neighbor in the RPL routing parent set.
>    28. I understand "Optionally, a node [...] selected" is about
>    hysteresis. As is, it is not clear what exactly is defined. I would simply
>    state that "some form of hysteresis SHOULD be implemented to avoid frequent
>    changes in time source neighbors"
>    29. "Lower-layer packets " -> "Frames generated by the MAC layer (e.g.
>    EBs and ACK)"
>    30. "A minimal TSCH configuration [...] tests" is WAY to verbose.
>    Please reword by something as simple as "Nodes in the network MUST use the
>    RPL routing protocol".
>    31. Same thing for the long intro to Section 7.1.
>    32. In 7.1.1, I would not repeat RFC6552, just state that a mote MUST
>    use step_of_rank as 2*ETX
>    33. "This information can be extracted from the neighbours information
>    described in Section 5.1." Please replace by equation based on counters.
>    34. I would keep 7.1.2, which helps clarify.
>    35. Same for 7.2.2, please remove repeats, and list simply the
>    configuration.
>    36. If possible, please federate the discussion about hysteresis for
>    both the routing and time source selection, since it's one and the same
>    thing.
>    37. What's the recommended value for PARENT_SWITCH_THRESHOLD?
>
> Minor remarks (*a* means add, **a** means remove, please use Ctrl+F to
> find):
>
>    1. Number of time slots per **Slotframe** *slotframe*
>    2. Amendament->Amendment
>    3. Number of EB**s** cells
>    4. These EBs *sent to the broadcast MAC address and* are not
>    acknowledged
>    5. Per the [IEEE802154e] **TSCH** standard
>    6. options below that -> options below, which
>    7. set,* *in
>    8. in presence of collisions it uses the back-off mechanism defined in
>    [IEEE802154e] -> the back-off mechanism defined in [IEEE802154e] is used to
>    resolve contention
>    9. node (RX), and a MAC -> node (RX). A MAC
>    10. fully to **be able to** configure
>    11. Size Slotframe (b32-b47) = 0x65 *(101)*
>    12. "Slot Number (2B) = from (0x00 to 0x05)" why the parenthesis?
>    13. Time Synch*ronization* information
>    14. "but it should at least contain the following information, for
>    each neighbour" -> "it SHOULD contain the following information for each
>    neighbor"
>    15. RPL objective function (OF) -> RPL Objective Function (OF)
>    16. "parent, uses the Join Priority" -> parent, it uses the Join
>    Priority
>    17. of **the** [IEEE802154e]
>    18. i.e*.* EBs sent
>    19.  When a nodes Joins -> When a node joins
>    20. " The later aims to avoid" -> "The latter avoids"
>    21. match*es* RPL topology
>    22. it is allowed to send Enhanced Beacons -> it SHOULD send Enhanced
>    Beacons
>    23. In case of a node receiving EBs -> In case a node receives EBs
>    24. a*n* IEEE802.15.4
>    25. Watteyene -> Watteyne
>
> administrative remark:
>
>    1. the repository is now called draft-vilajosana-6tsch-basic. Please
>    rename to draft-vilajosana-6tisch-minimal. You might want to give people
>    48h notice in case they have it cloned.
>    2. please use the bitbucket issue tracker built into your repository
>    to track these remarks.
>
> Remarks about the XML file:
>
>    1. While I reviewed the TXT version, I took the liberty to look at the
>    XML file.
>    2. For homogeneity with the other 6TiSCH drafts, please replace tabs
>    by 3 spaces, especially in figures. This should also fix indentation issues.
>    3. The draft-wang-6tsch-6top is published. Please replace the explicit
>    reference to "I-D.draft-wang-6tsch-6top" accordingly. This will also ensure
>    the correct I-D version.
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>