+1 The 15.4 spec only has a few criteria for not acknowledging a frame - mismatch PANID, mismatch destination address, or failing security processing.
— Jonathan On Jul 2, 2015, at 12:11 AM, Thomas Watteyne <[email protected]> wrote: > For neighbor-to-neighbor negociation, we have been opting for > https://tools.ietf.org/html/draft-wang-6tisch-6top-coapie-00, i.e. a speciifc > IE which carries the same payload as we use for CoAP-based management. This > draft just expired, maybe Qin could publish a revised version so we can start > discussing from there in Prague? > > I don't believe we can standardize that the node needs to do something > between the DATA frame it received and the ACK frame. ACK is just link-layer > mechanism to indicate that the node got the packet. AFTER the ACK is sent, > the node hands the MAC payload to the upper layer. Out of the numerous things > that can go wrong if we have a node do something between DATA and ACK, I'm > most worried about a node not being able to ACK some packets, because the > DATA packet contains too much semantics. > > Comments welcome. > > On Thu, Jul 2, 2015 at 6:14 AM, Michel Veillette > <[email protected]> wrote: > Hi Nicola, Qin > > > > About “Frame Pending bit does not mean that there is an emergency” > > > > I agree, the Frame Pending bit was provided just as an example in my first > email. The assumption was that the target was fully in control of the > scheduling base on availability of soft cells and availability of buffers. If > more information need to be transferred like this notion of emergency or > priority, a list of cells, the Frame Pending bit just need to be replaced by > an IE. The concept however stay the same, a temporary soft cell allocation > within a single transmission without consuming any extra bandwidth (cells). > > > > About “ACK frame is too tight or not” > > > > In the context of IEEE 802.15.4, the ack turnaround time is certainly too > tight (192 usec) > > For TSCH, the macTsTxAckDelay is 1 msec which seem to be very doable. > > > > > > <image001.jpg> > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > From: Nicola Accettura [mailto:[email protected]] > Sent: 1 juillet 2015 19:55 > To: Qin Wang > Cc: Michel Veillette; [email protected]; [email protected] > Subject: 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 <[email protected]>: > > 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 > <[email protected]> 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 > 6top-to-6top. Why? > > Currently 6top-to-6top could be used for allocating cells through a > negotiation: > > 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 > 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: > > 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 > <[email protected]>: > > 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. > > > > > > > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > From: Qin Wang [mailto:[email protected]] > Sent: 1 juillet 2015 11:28 > To: Nicola Accettura; Michel Veillette > Cc: [email protected]; [email protected] > 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 > <[email protected]> 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 > <[email protected]>: > > 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? > > > > Michel Veillette > System Architecture Director > > Trilliant Inc. > Tel: 450-375-0556 ext. 237 > [email protected] > > www.trilliantinc.com > > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > _______________________________________________ > 6tisch mailing list > [email protected] > http://cp.mcafee.com/d/FZsSd2gwcxNJ5xBZVd55AsrKrhs7cFCQn1PbVJ5MsqekkSjhOrsuuusoLsS8QAHm0afB3ZzOVI-kfSfbCXLIuMqenT-LOarzbP7nKnjp7cYCOesspVqWdAkRrK9YG7DR8OJMddECQjt-hojuv78I9CzATsSjDdqymokWnPtU03wCHIcfBisEeRNOsGm9CT9OFoCn8lrxrW0GnPtU02rsvod7bNI5-Aq83iSVelb4PiWq848WXcKwS8RcMYKVelb4OZo5VA_bKDByZTPr0USHhf0y2c43Xx
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
