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

[Tero Kivinen <[e-mail]>]

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