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 protected]>: > 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 protected] > 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 protected] | 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)
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
