In an effort to prepare the re-factoring of https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into what will become the SF0, we had an ad-hoc meeting with the authors of that draft.
Minutes below. Thomas ---- Minutes, 13 October 2015, ad-hoc meeting SF0 Note: times in CET NO recording was made, since this is an ad-hoc (no WG interim) meeting. Present - Diego Dujovne - Nicola Accettura - Alfredo Grieco - Maria Rita Palattella - Thomas Watteyne action items - *Diego* to rename repo, create skeleton of SF0 document, and assign tasks - *Nicola* to write down exact formula for calculating the timeout - *Nicola* and *Thomas* to be available to write parts of the document - *Maria Rita* and *Alfredo* to proof-read documents before publication goal discuss how to re-factor https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into the SF0 draft, so fits nicely on top of https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02 minutes - meeting starts at 11.00 AM - Intro - *Thomas* details the idea of 6P+SF0 - *Maria Rita*: Define mechanism to select the cell. Give basic rule on how to pick the cell. For example, how to pick the cells. We were relying on the monitoring already there, but now it should be done by the SF0. - *Thomas* agreed. Cells could be selected randomly. We need to align the two drafts. Look at what is written in the sublayer draft. Sec. 4.2 lists what a SF must do. - *Maria Rita*: what is the timeout? - *Thomas* timeout value depends on the RTT between neighbors. We can put a high value, nevertheless the scheduler function knows the cells already with the neighbor, so it may calculate a timeout value. - *Maria Rita*: what is the container field? - *Thomas* allows us to use multiple SFs on the same node, and use them on different slotframes/chunks. - *Maria Rita*: what is a cell identified with? - *Thomas* 4-byte cell identifier. Container generic. e.g. always from container 0, or the container is a set of flags, or the container can be the chunk number. - *Nicola* The cell selection a request a block of cells, so the receiver can choose the channel offset. Maybe identified by boundaries (set of cells) for allocating one or more cells. Indicate many: the whole block offset can be allocated, but also the channel offset. - *Thomas* great idea, but maybe more an extension for the simple mechanism, with cell boundaries. We can evolve to a new version. So we can say that two cells can mean the beginning and the end. - *Nicola* both must understand the same meaning on both ends. If a bigger set of cells is proposed, there is a higher chance to have a successful allocation. All the available cells on the transmitter side. - *Thomas* agreed that in that case it's more efficient to encode it as a range rather than a list of discrete cells. But maintains that this is an optimization for cases where the schedule is very dense - *Nicola* agrees that better for other scheduling functions apart from SF0. Even just saying the channel offset. Slot offset may generate more conflicts than channel offset. - *Thomas* We are not aiming to put the complete list of cells. Not exhaustive. If the first don't work, try others. We are talking of the probability to choose from the ones proposed, which is very high, given that schedule is mostly empty. Some optimizations can be proposed in case the schedule is filled. What you describe is a more efficient way of describing a range of cells. This can be described using by using what is specified on 3.1.5 of the sublayer draft. - Go over the requirements for an SF in https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02#section-4.2 - MUST specify an identifier for that 6OF. - IANA_SF0_ID. In IANA Consideration section, ask IANA to allocate a number. We recommend "0". - MUST specify a set of rules for a node to decide when to add one or more cells to a neighbor. - contents of https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-2 and https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-7 combined - *Maria Rita* we can distinguish 2 phases: - estimation (section 7) - based on estimation, comparison and decide to ADD/DELETE (section 2) - *Nicola*: issue: exchange add/remove cells - *Thomas* creates an issue on the OTF issue tracker. - MUST specify a set of rules for a node to decide when to delete one or more cells to a neighbor. - same as above - MUST specify a value for the timeout, or a rule to calculate it. - *Nicola* describes a formula which depends on backoff algorithm - Action item: *Nicola* to write down exact formula for calculating the timeout - MUST specify a meaning for the "Container" field in the 6P ADD Request. - value in the container field is the slotframe handle to pick from - we RECOMMEND to announced as a second slotframe in the EB, with NO slots - MUST specify the rule for selecting the cells (including their number) to add to the CellList field in the 6P ADD Request. - *Nicola*: More priority to the 6OF traffic? Possible overlap of Minimal with the 6OF slotframe. - *Thomas*: Possible deadlock if higher priority given to 6OF. - *Nicola*: Multicast traffic-related higher priority. - *Maria Rita*: There is no mechanism to allow 6OF change priorities. - *Thomas*: Slotframe handle 0 for Minimal and Slotframe 1 for 6OF. - A node SHOULD NOT select cells for the candidate list which overlap with cells scheduled in the minimal slotframe - We RECOMMEND that the length of the OTF slotframe is an integer multiple of the length of the minimal slotframe - *Thomas* creates an issue on the 6top-sublayer draft: remove "(including their number)": - OLD: MUST specify the rule for selecting the cells (including their number) to add to the CellList field in the 6P ADD Request. - NEW: MUST specify the rule for selecting the cells to add to the CellList field in the 6P ADD Request. - MUST specify the rule for verifying which cells from the CellList it can add to it schedule. - go through the candidate list in order. Pick the first NumCells cells which are not used in the current schedule. - MUST specify what to do after an error has occurred - either the node sent a 6P Response with an error code, or received one - RC_SUCCESS but no cells in the CellList of the response: means neighbor receive request, but no cells in the CellList are usable. In that case, retry immediate with a different celllist or a new random set if not enough RAM. - RC_ERR_VER: do not try again, blacklist the neighbor if RAM permits. - RC_ERR_6OFID: do not try again, blacklist the neighbor if RAM permits - RC_ERR_NORESOURCES wait for timeout and retry - RC_ERR_BUSY issue a RESET (new command needed) - SHOULD clearly state the application domain the 6OF is created for. - SF0 is generic, not optimized for particular application. - SHOULD contain examples which highlight normal and error scenarios. - *Nicola* to provide a diagram which shows when/why 3-way handshake is used. - SHOULD contain a performance evaluation of the scheme, possibly through references to external documents. - the SF MUST specify the behavior of a mote when it boots - if the has non-volatile and have a schedule, MUST verify with COUNT and MAY versify or more LIST to verify coherence - if not volatile, MAY do a COUNT, and either issue a CLEAR or ask LIST explicitly - changes to draft-sublayer - RC missing - RC_RESET: sent by receiving node when internal server error - commands missing - CLEAR: remove every cell from me - COUNT: tell me how many cells from me are in your schedule - LIST: ask a neighbor list the cells you have to it. Include an start index. sorted by slotoffset first/channeloffset second - relocation - add a section about the idea of maintaining stats and comparing PDRs between different cells, but leave the threshold as implementation specific - meeting ends at 12.50 PM
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
