[6tisch] Review of draft-ietf-6tisch-6top-protocol-09
Dear all, I have reviewed draft-ietf-6tisch-6top-protocol-09, I have just one remark. The protocol is sub-optimal, requiring additional mechanisms to fix inconsistencies, and being in the end not energy efficient as desired. In figure 4 at page 7, the L2 ACK to the 6P Response is used as the 3rd part into a 3-way negotiation (even though it is identified as 2-way transaction; similar arguments can be reproduced for the 3-way transaction, that should be indeed a 4-way negotiation). This is confirmed by the current implementation of OpenWSN ( https://github.com/openwsn-berkeley/openwsn-fw/blob/develop/openstack/02b-MAChigh/sixtop.c#L924) where one or more cells are added to the schedule of mote B after receiving the L2 ACK. Not sure if this should be called as layer violation, I understand that sometimes cross-layers tricks must be taken into account. However, the point that I see as a possible performance issue, is that the closure of the 3-way negotiation is decided by node B, that has to retransmit a 6P Response until it is correctly acknowledged. *If after all retransmissions the L2 ACK is not received, there will be an inconsistency, as also described in Figure 31 at page 31 of the draft. It is very likely that a L2 ACK would be lost due to the very well understood exposed terminal problem.* This happens in fact when bootstrapping very dense networks, since all transactions will happen simultaneously on the minimal shared cell. *Even though the protocol was intended to be easy and simple, an additional mechanism to deal with inconsistencies and fix them is needed.* Instead, *an option could be to avoid inconsistencies, without then having to make patches by elaborating mechanisms to fix them. *Easily and simply, by enabling the following things (while detailing I am referring to Figure 4 in the draft): 1. Node B schedules RX cells after transmitting the 6p Response and without waiting for the L2 ACK. 2. Node A schedules TX cells after receiving the 6p Response. 3. Node A sends an acknowledgment at 6p layer (6p ACK) after receiving the 6p Response using the new allocated dedicated cells, where the only possibility of collision would be very very unlikely. 4. Node B starts a 6p timeout waiting for the reception of the 6p ACK, if this one has not been received yet, and if the 6p Response has been retransmitted the maximum number of times. When the timeout expires, the RX cells previously allocated (at the previous point 1.) are deleted by node B's schedule. Actually, this timeout will not be activated most of the times, since the 6p ACK would be received just after the first 6p Response received by node B in Figure 31. >From an energy-saving point of view, there are two choices: - (more energy-efficient) sending a single 6p ACK that will avoid node B to retransmit many times the 6p Response if the L2 ACKs were missed. - (less energy-efficient) as in the current draft version, with the energy consumption resulting as the sum of the following: (i) node B retransmitting many times the 6p Response; (ii) node A transmitting packets that will not be received, due to inconsistencies, (iii) new 6p transactions to fix the inconsistencies. Best regards Nicola ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0
Diego, in the end, I guess we agree on this, the REQUIREDCELLS is the output of the bandwidth estimation algorithm, whichever we want to define in the draft. I guess we agree too that this is an estimate. Then it's up to the allocation policy to compare this estimate with what's the state of the system, i.e., SCHEDULEDCELLS, and produce an output (number of cells to add/delete) and a change in the state (SCHEDULEDCELLS will be updated according to REQUIREDCELLS and to SF0THERSH). The overprovision we are talking about depends in the end on some function of the SF0THRESH. One way to compute the output is the one that Tengfei is recalling. We already avoided to write down that thing in the OTF draft (now it is SF0, but the substance of the way of computing the output is always the same), just because we wanted the draft to be more general. For instance: adding/deleting one cell is for sure not optimal, as Tengfei is saying, I agree. Though in most cases, it is what is really needed. The choice to not indicate a specific value for the number of cells to add/delete comes from a tradeoff between point of views. Why are we going back? Or is there something that I'm misunderstanding or missing? Nicola 2016-11-02 17:02 GMT+01:00 Prof. Diego Dujovne : > Nicola, > I answer below. > Regards, > >Diego > > 2016-11-02 12:35 GMT-03:00 Nicola Accettura : > >> Diego, Tengfei, >> >> I'll provide comments to each of you. >> >> @Diego: I believe that the change in the estimation algorithm does not >> change the fact that both OTF and SF0 give as output a number of cells to >> add/delete, and this is the point I'm discussing on. If we agree on this >> simple evidence (OTF and SF0 give as output a number of cells to >> add/delete), I don't see why the reasoning related to the ouput of OTF >> should not apply to the reasoning related to SF0 output. So I don't get >> really your issue. >> > > What I'm saying is that the number of required cells could change when you > measure the requested cells from the application (an assumption no longer > valid) to the number of effectively used cells (which depends on the > aggregate number of effectively used cells by the node itself plus the ones > used by the forwarded traffic from the neighbors on this particular link) > > >> >> @Tengfei: the thing you are talking about (a hint on the number of cells >> to be added/deleted) was not expected neither by 6top nor OTF. In fact, >> what you are proposing was already present as idea in a paper on OTF. Now >> we have 6P and SF0. 6P inherits much from 6TOP. Some of the 6TOP features >> not present in 6P are now under the domain of SF0. SF0 inherits both from >> 6TOP and OTF. So the change from 6TOP,OTF to 6P,SF0 does not imply that SF0 >> has to specify a specific number of cells to be added/deleted. We wanted >> the protocols to be as general as possible. I don't think that writing down >> a specific way of computing the number of cells to be added/deleted would >> help the generality we want to express as standard. >> >> But there could be something else I'm not considering. Please, don't >> hesitate to share here your thoughts. >> > > Nicola, we may suggest a value, without being it mandatory. > > > >> >> Nicola >> >> >> 2016-11-02 16:00 GMT+01:00 Tengfei Chang : >> >>> Hi Nicola, Diego, >>> >>> I see. Thanks for all your explanation! >>> >>> It would be very helpful if we can see some recommended number of cell >>> or advice how to choose the number of cell in the draft. >>> As Sixtop left lots of details in SF, my thought is SF should give more >>> specific information or clues for developer/implementer to implement. >>> Of course, those information will come out from real experiments. >>> >>> Thanks for all you replying! >>> >>> Tengfei >>> >>> >>> On Wed, Nov 2, 2016 at 3:42 PM, Prof. Diego Dujovne < >>> diego.dujo...@mail.udp.cl> wrote: >>> >>>> Nicola, >>>>I agree with your comment, but the cell estimation >>>> algorithm changed: we now estimate the number of required >>>> cells from the number of requested cells (to add or delete) >>>> and the number of effectively used cells. What is still not clear >>>> to me is if the simulation results from the OTF paper is still valid >>>> given this change. To enable the cell estimation algorithm without >>>> packet loss, we need to guarantee always a small amount of >&
Re: [6tisch] [6TISCH] RELOCATE command in sixtop?
Tengfei, all, the idea of relocation is very useful, I agree. A RELOCATE command would require the same reliable process for maintaining the schedule knowledge consistent between both sides of the transaction. Which is in practice identical to that of an ADD command. Maybe it is possible to use the same abstract command to make add/relocate with the same kind of reliable process (request, response). Add and relocate operation have much more in common than a delete command (there is only a one-way packet in that transaction). What do you think? Nicola 2016-11-02 16:09 GMT+01:00 Prof. Diego Dujovne : > Pascal, > The relocation process from SF0 is meant > also to detect collisions after random allocation, among > other sources of packet loss, such as narrowband > interference or noise. > Regards, > > Diego > > 2016-11-02 12:06 GMT-03:00 Pascal Thubert (pthubert) : > >> Hello Tengfei; >> >> >> >> this looks very useful in the context of the minimal cell allocation >> (Xavi’s random appropriation and collision detection). >> >> >> >> Take care, >> >> >> >> Pascal >> >> >> >> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Tengfei >> Chang >> *Sent:* mercredi 2 novembre 2016 15:47 >> *To:* 6tisch@ietf.org >> *Subject:* [6tisch] [6TISCH] RELOCATE command in sixtop? >> >> >> >> All, >> >> >> >> I would like to propose an idea to add a new command called RELOCATE >> command in sixtop. >> >> This RELOCATE sixtop command will contains the cells to be added and >> removed in single packet. >> >> >> >> Without RELOCATE command, the relocation is done through adding one cell >> first then deleting one cell. >> >> With RELOCATE command, once the sixtop transaction for relocation >> successes, the relocation process is done. >> >> >> >> There are several benefit from RELOCATE: >> >> >> >> 1.save overhead of relocation process. >> >> 2. avoid the influence of relocation on SF0. It requires SF0 to take the >> relocation into consideration if the cell is added through relocation or >> not. SF0 may take different decision. >> >> >> >> What do you think? >> >> >> >> Tengfei >> >> >> >> >> >> >> -- >> >> Chang Tengfei, >> >> Pre-Postdoctoral Research Engineer, Inria >> >> ___ >> 6tisch mailing list >> 6tisch@ietf.org >> 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0
Diego, Tengfei, I'll provide comments to each of you. @Diego: I believe that the change in the estimation algorithm does not change the fact that both OTF and SF0 give as output a number of cells to add/delete, and this is the point I'm discussing on. If we agree on this simple evidence (OTF and SF0 give as output a number of cells to add/delete), I don't see why the reasoning related to the ouput of OTF should not apply to the reasoning related to SF0 output. So I don't get really your issue. @Tengfei: the thing you are talking about (a hint on the number of cells to be added/deleted) was not expected neither by 6top nor OTF. In fact, what you are proposing was already present as idea in a paper on OTF. Now we have 6P and SF0. 6P inherits much from 6TOP. Some of the 6TOP features not present in 6P are now under the domain of SF0. SF0 inherits both from 6TOP and OTF. So the change from 6TOP,OTF to 6P,SF0 does not imply that SF0 has to specify a specific number of cells to be added/deleted. We wanted the protocols to be as general as possible. I don't think that writing down a specific way of computing the number of cells to be added/deleted would help the generality we want to express as standard. But there could be something else I'm not considering. Please, don't hesitate to share here your thoughts. Nicola 2016-11-02 16:00 GMT+01:00 Tengfei Chang : > Hi Nicola, Diego, > > I see. Thanks for all your explanation! > > It would be very helpful if we can see some recommended number of cell or > advice how to choose the number of cell in the draft. > As Sixtop left lots of details in SF, my thought is SF should give more > specific information or clues for developer/implementer to implement. > Of course, those information will come out from real experiments. > > Thanks for all you replying! > > Tengfei > > > On Wed, Nov 2, 2016 at 3:42 PM, Prof. Diego Dujovne < > diego.dujo...@mail.udp.cl> wrote: > >> Nicola, >>I agree with your comment, but the cell estimation >> algorithm changed: we now estimate the number of required >> cells from the number of requested cells (to add or delete) >> and the number of effectively used cells. What is still not clear >> to me is if the simulation results from the OTF paper is still valid >> given this change. To enable the cell estimation algorithm without >> packet loss, we need to guarantee always a small amount of >> overprovisioning. >> Let me bring the lost text (from OTF) back to SF0. >> Regards, >> >> Diego >> >> 2016-11-02 11:36 GMT-03:00 Nicola Accettura : >> >>> Hi Tengei, >>> >>> the problem you are rising is that you would like to see a number of >>> cells to add/delete when comparing required and deleted cells. >>> >>> The ancestor of SF0, namely OTF, used to specify the following sentence: >>> >>> The number of soft cells to be scheduled/deleted for bundle resizing >>>is out of the scope of this document and implementation-dependant. >>> >>> In fact, we wanted to let that choice being implementation specific. >>> >>> What you are proposing (the exact number of cells to add or delete) was >>> already implemented in the 6tisch simulator, and it is in fact something >>> that has already been used and tested in the following papers: >>> >>> Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless >>> Industrial Networks, IEEE Sensors Journal, 2015 >>> >>> Muraoka et al., Simple Distributed Scheduling with Collision Detection >>> in TSCH Networks, IEEE Sensors Journal, 2016 >>> >>> But, as already said, this is just a way you can allocate cells. I guess >>> we don't want to restrict that setting to a particular algorithm choice. >>> >>> Hope this helps. >>> >>> Nicola >>> >>> 2016-11-02 14:59 GMT+01:00 Tengfei Chang : >>> >>>> Hi All, >>>> >>>> I am reading the SF0-02 version which is just released few days ago. >>>> >>>> In the SF0 Allocation Policy section, the policy said >>>> >>>>1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more >>>>cells. >>>>2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do >>>>nothing. >>>>3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. >>>> >>>> >>>> >>>> Personally thinking, add/delete one cells may call the six
Re: [6tisch] [6TISCH] Specify the number of cells to be added or deleted in SF0
Hi Tengei, the problem you are rising is that you would like to see a number of cells to add/delete when comparing required and deleted cells. The ancestor of SF0, namely OTF, used to specify the following sentence: The number of soft cells to be scheduled/deleted for bundle resizing is out of the scope of this document and implementation-dependant. In fact, we wanted to let that choice being implementation specific. What you are proposing (the exact number of cells to add or delete) was already implemented in the 6tisch simulator, and it is in fact something that has already been used and tested in the following papers: Palattella et al., On-the-Fly Bandwidth Reservation for 6TiSCH Wireless Industrial Networks, IEEE Sensors Journal, 2015 Muraoka et al., Simple Distributed Scheduling with Collision Detection in TSCH Networks, IEEE Sensors Journal, 2016 But, as already said, this is just a way you can allocate cells. I guess we don't want to restrict that setting to a particular algorithm choice. Hope this helps. Nicola 2016-11-02 14:59 GMT+01:00 Tengfei Chang : > Hi All, > > I am reading the SF0-02 version which is just released few days ago. > > In the SF0 Allocation Policy section, the policy said > >1. If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more >cells. >2. If (SCHEDULEDCELLS-SF0THRESH)<=REQUIREDCELLS<=SCHEDULEDCELLS, do >nothing. >3. If SCHEDULEDCELLS<=REQUIREDCELLS, add one or more cells. > > > > Personally thinking, add/delete one cells may call the sixtop many times > which is not efficiency, add/delete more cells is not clear to the > implementer. > I guess there is a decision to say when to add one cell and when to add > more cells. But I didn't find it in SF0 draft. > Is there any reason why we doesn't say specific number of cells? > > If no, I think we can add/remove the number of cells to make sure the > scheduled cells equals to the required cells plus half of SF0THRESH, which > will help stabilize a little bit of the SF0, in case the sixtop is calling > too often. > > Which means: if SCHEDULEDCELLS<=REQUIREDCELLS: > > 1. when there is no cell in the schedule add one cell > 2. when there is at least one cell in schedule, add > REQUIREDCELLS-SCHEDULEDCELLS+(SF0THRESH+1)/2 number of cells > > if REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH)) > > 1. When required cells equals 0, remove all cells but keep one in schedule > 2. when required cells is greater than 0, remove SCHEDULEDCELLS- > REQUIREDCELLS-(SF0THRESH+1)/2 > > Does this make sense? > > Tengfei > > -- > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SF Timeout calculation (Ticket #53)
Diego, from what I saw it does not help. That is a way to associate requests to responses in the transaction. If the timeout expires on A, a response arriving out of time will not be considered. If the 6P response from B to A is out of time for A, that response should be immediately trashed: the cells to be allocated listed in the 6P response could have been allocated to other neighbors by A. Nicola 2016-10-31 23:18 GMT+01:00 Prof. Diego Dujovne : > Nicola, >One recent inconsistency check on 6P is the > Schedule Generation, defined on the 6top protocol > draft on: > > 4.3.11. Generation Management > > section. Maybe this helps reducing the inconsistency > you are mentioning without increasing the timeout. > Regards, > > Diego > > > 2016-10-31 19:09 GMT-03:00 Nicola Accettura : > >> Qin, Diego, >> >> I'll try to explain better my point of view. >> >> Referring to the very helpful scheme that Qin presented, I would say that >> time between t3 and t5 will happen almost instantaneously with respect to >> the timeslot duration, since those are operations triggered by the correct >> reception of an ADD request by node B. >> >> The problem stands out in calculating the time between t5 and t6, this is >> the timeout calculation we should focus on. Since the time between t3 and >> t5 is very small, it does not change the following reasoning to say that we >> want to compute the timeout as function of [t3...t6]. So, my point of view >> starts by the same premises as Diego's. >> >> What I'm worried about is the value to assign to this timeout. Let's >> forget by now about the 6P ACK (maybe it's better to open another thread >> for that later). >> >> I guess that the aim is that we don't want the ADD response to arrive >> when the timeout is expired. >> >> If the ADD response arrives after the timeout, the MAC frame containing >> the 6P ADD response will be acked anyway. This will produce a disagreement >> on the scheduled cells between A and B. Node A, although it received the 6P >> ADD answer, it will consider that answer out of time and it will not add >> any TX cell. At the same time, node B will add RX cells, because it was >> acknowledged by A for the correct delivery of the 6P ADD response. Node A, >> since it feels not satisfied (still no allocated cells), will continue >> asking for new cells to B. Cells available will terminate very quickly on B >> if there are many motes competing to get bandwidth to B. >> >> This happens if the timeout is shorter than the unpredictable time we >> want to estimate. >> >> If the timeout is long enough for containing the maximum of that >> unppredictable time, i.e., the time interval [t3...t6], the 6P ADD answer >> will always arrive while node A is waiting for the answer. If it does not >> arrive in this maximum time, it will never arrive. >> >> Let's evaluate that maximum. Timeslot long 10 ms, slotframe 101 >> timeslots, maxRetries 3. As in Qin example. There is also the first try, so >> TXATTEMPTS = maxRetries + 1 = 4. >> >> Each try to send a packet happens randomly in the current backoff >> interval. In the worst case, the backoff time is chosen in the biggest >> backoff interval [0, 2^macMaxBE - 1]. In the really worst case, node B will >> choose to transmit in 2^macMaxBE shared cells. If macMaxBE is 4 (as in >> OpenWSN, but 7 according to the IEEE802.15.4e standard), the time to >> transmit the packet just the first time could be in 2^4 = 16 shared slots. >> In other words, if there is only one shared cell, according to 'minimal', >> that time will be around 16 seconds. This is the worst case, I know, but we >> want to be sure that timeout does not expire before the actual time that >> node B can take to ship the ADD response to A. >> >> 16 seconds is just the time for sending a packet. That must be multiplied >> by TXATTEMPTS = 4. So the timeout should be more than 1 minute long. If it >> expires and node A has not received the 6P ADD response, it means that it >> won't receive that 6P ADD response later, and, as a consequence, there will >> be no inconsistency. >> >> The formula that I have in mind for the timeout calculation is: >> >> timeout = 2^macMaxBE * TXATTEMPT [# executed shared cells] >> >> and I would let the unity of measure be the number of shared cells. In >> other words, if timeout comes to be 64, this means that the timeout will >> expire just after the 64th shared cell. >> >> I'm
Re: [6tisch] SF Timeout calculation (Ticket #53)
Diego, defining priorities about the management of packets is implementation specific, I guess. But I can be wrong. To be honest, from what I saw in practical implementations, the best is to give the highest priority to 6P packets both on shared and dedicated cells, because they are in charge to enlarge/reduce bandwidth starting from 'minimal'. Data will be always be created and, if you don't give priority to 6P negotiations, they will quickly fill up queues while congesting the small bandwidth available. Data must be able to travel only if the network is sufficiently capable - if there are dedicated cells. To get dedicated cells you need first 6P negotiations. If the network has sufficient bandwith (dedicated cells have been allocated very quickly), data will use the average bandwidth and there will not be many negotiations. I know it's counter-intuitive: if you give more priority to 6P packets you will in fact allow data to stay very comfortable in the dedicated cells allocated. Nicola 2016-10-31 20:48 GMT+01:00 Prof. Diego Dujovne : > Nicola, > I would try to focus on the draft, however, let me answer > briefly > the shared/dedicated point of view below. > Regards, > >Diego > > 2016-10-31 15:18 GMT-03:00 Nicola Accettura : > >> Hi Diego, >> >> thank you for your answer too. >> >> However there are two points I would like to point out. >> >> First, the mac-layer ack is in fact the TSCH ack, that travels on the air >> during the same timeslot of the data packet. It is sent if the data packet >> is unicast, either on shared or on dedicated cells. The 6P ACK I'm >> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it >> requires its own TSCH ack from B to A. >> > > First, I do not expect packets which are not Unicast during a negotiation. > What the SF needs to calculate the > timeout is any type of signalling confirming that the A->B request packet > has arrived to B. If this signal is > a different packet, it will take longer to arrive, but its meaning is not > different from what we need to start the timeout countdown. > So, if there is no time during the timeslot to bring upstream (to the SF) > the MAC ACK, then, it will do it in the next transmission opportunity, > which may happen in the next available slot. But the timeout countdown will > not start until that event happens. > In the way back, (the request response from B to A) there will be a MAC > ACK too, which will be in turn brought upstream (to the SF) in the same way > as it was brought the request from A to B, if there is no time in the > current timeslot, it will be done during the next transmission opportunity. > > >> >> Second, I'm totally not aligned on "...dedicated cells are for data and >> shared cells for any kind of signalling and/or negotiation." and I believe >> this is not the distinction between those types of cells. >> >> Shared or dedicated cells can be used either for signaling and/or data. >> > > I understand your point on the flexibility to use any of them for > different purposes, but I would prioritize higher reliability (dedicated > cells) for data, while leaving negotiations for shared cells. As a matter > of fact, 6P now allows SFs to allocate either type of cells. > > >> >> 'Minimal'. as an example, has got a single shared cell. One can run >> minimal without any other more sophisticated scheduling technique just >> using that shared cell for both signaling and data. The same is possible if >> someone uses a dynamic schedule and uses also dedicated cells. I don't see >> any reason for forbidding dedicated cells to vehiculate both signaling and >> data. The difference is that in shared cells there's contention. >> > > I see that a balance on the schedule is needed to address both > scalability and reliability. You can base your whole scheduling on shared > or dedicated cells, it is up to the SF now to decide where to expand and to > decide which type of traffic goes where. Before, there was the assumption > of having only a single best-effort track. Now we have two type of cells to > decide on at the SF. It is not specified yet on the SF0 draft, but a > decision on this matter must be taken. > > >> >> I would add that it could be possible to piggyback 6P signaling with data >> from upper layers, if there is space in the MTU. It is the encapsulation >> that makes the distinction between data and 6P signaling. Data go >> encapsulated within the IEEE802.15.4e packet payload, while 6P goes into >> the payload IEs, and these two payloads can coexist in the
Re: [6tisch] SF Timeout calculation (Ticket #53)
B SF0 processes ADD Request >> t5: Node B 6top prepares ADD Response >> t6: Node B 6top sends out ADD Response, ending with MAC-ACK success >> t7: Node A 6top processes ADD Response. >> t8: Node A 6top sends out 6P ACK, ending with MAC-ACK success >> t9: Node B 6top processes 6P ACK >> >> According to my understanding, the most unpredictable time is t2, t6 and >> t8, because they are associated with Retry and the length of slotframe. >> Assume slot duration is 10ms and slotframe length is 101, maxRetry is 3, >> then, t2 and t6 could be 3 seconds, and t8 could be 3 seconds also if >> Shared cell is used. >> >> (1) Current scheme. Timeout starts when SF0 on node A issues command to >> 6top to ask ADD cells. Then the value of Timeout is function of (t1,..t7) >> (2) Diego's scheme. Timeout starts when SF0 on node A gets MAC-ACK >> success from 6top. Then the value of Timeout is function of (t3,..t7) >> (3) Nicola's scheme. (I'm not sure the formula to calculate the value of >> Timeout. But my feeling is each Timeout has to include at least one long >> and unpredictable Time, i.e. t2, or t6, Nicola: would you please add it?) >> >> Comparing (1) and (2), I agree that (2) is much better than (1), because >> (2) does not take t2 into account in (2), reducing almost half of >> uncertainty. >> >> I haven't figured out the advantage of (3) over (2). Nicola, would you >> please give me your explanation? >> >> Thanks >> Qin >> >> >> >> On Monday, October 31, 2016 2:18 PM, Nicola Accettura < >> nick.accett...@gmail.com> wrote: >> >> >> Hi Diego, >> >> thank you for your answer too. >> >> However there are two points I would like to point out. >> >> First, the mac-layer ack is in fact the TSCH ack, that travels on the air >> during the same timeslot of the data packet. It is sent if the data packet >> is unicast, either on shared or on dedicated cells. The 6P ACK I'm >> proposing is NOT a TSCH ack, it is a data packet sent from A to B and it >> requires its own TSCH ack from B to A. >> >> Second, I'm totally not aligned on "...dedicated cells are for data and >> shared cells for any kind of signalling and/or negotiation." and I believe >> this is not the distinction between those types of cells. >> >> Shared or dedicated cells can be used either for signaling and/or data. >> >> 'Minimal'. as an example, has got a single shared cell. One can run >> minimal without any other more sophisticated scheduling technique just >> using that shared cell for both signaling and data. The same is possible if >> someone uses a dynamic schedule and uses also dedicated cells. I don't see >> any reason for forbidding dedicated cells to vehiculate both signaling and >> data. The difference is that in shared cells there's contention. >> >> I would add that it could be possible to piggyback 6P signaling with data >> from upper layers, if there is space in the MTU. It is the encapsulation >> that makes the distinction between data and 6P signaling. Data go >> encapsulated within the IEEE802.15.4e packet payload, while 6P goes into >> the payload IEs, and these two payloads can coexist in the same >> IEEE802.15.4e frame. >> >> Thoughts? >> >> >> Nicola >> >> >> >> > > > -- > 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SF Timeout calculation (Ticket #53)
Hi Diego, thank you for your answer too. However there are two points I would like to point out. First, the mac-layer ack is in fact the TSCH ack, that travels on the air during the same timeslot of the data packet. It is sent if the data packet is unicast, either on shared or on dedicated cells. The 6P ACK I'm proposing is NOT a TSCH ack, it is a data packet sent from A to B and it requires its own TSCH ack from B to A. Second, I'm totally not aligned on "...dedicated cells are for data and shared cells for any kind of signalling and/or negotiation." and I believe this is not the distinction between those types of cells. Shared or dedicated cells can be used either for signaling and/or data. 'Minimal'. as an example, has got a single shared cell. One can run minimal without any other more sophisticated scheduling technique just using that shared cell for both signaling and data. The same is possible if someone uses a dynamic schedule and uses also dedicated cells. I don't see any reason for forbidding dedicated cells to vehiculate both signaling and data. The difference is that in shared cells there's contention. I would add that it could be possible to piggyback 6P signaling with data from upper layers, if there is space in the MTU. It is the encapsulation that makes the distinction between data and 6P signaling. Data go encapsulated within the IEEE802.15.4e packet payload, while 6P goes into the payload IEs, and these two payloads can coexist in the same IEEE802.15.4e frame. Thoughts? Nicola ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] SF Timeout calculation (Ticket #53)
Hi Qin, I'm very happy for your feedback. I was just considering the transaction as a 6P one, you have bettered off that by introducing also the relationship between 6P and SF0 in each part of the transaction. This is perfect now! Actually I did not propose to delete the timeout. I perfectly agree with you in saying that we need timeouts to preserve the system from Failed transactions. I was proposing instead to have a timeout on both sides of the transaction, but shorter than the one that would be required if the transaction was 2-way: 1. node A will start the timeout after receiving the mac-layer ack from node B for the ADD request: if node A receives an ADD response from B during the timeout window, the transaction will continue, otherwise, the transaction is considered as failed 2. node B will start the timeout after receiving the mac-layer ack from node A for the ADD response: if node B receives a 6P ACK from A during the timeout window, the transaction will continue, otherwise, the transaction is considered failed Please, note that, if A received the ADD response in the 'minimal' shared cell and the dedicated TX cells are allocated just after that reception, the 6P ACK will be sent during the same slotframe in the first dedicated TX cell. Just speaking about possible extensions for more complex uses: the 6P ACK could also hold a flag to declare it as a NACK. If the timeout on node A was expired, and it received a 6P answer out of time by B, it can send back a NACK to let B stop its own timeout and let it delete the RX cells previously half-opened. What do you think? Nicola 2016-10-31 16:20 GMT+01:00 Qin Wang : > Hi Nicola, > > I want to confirm my understanding first. > > Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into > a transaction, then the sequence of a original 2-way ADD transaction will > be: > (1) node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD > request to nodeB > (2) node B 6top layer receives ADD Request, SF0 sets "adding RX cells" > OPEN, and 6top layer sends ADD Response to node A > (3) node A 6top layer receives ADD Response, SF0 adds TX cells and sets > "adding TX cells" CLOSED, and 6top layer sends 6P ACK to node B > (4) node B 6top layer receives 6P ACK, SF0 adds RX cells and sets "adding > RX cells" CLOSE. > > Is my understanding correct? In addition, the proposed scheme will not > need Timeout. Is it what you mean? > > But, I still think the scheme can not avoid a Timeout. Otherwise, how node > A or node B can stop a Failed transaction if something happens? > > Thanks > Qin > > > > On Saturday, October 29, 2016 2:18 PM, Nicola Accettura < > nick.accett...@gmail.com> wrote: > > > Diego, all, > > the timeout obviously must start when the ack is received. I agree in > total. > > Though, you still need to get the timeout proportional to TXATTEMPTS and > also to the maximum backoff window. Why? > > Call A the node that is requesting cells, and B the node that is asked for > cells. Node A sends a request and gets a mac layer ack from B. A starts the > timeout. B sends a packet, but it's lost. Sends another packet and it is > lost... until the last attempt which is successful: B gets a link layer ack > from A. So B allocates cells as RX. > > This confirms that the timeout should be proportional to TXATTEMPTS. And > to the maxium backoff window. If there is only one shared cell, according > to 'minimal', the timeout is proportional also to the slotframesize. If > some implementation considers more than one shared cell per slotframe, the > timeout can be smaller. At this point, I would say that the unity of > measure of the timeout should be the number of executed shared cells, so > that the timeout can be safely be proportional just to the product of > TXATTEMPTS and the maximum backoff window. > > Yes, this causes to have a very long timeout, with possible (and actually > frequent) desynchronizations. Especially when the network is forming, all > nodes will ask for dedicated cells, many 6P packets will get lost. > Keepalives will be triggered, but this worsen the situation. Everything is > very very bad. > > Is that possible to have a shorter timeout? > > My answer is 'yes'. But we need something else: a 6P ACK. > > In fact, assume that A sent a request, B acked at MAC layer. Then B (maybe > after many tries, if the responses have been lost, and this is possible in > the 'minimal' shared cell due to collisions in big networks) is finally > able to send an answer that is correctly received by A and A sends an ack > at mac layer. B adds cells as RX and expects A to open the same cells as > TX. > > 'Go
Re: [6tisch] SF Timeout calculation (Ticket #53)
Diego, all, the timeout obviously must start when the ack is received. I agree in total. Though, you still need to get the timeout proportional to TXATTEMPTS and also to the maximum backoff window. Why? Call A the node that is requesting cells, and B the node that is asked for cells. Node A sends a request and gets a mac layer ack from B. A starts the timeout. B sends a packet, but it's lost. Sends another packet and it is lost... until the last attempt which is successful: B gets a link layer ack from A. So B allocates cells as RX. This confirms that the timeout should be proportional to TXATTEMPTS. And to the maxium backoff window. If there is only one shared cell, according to 'minimal', the timeout is proportional also to the slotframesize. If some implementation considers more than one shared cell per slotframe, the timeout can be smaller. At this point, I would say that the unity of measure of the timeout should be the number of executed shared cells, so that the timeout can be safely be proportional just to the product of TXATTEMPTS and the maximum backoff window. Yes, this causes to have a very long timeout, with possible (and actually frequent) desynchronizations. Especially when the network is forming, all nodes will ask for dedicated cells, many 6P packets will get lost. Keepalives will be triggered, but this worsen the situation. Everything is very very bad. Is that possible to have a shorter timeout? My answer is 'yes'. But we need something else: a 6P ACK. In fact, assume that A sent a request, B acked at MAC layer. Then B (maybe after many tries, if the responses have been lost, and this is possible in the 'minimal' shared cell due to collisions in big networks) is finally able to send an answer that is correctly received by A and A sends an ack at mac layer. B adds cells as RX and expects A to open the same cells as TX. 'Good!' one would say. Wrong! Node A has acknowledged at MAC layer the correct reception of the answer by B but will process the 6P packet after that. If the timeout is too short, that packet will be considered out of time. And the TX cells will not be allocated. With some RX cells open on node B. One can think of a timeout to garbage collect on B. But I'm not sure this would be very efficient, there's the probability of false positive. A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX side after receiving the mac layer ack from A. A will open the TX side after sending the mac layer ack, it the 6P response was in time. It will send the 6P ack possibly in the newly created dedicated cell, so decongesting the shared cell of 'minimal'. If B receives the 6P ack, it will be sure that the RX side is open completely without possible impairment with the node A schedule knowledge. Instead, if the 6P response was out of time, A will not send any 6P ack, will not open the TX side. B will not receive any 6P ack within a timeout (that can be the same length as that starting on the A side after the reception of the mac layer ack to the request packet) and when that expires will delete the RX cells that were 'half' opened. With this, it is not possible to get suspicious cells allocations on the RX side. There's still the possibility that a TX side is open with the RX side not open. But for that, 6P or SF will manage a relocation. Think about the 6P packet as the third part of a 3-way-handshake. Of course, it's obvious that I'm strongly in favor of a 6P ack definition, more than having a big timeout. Does it make sense? Nicola 2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne : > Dear all, >Yesterday, we had a discussion about ticket #53 > from the issue tracker, on the way to calculate the > SF0 timeout value. >There is current a proposal to calculate the timeout > on SF0 between the arrival of the MAC-layer ACK for the > request packet and the arrival of the response packet. > In order to achieve this calculation, the 6P protocol must > signal the arrival of the request ACK packet so as to start > the timer countdown. >Using this method, we avoid very long timeouts set > to the max value of the number of TXATTEMPTS and the > maximum backoff value. > Graphically: > > SF|REQUEST| |timer-|RESPONSE| > ^ > 6P |REQUEST| | |RESPONSE| > MAC LAYER |REQUEST| |ACK||RESPONSE| |ACK| > > I would like to know if your thougthts about this idea. > Thank you. > Regards, > > Diego > > -- > 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/list
Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly
Maria Rita, I've got a single additional comment, you can find it inline. Nicola 2015-07-02 3:57 GMT-07:00 Thomas Watteyne : > Comment inline. > > On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA < > maria-rita.palatte...@uni.lu> wrote: > >> Hi all, >> >> I have reviewed the last version(v5) of the OTF draft. >> >> >> >> The draft mainly looks good, but I have some “almost” minor comments. >> >> >> >> I think there is an inconsistence to be fixed. >> >> In the abstract and at pag. 4 we state that OTF (and the allocation >> policy) determines/decides WHEN to reserve/delete soft cells in the >> schedule. >> >> But in sec. 2, pag. 3, we state that the algorithm which decides WHEN to >> add/delete soft cells is out of scope. >> >> I think this last sentence isn’t correct, because OTF actually determines >> WHEN, based on the values of the thresholds. What is not defined, and out >> of scope, is the actual NUMBER of cells to be added or deleted. >> >> Am I wrong? >> > You are right, there is an inconsistency in the terms used. I'll give an interpretation of what the text means. WHEN is OTF triggered? It depends on the triggering event, which is implementation-dependant and out of scope (e.g., on a buffer overflow, or periodically, or every X packets received). The sentence on page 3 sec. 2 that you point out, I guess, referes to the triggering event. Once triggered, OTF decides IF adding/deleting cells. In this sense, "when" stands for "if" in the abstract and in the other sentences referring to the outcome of OTF. Does it make sense? We have to clarify in the text, I agree. > >> >> Another thing to be clarified is the allocation of cells on the best >> effort L3 bundle. >> >> Actually, when we talk of a L3 track, and we look at the bandwidth on a >> L3 link, between two neighbors, we have 2 bundles associated to that link, >> one incoming, and one outgoing. >> >> When we add cells, are we referring to the INCOMING bundle, or are we >> supposed to add the cells on both bundles? Pascal? How does it work? >> > > I believe a node only worries about scheduling cells TO its neighbor, > and that cells are NOT bidirection. Of course, a node will receive requests > from it neighbor (for incoming cells), but doesn't trigger those. > > >> I was also wondering that it may be useful in the future do add a 6top >> command that allows to “FREE” a cell. Instead of deleting cells from the >> best effort track. >> >> In fact, if we check the scheduled BWD per L2 track, then it may happen >> that we don’t need cells for the traffic on that track, but we may need it >> for other tracks, using the same L3 link. >> >> In that case, I wouldn’t delete the cells from the L3 bundle. >> > > I'm afraid I don't catch the subtlety here. I would just add/delete > cells and not try to recycle them. Seems like a complicated optimization > with no clear quantified benefits. > > >> In line with this, I think we should plan to work on how OTF will deal >> with L2 tracks, and also with chunks appropriation. But now it is too short >> for this IETF meeting, we may discuss while we are there. >> > > Agreed, probably a point to raise during the WG meeting? > > >> Moreover, I think in sec. 7, when we define the (default) bandwidth >> estimation algorithm, as we did for the description of the events, we >> should make clear the link with the OTF allocation policy, and thus, >> between incoming, outgoing traffic, scheduled cells, reserved cells, etc. >> >> In the way it is described, it is not straightforward to understand such >> link. >> >> >> >> Here are some editorial changes: >> >> >> >> Legend **xx** -> ADD **X** -> delete >> >> >> >> 1) Check if best effort track is identified by TrackID = 00, or = >> NULLT >> >> 2) In OTFTHRESHLOW/HIGH definition -> out of **OTF** scope >> >> 3) Fig. 1 label: …. For triggering **6top** add/remove **soft >> cell** command >> >> 4) When both OTFTHRESHLOW and OTFTHRESHHIGH **are** equal **to** >> 0, any discrepancy ……. >> >> 5) Other values for the thresholds **values** **, different from >> 0,** reduce the number of triggered 6top negotiations. >> >> 6) Sec 6, before listing the parameters: ** We define the >> following parameters:** >> >> 7) Sec. 7, **The steps of the ** default bandwidth estimation >> algorithm, running over a parent node, **are listed hereafter:** >> >> 8) Reference to be fixed: I-D.ietf-6TiSCH-tsch -> now RFC7554 >> >> >> >> Please note that my review doesn’t take into account the last discussion >> on the ML about the draft. I need to couch up with the emails. Thanks! >> >> >> >> Maria Rita >> >> >> >> >> >> ___ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > _
Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
Qin, Michel, I also prefer option (2). This feature can be considered as a faster negotiation addressing "emergencies". Usually a negotiation will require two cells (1 for reservation request, 1 for reservation response). Let's call this as DEFAULT_NEGOTIATION. In the "emergency" case, we have a single cell used. I guess a single cell would be reserved, there is not enough room in the ack. Let's call this as EMERGENCY_NEGOTIATION. Actually, I think that an in-band reservation should be possible also for the DEFAULT_NEGOTIATION: a data packet is encapsulated in a 6top packet, with 6top possibly carrying the IEs related to a reservation request. IEs will be processed at the 6top layer, the payload will be dispatched to upper layers on the receiver side. Then, node B will send a reservation response to node A within another cell (in case, with the same piggybacking approach, if there is a cell from B to A and a data packet to be sent in that direction). This possibility for the DEFAULT_NEGOTIATION could save energy, since a single packet will be able to address 6top needs and deliver data packets. I point out again that this could be an option working when there is enough room in the packet to accomodate both data and 6top IEs. When there is no room for 6top IEs in packets carrying data (data occupies most of the frame space), the 6top IEs will be sent in a following dedicated packet, as in the current 6top drafts. For the EMERGENCY_NEGOTIATION, piggybacking 6top IEs with data packet is the sole option available. As you point out, the Frame Pending bit does not mean that there is an "emergency", so if node A sends a data packet to node B with the Frame Pending set and with a 6top reservation request, there is no way to discriminate if this would be a DEFAULT_NEGOTIATION or an EMERGENCY_NEGOTIATION. My question is: would that be possible to have a 6top flag bit indicating EMERGENCY_NEGOTIATION? I would also say that the reservation request IEs for softcells could be significantly reduced in size. Node A could send a subset of available timeslots (note, I'm not talking about cells), maybe in the form: starttimeslot3-endtimeslot7, starttimeslot15-endtimeslot25, meaning that timeslots 3,4,5,6,7,15,16,17,18,19,20,21,22,23,24,25 are available in its own schedule (only 2*4b ytes needed). Node A will also indicate the number of cells required, e.g. 3. Node B will answer with 3 cells: timeslot4 on channeloffset3, timeslot5 on channeloffset 10, timeslot20 on channeloffset5. In many cases the node starting a negotiation (node A) won't have to specify a preferred channel offset for each proposed timeslot (maybe will specify only a single channel offset for all timeslots proposed). This possibility would save a lot of space in the reservation request. You wrote also: "The remained issue for both of the schemes is if the time for nodeB to insert the softcell request response IE into ACK frame is too tight or not. I don't have clear answer to it." This is a very good point we need to verify. What do you think? Nicola 2015-07-01 13:17 GMT-07:00 Qin Wang : > Michel and Nicola, > > Firstly, I agree It could be a good idea to let DATA/ACK frames carry > softcell negotiation information, and agree it belongs to 6top-to-6top > negotiation procedure, instead of OTF. > > Secondly, I would like to compare the two following schemes to implement > the idea. > > (1) nodeA sends a data frame to nodeB with Frame Pending setting; nodeB > reply a ACK frame, with a softcell request response IE to give nodeA > additional softcell to send its following data frame. > > (2) nodeA send a data frame to nodeB, in which a softcell request IE is > carried; nodeB reply a ACK frame, with a softcell request response IE to > give nodeA additional softcell to send its following data frame. > > I prefer scheme (2) although it costs more bits of softcell request IE > from nodeA to nodeB, because Frame Pending bit belongs to MAC layer, it > indicates there is more data following, not necessarily more bandwidth will > be needed. > > The remained issue for both of the schemes is if the time for nodeB to > insert the softcell request response IE into ACK frame is too tight or not. > I don't have clear answer to it. > > What do you think? > > Thanks > Qin > > > On Thursday, July 2, 2015 2:05 AM, Nicola Accettura < > nick.accett...@gmail.com> wrote: > > > Qin, > you are pointing out that the bandwidth must be already provided if one > wants to use the Frame Pending setting. This is what we have discussed in > the past and is the state of the art in 6tisch. > > Michele is proposing to use the Frame Pending jointly with a temporary > cell reservation in the ACK. > > I guess this is not in the scope of OTF, but, in case, in that of >
Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
Qin, you are pointing out that the bandwidth must be already provided if one wants to use the Frame Pending setting. This is what we have discussed in the past and is the state of the art in 6tisch. Michele is proposing to use the Frame Pending jointly with a temporary cell reservation in the ACK. I guess this is not in the scope of OTF, but, in case, in that of 6top-to-6top. Why? Currently 6top-to-6top could be used for allocating cells through a negotiation: 1. mote A sends a reservation request to mote B in a cell, and that signaling packet is unicast, so acknowledged in the same cell by B 2. mote B answers A with a reservation response in a following cell, which is also a unicast packet acnowledged in that same cell Michel is saying: 1. mote A sends a Frame Pending to B in a cell, and B sends the ack to A in the same cell answering with a temporary allocation So, Michel's proposal uses 1 cell to perform the negotiation that 6top does (in the current version) by using 2 cells. I guess this is the reason for defining this approach reactive. At the same time, the current 6top negotiation allows to exchange more information for reserving a common available cell. In Michel's approach I figure out many cases of failures: what happens if the temporary cell given by B to A was already busy in A (it was already part of the A's schedule, but with another neighbor, say C)? I guess A will not be able to free its memory, so leading to congestion. Right? Nicola 2015-07-01 10:09 GMT-07:00 Michel Veillette < michel.veille...@trilliantinc.com>: > Hi Qin > > > > Yes, the Frame Pending flag is defined as follow: > > > > IEEE 802.15.4-2006 section 7.2.1.1.3 > > “Frame Pending subfield is 1 bit in length and shall be set to one if the > device sending the frame has more data for the recipient. This subfield > shall be set to zero otherwise” > > > > This feature can be especially useful for the upstream traffic in a RPL > DODAG. In a scenario where a DAG parent have dozens of children, dedicated > timeslot will be infrequent and share timeslots suffer from contention. If > a subset of these children have ongoing traffic, the parent can use the > Frame Pending flag information to schedule temporary soft cells and avoid > contention or speedup transfer. > > > > > > [image: cid:image001.jpg@01C868D8.BF0BB7E0] > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veille...@trilliantinc.com > > www.trilliantinc.com > > > > > > *From:* Qin Wang [mailto:qinwang6...@yahoo.com] > *Sent:* 1 juillet 2015 11:28 > *To:* Nicola Accettura; Michel Veillette > *Cc:* 6tisch@ietf.org; diego.dujo...@mail.udp.cl > *Subject:* Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05 > > > > Hi Michel and Nicola, > > > > I think Michel's idea is interesting. But, according to my understanding, > the Frame Pending setting just means there is frame following, does not > mean that the current bandwidth provided by TSCH schedule, including hard > cells and soft cells, is not enough to convey those frames, and then needs > more bandwidth (e.g. additional soft cells) . Right? Do I miss something? > > > > Thanks > > Qin > > > > > > On Wednesday, July 1, 2015 4:03 AM, Nicola Accettura < > nick.accett...@gmail.com> wrote: > > > > Hi Michel, > > your proposal is very interesting. > > However, OTF does not allocate cells directly: it just computes the > estimated number of cells to add or delete into the schedule, and then > sends this information to 6top. 6top is then in charge of negotiating cells > among neighbors, and meybe perform the scheme you are proposing. > > So, your proposal seems fitting more the 6top-to-6top communication. > > Am I missing something? What others think about? > > Sincerely > > Nicola > > > > 2015-06-30 8:13 GMT-07:00 Michel Veillette < > michel.veille...@trilliantinc.com>: > > Hi Diego > > > > It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not > completely done yet) and I wandering if the concept of on the fly, in a > single exchange, temporary allocation of a soft cell have already been > discussed. For example, a node can use the Frame Pending subfield (IEEE > 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready > to be transmitted. Based on that knowledge, the target may add an IE in an > enhanced acknowledgment to allocate a temporary soft cell (e.g. single > cell). Each subsequent transmission may further re-allocate a temporary > soft cell. It’s important to note that the default delay for a TSCH > Acknowledgment is 1ms (macTsT
Re: [6tisch] draft-dujovne-6tisch-on-the-fly-05
Hi Michel, your proposal is very interesting. However, OTF does not allocate cells directly: it just computes the estimated number of cells to add or delete into the schedule, and then sends this information to 6top. 6top is then in charge of negotiating cells among neighbors, and meybe perform the scheme you are proposing. So, your proposal seems fitting more the 6top-to-6top communication. Am I missing something? What others think about? Sincerely Nicola 2015-06-30 8:13 GMT-07:00 Michel Veillette < michel.veille...@trilliantinc.com>: > Hi Diego > > > > It’s my first reading of the “6TiSCH On-the-Fly Scheduling” (and I’m not > completely done yet) and I wandering if the concept of on the fly, in a > single exchange, temporary allocation of a soft cell have already been > discussed. For example, a node can use the Frame Pending subfield (IEEE > 802.15.4-2006 section 7.2.1.1.3) to indicate the presence of packets ready > to be transmitted. Based on that knowledge, the target may add an IE in an > enhanced acknowledgment to allocate a temporary soft cell (e.g. single > cell). Each subsequent transmission may further re-allocate a temporary > soft cell. It’s important to note that the default delay for a TSCH > Acknowledgment is 1ms (macTsTxAckDelay) which seem sufficient for the > processing of this new IE. > > > > > > This scheme is very reactive and may help dealing with non-predictable > communication patterns. > > What do you things? > > > > [image: cid:image001.jpg@01C868D8.BF0BB7E0] > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > michel.veille...@trilliantinc.com > > www.trilliantinc.com > > > > > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] DODAG root rank in minimal draft
+1 2015-06-25 2:37 GMT-07:00 Thomas Watteyne : > Simon, > > Your suggestions make sense to me. > > Others? > > Thomas > > On Mon, Jun 22, 2015 at 5:16 PM, Simon Duquennoy wrote: > >> That was an important fix, thanks, but now we seem to have an new >> inconsistency. In 6.2, >> "Join Priority of any node MUST be equivalent to the result of the >> function DAGRank(rank)" >> implies the DAG root has a rank of 1. However, IEEE802.15.4e-2012 >> stipulates that the PAN coordinator's join priority is 0 (section >> 5.2.4.13). This means that the PAN coordinator cannot be DAG root -- surely >> not what we want. >> >> My suggestion is to define Join Priority as "DAGRank(rank)-1". >> >> Two more comments on section 6.2: >> * This statement is currently inconsistent with having JP = >> DAGRank(rank): "The Join Priority of the DAG root is zero, i.e., EBs sent >> from the DAG root are sent with Join Priority equal to 0." >> * The whole paragraph reads like there are possibly several time sources >> (so far so good). However, this sentence implies there is only one: "If >> connectivity to the time source neighbor is lost, a new time source >> neighbor MUST be chosen among the neighbors in the routing parent set." >> >> Thanks, >> Simon >> >> >> On Mon, Jun 1, 2015 at 11:19 PM, Thomas Watteyne < >> watte...@eecs.berkeley.edu> wrote: >> >>> Yup, good catch! >>> >>> On Sun, May 24, 2015 at 10:08 PM, Xavier Vilajosana < >>> xvilajos...@eecs.berkeley.edu> wrote: >>> >>>> Dear Nicola, >>>> >>>> thanks for your comment! I reviewed both rfc6550 and rfc6552 and you >>>> are right. >>>> >>>> I corrected the draft as follows: >>>> >>>> >>>> +---+ >>>> | 0 | R(0) = 0 >>>> | | DAGRank(R(0)) = 0 >>>> +---+ >>>> | >>>> | >>>> +---+ >>>> | 1 | R(1)=R(0)+683=683 >>>> | | DAGRank(R(1)) = 2 >>>> +---+ >>>> ... >>>> >>>> substituted by this >>>> >>>> +---+ >>>> | 0 | R(minHopRankIncrease) = 256 >>>> | | DAGRank(R(0)) = 1 >>>> +---+ >>>> | >>>> | >>>> +---+ >>>> | 1 | R(1)=R(0)+683 = 939 >>>> | | DAGRank(R(1)) = 3 >>>> +---+ >>>> ... >>>> >>>> thanks you very much! >>>> regards, >>>> Xavi >>>> >>>> 2015-05-22 19:43 GMT+02:00 Nicola Accettura : >>>> >>>>> Hi Xavi, Kris, all, >>>>> >>>>> reading RFC 6550, I find: >>>>> >>>>> >>>>>1. page 70: >>>>> >>>>>A DODAG root MUST advertise a Rank of ROOT_RANK. >>>>> >>>>>2. page 112: >>>>> >>>>>ROOT_RANK: This is the Rank for a DODAG root. ROOT_RANK has a value >>>>> of MinHopRankIncrease (as advertised by the DODAG root), such >>>>> that DAGRank(ROOT_RANK) is 1. >>>>> >>>>> >>>>> So that the example in section 9.1.2 of draft-ietf-6tisch-minimal-06 >>>>> seems not compliant with RFC 6550 (unless node 0 is a virtual DODAG root). >>>>> >>>>> Am I missing something? >>>>> >>>>> Sincerely, >>>>> Nicola >>>>> >>>>> ___ >>>>> 6tisch mailing list >>>>> 6tisch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/6tisch >>>>> >>>>> >>>> >>>> ___ >>>> 6tisch mailing list >>>> 6tisch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> ___ >>> 6tisch mailing list >>> 6tisch@ietf.org >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
[6tisch] DODAG root rank in minimal draft
Hi Xavi, Kris, all, reading RFC 6550, I find: 1. page 70: A DODAG root MUST advertise a Rank of ROOT_RANK. 2. page 112: ROOT_RANK: This is the Rank for a DODAG root. ROOT_RANK has a value of MinHopRankIncrease (as advertised by the DODAG root), such that DAGRank(ROOT_RANK) is 1. So that the example in section 9.1.2 of draft-ietf-6tisch-minimal-06 seems not compliant with RFC 6550 (unless node 0 is a virtual DODAG root). Am I missing something? Sincerely, Nicola ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
Re: [6tisch] security section in minimal
+1! 2015-05-10 21:24 GMT-07:00 Xavier Vilajosana : > Dear all, > > after the last call we would like to close the security section in > minimal. We wrapped up all comments from the previous days and from the > meeting and here is our proposal: > > This draft assumes the existence of two cryptographic keys, K1 and > K2. EBs SHOULD be authenticated with key K1. DATA, ACKNOWLEDGEMENT, and > MAC COMMAND frame types SHOULD be authenticated and encrypted with key K2. > For early interoperability, K1 MAY be set to "6TiSCH minimal15". K2 SHOULD > be a randomly generated high entropy cryptographic key. Key distribution > is out of scope. > > I would like to encourage everybody to see if this texts covers all what > we want for minimal, and provide consensus. We need to move forward. > > kind regards, > Xavi > > ___ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > > ___ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
