Wiki
Clone wikimeetings / 151013_webex_sf0
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 permitsRC_ERR_NORESOURCES
wait for timeout and retryRC_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
- MUST specify an identifier for that 6OF.
- changes to draft-sublayer
- RC missing
- RC_RESET: sent by receiving node when internal server error
- commands missing
CLEAR
: remove every cell from meCOUNT
: tell me how many cells from me are in your scheduleLIST
: ask a neighbor list the cells you have to it. Include an start index. sorted by slotoffset first/channeloffset second
- RC missing
- 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
Updated