Oh yes, Tero, we agree on the bottom line and on your points.
Cheers, Pascal > -----Original Message----- > From: Tero Kivinen [mailto:[email protected]] > Sent: mardi 8 mars 2016 15:50 > To: Pascal Thubert (pthubert) <[email protected]> > Cc: Tengfei Chang <[email protected]>; [email protected]; Prof. Diego > Dujovne <[email protected]> > Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P > > 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. > -- > [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
