Subject: [6tisch] 6P and Sf0 issue: Examples of error handling

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 3 Mar 2016 17:41:42 -0300

Dear all,
           One of the sections I would like to add to
the SF0 draft is the examples of error handling.

One example could be Timeout handling:
When a transaction times out, either a packet is lost,
the destination node lost connectivity or it is too busy
to answer on time.
Consequence: The transaction, in any stage, should
be rolled back by both ends.
Here, both nodes are expected to Timeout.
Section 3.6.2 of the sublayer draft "Aborting a
6P transaction", cannot be used, since in this case
there is no response.
I propose to issue a rollback command such as
"IANA_6TOP_CMD_ROLLBACK" to the destination
node using the same token from the original transaction,
and do not wait for an answer.
This enables the source node to try a new transaction
before the destination node times out, thus reducing
delay.

Would you agree in adding this command to reduce
delay?

Another issue should be Retry handling, in case of
timeout.
Do we allow retries within a transaction?
If we allow retries, the maximum number of retries before
considering a transaction failed should be configured on
the SF.

Thank you.
Regards,

                                    Diego Dujovne

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 4 Mar 2016 10:00:00 +0100

Hello Diego,

*For IANA_6TOP_CMD_ROLLBACK command: *

I think I understand what you are trying to solve. But using
IANA_6TOP_CMD_ROLLBACK
has another issue: how to decide when to send the command. I think this is
the same question for setting the value of 6P_TIMEOUT.
Also if a transaction timeout because of bad link quality or lost
connection, sending another packet is not a good idea.

*For Retry handling:*

First, I think whether retry or not is a decision made by scheduling
function. For 6P, it just forwards this message to upper layer (such as SF0)

If retries are required, I think it makes sense that retrying within a
transaction.

What do you think?

Tengfei

On Thu, Mar 3, 2016 at 9:41 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 10 Mar 2016 19:56:31 -0300

Tengfei,
          So, taking into account your proposal, the SF should configure
the Retry
Limit and handle the retries at SF layer, leaving 6P to deal only with
transactions:
either they are complete and successful or failed and rolled back (even in a
timeout case).
          Retries shall not be allowed during a 6P transaction: This
increases
delay, but reduces complexity.
What do you think?
          Regards,

                                        Diego

2016-03-04 6:00 GMT-03:00 Tengfei Chang <[email-masked]>:

> I think I understand what you are trying to solve. But using IANA_6TOP_CMD_ROLLBACK

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 11 Mar 2016 00:57:55 +0100

Hi Diego,

Yes, that's what I proposed.

The delay that

*starting from receiving the failure of 6P transaction, then forwarding to
SF and SF make the decision to start another 6P transcation*

depends on the position of current slot and next available slot for sending
6P request for Retry.

For example, the slotframe with 11 slots has two shared slots for 6P
transcation: slot 0 and slot 10. If I received the the response at slot0
which indicate the the failure of 6P transcation. SF is able to make the
decision to Retry before slot 10, then the delay for *SF handling Retries*
or* 6P handling the Retries* are the same (delay=10 slots).

If the failure of response is received at slot 10 and SF is not able to
make the decision before the slot 0, then *SF handling Retries* has to wait
until the next slot10 to send the 6P request(delay=11slots), while *6P
handling the Retries *can send it at slot0 with 1 slot delay.

However, I think we can assume that SF can make the decision in a very
short time (within one slot), right?

Tengfei