Hi Tero, thanks for your comments. They are valuable. See inline.
2016-08-02 14:37 GMT+02:00 Tero Kivinen <[email protected]>: > 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. > > XV> I will study your proposal (also the example you point in the next email you had sent). it seems more flexible but still simple. > > 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)). > > XV: so you suggest 3 way (request-response-confirmation) for all cmds.. It is energy-wise costly. What others think? > > 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... > XV: idem as before, doable but consumes more energy. let's reach consensus so we can progress. > -- > > [email protected] >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
