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