Subject: Re: [6tisch] Thomas' review of draft-ietf-6tisch-6top-sf0-01

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Fri, 23 Sep 2016 13:14:37 +0200

Hi Thomas,

thanks for your comments I confirm I will attend the meeting this
afternoon. I will go through your reviews carefully.

thanks so much!
X

2016-09-23 11:44 GMT+02:00 Thomas Watteyne <[email-masked]>:

> All,
>
> In preparation of the 6TiSCH interim meeting later today, below is my
> review of draft-ietf-6tisch-6top-sf0-01. I'm reading the XML file
> directly at https://bitbucket.org/6tisch/draft-ietf-6tisch-6top-
> sf0/src/master/draft-ietf-6tisch-6top-sf0-02.xml, to be most up-to-date.
>
> *@authors*, could you confirm you will attend the 6TiSCH interim meeting
> later today?
>
> Thomas
>
> *issue tracking*
>
> This is now a WG doc. Per the 6TiSCH best practice, this means issues
> should be tracked by https://trac.tools.ietf.org/wg/6tisch/trac/report/1
>
> *@editor*, please:
> - report the open issue on the bitbucket issue tracker into the IETF
> 6TiSCH issue tracker
> - disable the bitbucket issue tracker
>
> *organization*
>
> The idea is that the definition of an SF follows the recommendations from
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#section-5,
> in particular answers all the requirements and follows the structure.
>
> *@editor*, please add an appendix at the draft to indicate whether you
> answer all requirements (checklist) and formatting. You can mark this
> appendix a temporary by putting the "[temporay]" keyword. One example is
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#appendix-A.
>
> *implementation/.performance evaluation*
>
> The WG needs to know (1) who implemented this and (2) how good the
> proposed solution performes.
>
> *@editor*, follow the implementation section by a "Performance
> Evaluation" section in which you list the key results. The WG needs to know
> the limits of the SF: how does it scale with number of motes, network
> dynamics, etc.
>
> *figure*
>
> *@editor*, as discussed in IETF96 Berlin, Figure "The SF0 Allocation
> Policy" is not clear. Please comment on the changes you agreed to do.
>
> *general confusion about cells/bandwidth*
>
> I fail to understand the relationship between cells and bandwidth. You
> express bandwidth in kbps, but a cell carries one packet, and that packet
> can contain ~0-100 bytes of payload. Many small packets is very different
> from a few large packets from a scheduling point of view.
>
> I therefore STRONGLY suggest to think about number of packets, no kbps.
>
> *general questions about PDR*
>
> I'm not at all convinced about using PDR to calculate the number of cells,
> based on a number of kbps. It's unbelievably complex for no reason.
>
> Rather, I suggest to think only about number of cells used: if I'm using
> 90% (resp. add) of the outgoing cells to a particular neighbor over some
> period of time, I should probably add (resp. delete) some.
>
> *about timeout*
>
> The draft now says
>
> "The general timeout equals the equivalent time of the number of slots
> until the next scheduled cell."
>
> Next scheduled cell to whom? In RX or TX? What are retries?
>
> Similarly, "Node Behavior at Boot" states that the "timeout" is calculated
> as:
>
> timeout = (2^(macMaxBE+1)-2^macMinBE) * SM
>
> - what timeout is this exactly?
> - minimal Slotframe, SM: is that a duration, a number of slots?
> - what is the unit of timeout?
>
> *metadata*
>
> I don't understand the use of the metadata in Section "Meaning of Metadata
> Information".
>
> *PDR threshold*
>
> "Relocating Cells" now states:
>
> SF0 uses Packet Delivery Rate (PDR) statistics to monitor the currently
> allocated cells for cell re-allocation (by changing their slotOffset and/or
> channelOffset) when it finds out that the PDR of one or more softcells
> below 20% of the average PDR.
>
> The average PDR of what? Why 20%?
>
> *editorial suggestions*
>
> - the many acronyms (BEA, COBU, NIBR,NOB, AP, etc) add confusion more than
> clarity. THere appears to be a new term/acronym every 2 sentences! Can we
> not simply talk about "incoming", "outgoing" and "generated"? Not every
> word needs an acronym.
> - I don't understand what Whitelist and Blacklist mean in the "Rules for
> CellList" section.
> - "delete one or more cells" and "add one or more cells" is not precise
> enough. How many should be added/deleted?
> - the term bandwidth is confusing. Is it a number of packets per second?
> per frame? a number of cells? *@editor*, please add a definitions
> section, and consider changing the terminology.
> - isn't "NOB=NIBR-COBU", not "NOB=COBU+NIBR"
> - the draft starts very abruptly by referencing triggering events, BEA and
> allocation policy in the "Rules for Adding/Deleting Cells" Section. At that
> point of the draft, the reader has no idea what that is. *@editor*,
> please add an "Overview" section which contains a couple of paragraphs.
>
> *nits and typos*
>
> [use Ctrl+F]
>
> - "and determine" -> "and determines"
> - re-allocation-> relocation
> - dissappears -> disappears
> - 6P ALL Request -> 6P ADD Request?
>
> --
> _______________________________________
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya

+34 646 633 681| [email-masked] | 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)

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 23 Sep 2016 08:29:23 -0300

Thomas,
              Thanks for the review, I hope to attend to the call.
I am very happy that we can discuss these items, so we
can provide a new version with the feedback before IETF97.
              Regards,

                                               Diego

2016-09-23 8:14 GMT-03:00 Xavi Vilajosana Guillen <[email-masked]>:

>> directly at https://bitbucket.org/6tisch/draft-ietf-6tisch-6top-sf0/
>> src/master/draft-ietf-6tisch-6top-sf0-02.xml, to be most up-to-date.
>>
>> I'm not at all convinced about using PDR to calculate the number of
>> cells, based on a number of kbps. It's unbelievably complex for no reason.
>>
>> Similarly, "Node Behavior at Boot" states that the "timeout" is
>> calculated as:
>>
>> I don't understand the use of the metadata in Section "Meaning of
>> Metadata Information".
>>
>> *PDR threshold*
>>
>> - the many acronyms (BEA, COBU, NIBR,NOB, AP, etc) add confusion more
>> than clarity. THere appears to be a new term/acronym every 2 sentences! Can
>> we not simply talk about "incoming", "outgoing" and "generated"? Not every
>> word needs an acronym.
>> - the draft starts very abruptly by referencing triggering events, BEA
>> and allocation policy in the "Rules for Adding/Deleting Cells" Section. At
>> that point of the draft, the reader has no idea what that is. *@editor*,

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Sep 2016 13:29:50 +0200

Excellent!

On Fri, Sep 23, 2016 at 1:29 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

>>> directly at https://bitbucket.org/6tisch/draft-ietf-6tisch-6top-sf0/s
>>> rc/master/draft-ietf-6tisch-6top-sf0-02.xml, to be most up-to-date.
>>>
>>> *@authors*, could you confirm you will attend the 6TiSCH interim
>>> meeting later today?
>>>
>>> Thomas
>>>
>>> *issue tracking*
>>>
>>> The idea is that the definition of an SF follows the recommendations
>>> from https://tools.ietf.org/html/draft-ietf-6tisch-6top-prot
>>> ocol-02#section-5, in particular answers all the requirements and
>>> follows the structure.
>>>

Thomas Watteyne, PhD

www.thomaswatteyne.com