Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

[Tero Kivinen <[e-mail]>]

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.
-- 
[e-mail]