Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

[Tero Kivinen <[e-mail]>]

Pascal Thubert (pthubert) writes:
> But this is another discussion entirely. It is about the transaction
> that associates new timeslots to a bundle and why we need a
> correlator, or transaction ID. I was explaining that if the parent
> wait for the ack to allocate a slot that was negotiated, and there
> is no flow after that, then if the ack is lost the child thinks the
> slot is allocated and the parent does not. The child may start using
> it wrongly.  

Which is why you should not use ACK for anything like that, but
instead use application level messages for that kind of things. 

> The point behind this is that if the transaction does not complete,
> it must be retried from scratch with the same sequence, or it must
> time out and roll back.

Receiving or not receiving ACK should not cause transaction to
complete or not to complete, there must be some kind of application
level message to indicate that it was successful if that information
is needed in the peers.
-- 
[e-mail]