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

[Xavier Vilajosana <[e-mail]>]

Hi Tero,

thanks for your comments. They are valuable. See inline.

2016-08-02 14:37 GMT+02:00 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.
>
> 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.


> --
>


> [e-mail]
>