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

From: Thomas Watteyne <[email-masked]>
Date: Fri, 23 Sep 2016 11:44:33 +0200

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
_______________________________________