Hi Qin, I'm very happy for your feedback.
I was just considering the transaction as a 6P one, you have bettered off that by introducing also the relationship between 6P and SF0 in each part of the transaction. This is perfect now! Actually I did not propose to delete the timeout. I perfectly agree with you in saying that we need timeouts to preserve the system from Failed transactions. I was proposing instead to have a timeout on both sides of the transaction, but shorter than the one that would be required if the transaction was 2-way: 1. node A will start the timeout after receiving the mac-layer ack from node B for the ADD request: if node A receives an ADD response from B during the timeout window, the transaction will continue, otherwise, the transaction is considered as failed 2. node B will start the timeout after receiving the mac-layer ack from node A for the ADD response: if node B receives a 6P ACK from A during the timeout window, the transaction will continue, otherwise, the transaction is considered failed Please, note that, if A received the ADD response in the 'minimal' shared cell and the dedicated TX cells are allocated just after that reception, the 6P ACK will be sent during the same slotframe in the first dedicated TX cell. Just speaking about possible extensions for more complex uses: the 6P ACK could also hold a flag to declare it as a NACK. If the timeout on node A was expired, and it received a 6P answer out of time by B, it can send back a NACK to let B stop its own timeout and let it delete the RX cells previously half-opened. What do you think? Nicola 2016-10-31 16:20 GMT+01:00 Qin Wang <[email protected]>: > Hi Nicola, > > I want to confirm my understanding first. > > Your proposal is to introduce a new 6P message, i.e. 6P ACK message, into > a transaction, then the sequence of a original 2-way ADD transaction will > be: > (1) node A SF0 sets "adding TX cells" OPEN, and 6top layer sends ADD > request to nodeB > (2) node B 6top layer receives ADD Request, SF0 sets "adding RX cells" > OPEN, and 6top layer sends ADD Response to node A > (3) node A 6top layer receives ADD Response, SF0 adds TX cells and sets > "adding TX cells" CLOSED, and 6top layer sends 6P ACK to node B > (4) node B 6top layer receives 6P ACK, SF0 adds RX cells and sets "adding > RX cells" CLOSE. > > Is my understanding correct? In addition, the proposed scheme will not > need Timeout. Is it what you mean? > > But, I still think the scheme can not avoid a Timeout. Otherwise, how node > A or node B can stop a Failed transaction if something happens? > > Thanks > Qin > > > > On Saturday, October 29, 2016 2:18 PM, Nicola Accettura < > [email protected]> wrote: > > > Diego, all, > > the timeout obviously must start when the ack is received. I agree in > total. > > Though, you still need to get the timeout proportional to TXATTEMPTS and > also to the maximum backoff window. Why? > > Call A the node that is requesting cells, and B the node that is asked for > cells. Node A sends a request and gets a mac layer ack from B. A starts the > timeout. B sends a packet, but it's lost. Sends another packet and it is > lost... until the last attempt which is successful: B gets a link layer ack > from A. So B allocates cells as RX. > > This confirms that the timeout should be proportional to TXATTEMPTS. And > to the maxium backoff window. If there is only one shared cell, according > to 'minimal', the timeout is proportional also to the slotframesize. If > some implementation considers more than one shared cell per slotframe, the > timeout can be smaller. At this point, I would say that the unity of > measure of the timeout should be the number of executed shared cells, so > that the timeout can be safely be proportional just to the product of > TXATTEMPTS and the maximum backoff window. > > Yes, this causes to have a very long timeout, with possible (and actually > frequent) desynchronizations. Especially when the network is forming, all > nodes will ask for dedicated cells, many 6P packets will get lost. > Keepalives will be triggered, but this worsen the situation. Everything is > very very bad. > > Is that possible to have a shorter timeout? > > My answer is 'yes'. But we need something else: a 6P ACK. > > In fact, assume that A sent a request, B acked at MAC layer. Then B (maybe > after many tries, if the responses have been lost, and this is possible in > the 'minimal' shared cell due to collisions in big networks) is finally > able to send an answer that is correctly received by A and A sends an ack > at mac layer. B adds cells as RX and expects A to open the same cells as > TX. > > 'Good!' one would say. > > Wrong! Node A has acknowledged at MAC layer the correct reception of the > answer by B but will process the 6P packet after that. If the timeout is > too short, that packet will be considered out of time. And the TX cells > will not be allocated. With some RX cells open on node B. > > One can think of a timeout to garbage collect on B. But I'm not sure this > would be very efficient, there's the probability of false positive. > > A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX > side after receiving the mac layer ack from A. A will open the TX side > after sending the mac layer ack, it the 6P response was in time. It will > send the 6P ack possibly in the newly created dedicated cell, so > decongesting the shared cell of 'minimal'. If B receives the 6P ack, it > will be sure that the RX side is open completely without possible > impairment with the node A schedule knowledge. > > Instead, if the 6P response was out of time, A will not send any 6P ack, > will not open the TX side. B will not receive any 6P ack within a timeout > (that can be the same length as that starting on the A side after the > reception of the mac layer ack to the request packet) and when that expires > will delete the RX cells that were 'half' opened. > > With this, it is not possible to get suspicious cells allocations on the > RX side. There's still the possibility that a TX side is open with the RX > side not open. But for that, 6P or SF will manage a relocation. > > Think about the 6P packet as the third part of a 3-way-handshake. > > Of course, it's obvious that I'm strongly in favor of a 6P ack definition, > more than having a big timeout. > > Does it make sense? > > Nicola > > > 2016-10-29 18:44 GMT+02:00 Prof. Diego Dujovne <[email protected]> > : > > Dear all, > Yesterday, we had a discussion about ticket #53 > from the issue tracker, on the way to calculate the > SF0 timeout value. > There is current a proposal to calculate the timeout > on SF0 between the arrival of the MAC-layer ACK for the > request packet and the arrival of the response packet. > In order to achieve this calculation, the 6P protocol must > signal the arrival of the request ACK packet so as to start > the timer countdown. > Using this method, we avoid very long timeouts set > to the max value of the number of TXATTEMPTS and the > maximum backoff value. > Graphically: > > SF |REQUEST| |timer-----|RESPONSE| > ^ > 6P |REQUEST| | |RESPONSE| > MAC LAYER |REQUEST| |ACK| |RESPONSE| |ACK| > > I would like to know if your thougthts about this idea. > Thank you. > Regards, > > Diego > > -- > DIEGO DUJOVNE > Profesor Asociado > Escuela de Informática y Telecomunicaciones > Facultad de IngenierÃa - Universidad Diego Portales - Chile > www.ingenieria.udp.cl > (56 2) 676 8125 > > ______________________________ _________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/ listinfo/6tisch > <https://www.ietf.org/mailman/listinfo/6tisch> > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
