Excellent! On Fri, Sep 23, 2016 at 1:29 PM, Prof. Diego Dujovne < [email protected]> wrote:
> 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 protected]>: > >> 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/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* >>> >>> 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-prot >>> ocol-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-protoc >>> ol-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 >> >> > > > -- > 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 > -- _______________________________________ 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
