Hello Diego: Thanks for this great argumentation. I agree that you are following the 6p design but disagree with that design in the first place.
I see value in a clear layer separation where the TSCH specifics are separated from the bandwidth calculations. We could also see the functional group that is cell dependent and is not covered by 6P as another layer between the 2. That layer should be separated from SF and can be common between multiple SFs Regards, Pascal Le 13 mai 2016 à 19:35, Prof. Diego Dujovne <[email protected]<mailto:[email protected]>> a écrit : Pascal, The question here is who is doing cell accounting. AFAIK, 6P had to guarantee transactions and SF had to do the accounting by directly managing the cells by their identification. This is explained (at least) on the example from Figure 4, section 4.1.1, step 1, on page 6 of the 6top-protocol draft: 1. The SF running on node A selects 3 candidate cells. So the SF decides which are the candidates for the CellList. On the same example, on step 3: 3. The SF running on node B selects 2 of the 3 cells in the CellList of the 6P ADD Request. Node B sends back a 6P Response to node A, indicating the cells it selected. So the SF on the other end selects which of the candidates should be chosen. This process is better explained on section 4.3.6: Adding cells. Now, suppose the SF does the accounting only on the amount of cells per bundle (assuming a bundle is a one-way link against a neighbour) and 6P manages the cell IDs: The conflict here comes from the relocation algorithm, which keeps statistics on individual (and identified) cells to relocate them in case the PDR drops below a certain threshold. According to the 6top-protocol draft, this is a task which corresponds to the SF too. Furthermore, SFs are part of the 6top protocol and not another layer, so there is theoretically no layer violation there. What do you think? Regards, Diego 2016-05-13 12:50 GMT-03:00 Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>: Hell Diego, My point is that a SF should operate on a number of units of transmissions, which happen to be cells in our case. SF should indicate to 6top that there is a need to change for more of less of these units. But the fact that one of these units is mapped to a particular slot offset / channel offset should not be its business. I see it as a layer violation… What if for instance the SF is in the root? Should it really manage down to the cell? Pascal From: Prof. Diego Dujovne [mailto:[email protected]<mailto:[email protected]>] Sent: vendredi 13 mai 2016 17:08 To: Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [6tisch] My adoption-time review of SFO Dear all, During today's webex call, I presented a slide where the comments below were going to be addressed on the next version of the draft. However, I raised the point about: > 4. Rules for CellList Why is this here? Which cell are allocated is not SF0 ‘s business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document. -> This section is recommended by the 6top-protocol draft, and AFAIK it defines which cells are offered and which are selected for allocation. > 7. Node Behavior at Boot Again this is describing 6P not SF0 behavior. Note that the clear should be done at link up in case -> This section is also recommended by the 6top-protocol draft, and it should include any type of pre-configuration and expected initial state on the SF. -> From the comment from Pascal on today's webex: "What if a node has a big storage and it can keep all configuration after a crash?" The SF can use that info to reconstruct all the configuration and recover instead of issuing a clear command. However, there must be a timeout period for recover; if this timeout expires, then all the cells from the crashed node shall be released. Rules for CellList and Node Behaviour at boot are recommended on Sec. 5.3 of draft-ietf-6tisch-6top- protocol-00 2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <[email protected]<mailto:[email protected]>>: Dear authors: Please find my review of the SF0 draft; but since last call is pending please do not make *any* changes till after draft-ietf-*- 00 is published. > This document addresses the requirements for a scheduling function listed in [I-D.wang-6tisch-6top-sublayer<https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>], Section 4.2, and follows the recommended outline from Section 4.3<https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>. I would expect that this doc is the reference for SF and is the one that requests the creation of the SF registry by IANA (text to be added in the IANA section). This reference to sublayer should go away since we are not promoting the draft at the moment – or should we be doing so? > > 3.1. SF0 Triggering Events > > We RECOMMEND SF0 to be triggered at least by the following events: The term ‘We’ is probably inappropriate. Better formulate this like “ It is RECOMMENDED that…” Also shouldn’t there be an event when: - Connectivity to the neighbor is lost. A L3 Link down event should free up resources. The question for 6P is how both sides agree at the same time that the link is down. - A threshold of unused time slots is reached so they should be freed > 6. If the RAB is less than the Minimum Remaining Bandwidth (MRB), Add MRB to the NOB: NOB=NOB+MRB Shouldn’t this be NOB=MRB > 4. Rules for CellList Why is this here? Which cell are allocated is not SF0 ‘s business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document. > 7. Node Behavior at Boot Again this is describing 6P not SF0 behavior. Note that the clear should be done at link up in case > 11. Examples > > TODO > > 12. Implementation Status These sections probably belong to annexes Cheers, Pascal _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl<http://www.ingenieria.udp.cl> (56 2) 676 8125 -- DIEGO DUJOVNE Académico Escuela de Ingeniería en Informática y Telecomunicaciones Facultad de Ingeniería UDP www.ingenieria.udp.cl<http://www.ingenieria.udp.cl> (56 2) 676 8125
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
