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?
ThanksQin
On Saturday, October 29, 2016 2:18 PM, Nicola Accettura
<nick.accett...@gmail.com> 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 <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
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
