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 <diego.dujo...@mail.udp.cl>: > 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
