Xavier Vilajosana writes: > 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?
That might not be needed, depending how the protocol is used. We do not do that in UDP based protocols, we usually assume that requested will retransmit request until it gets response back, and if it does not get response back ever, it assumes the other end is dead, and does something else (like reconnect). You can do similar things here. I.e., initiator sends request and waits for response. If it does not get response (to the application level) in specified time, it will retransmit its application level message (which will be sent as new L2 frame), and it will continue retransmit until it gets response, or it times out. This will require the protocol to be made in such way that responder is able to recognize the retransmissions, and send same responses to them as it sent first time. This does not require separate confirmation message. If responder requires confirmation it can also use the fact that other end started using newly allocated resources as a confirmation that initiator has received the response... > XV: idem as before, doable but consumes more energy. let's reach consensus so > we can progress. TSCH network use lots of energy anyways, as they cannot be sleeping for long time. Every node in the network needs to be sending packets every now and then to keep synchorinized in the network time, thus adding one or two packets to be sent during the setup phase is not really that big difference compared to the mandatory timekeeping frames that needs to be sent during normal operation. -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
