Xavier Vilajosana writes: > A node knows the bytes it can fit in a packet. This gives an indication to the > node of what is the number of items that can be requested. When a node issues > a LIST it starts by offset 0, this returns the first N scheduled cells. Then > it seems reasonable that the node will indicate offset N and request N more > cells ... > If the number of requested cells does not fit in the packet an error is > returned and the node retries again with a smaller value of N. > I do not see a big complexity on that. What issues do you see?
Note, that in 15.4 network some othe frames might also include other information elements, which might consume some of the space available for the actual data. I.e., even the upperlayer of the sending device might not know how many bytes it can send at given moment, as MAC layer might add some extra overhead without telling that to the upper layer. I think it would be better to make protocol so that sender will send as many items it can fit, and indicates whether there is more and responder will just give offset where the next request starts. Or just use the numCells as a max size, but make it so that sender can also send less if it cannot fit that many in response. This would require some way to tell how many cells there are so requested will know when to stop. > 2. Will the clear command result in inconsistency in current > design? For example, a clear command is sent from A to B and the > response from B to A is lost. > > The CLEAR is not executed until the response is received. B side > executes the CLEAR after receiving the L2 ACK of the response > message. > > It there any problem when the L2 ACK is lost in which A clears while B > does not? > > In a TSCH network the probability of losing the ACK is very low. As the packet > has already been sent the ACK has extremely high chances to pass as well (it > is shorter in length which still favours the transmission success). Of course > this can remotely happen and if this happens the system should recover from > that inconsistency. To do so the generation counters will enable the detection > of the inconsistency and both nodes schedule will be cleared (only cells > between them). Loosing ACK might be low probability and that does not usually even cause issues, as L2 will simply retransmit the frame. The bigger issue is that L2 ACK just indicates that FCS check was correct and frame was received by the other end, it DOES NOT mean that frame will be delivered to the upper layer. It is completely possible that MAC runs out of buffer space after receiving the frame and sending ACK, but before sending the received frame to upper layer. I.e. L2 ACK only means that I got the frame, no need to do retransmission anymore. It does not mean that frame will be delivered to the upper layer, or that upper layer will be able to parse and process the frame. So using L2 ACK for any kind of application level acknowledgement is bad idea. Also with 6tisch L2 ACK is alreayd quite large (frame control (2 octets), seq number (1), addressing fields (0-20), auxiliary security header (1-10), Time correction IE (2), MIC (4-16), FSC (2-4)). > The alternative is to use a 3 step transaction, which requires 33% more > packets over the air at every transaction. We decided to avoid that. Maybe a > research question is to evaluate in a real deployment the energy overhead of > using 3 way transactions vs eventually recovering from a lost ACK during a > CLEAR. Given the chances of losing an ACK I would bet for the later. I think using protocol defined on the 6top layer is better. It is bad idea to rely on L2 ACKs for anything else than information that there no need to retransmit this frame again... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
