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

Tengfei Chang <tengfei.chang@gmail.com> Thu, 10 March 2016 23:58 UTC

Return-Path: <tengfei.chang@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7588512DEED for <6tisch@ietfa.amsl.com>; Thu, 10 Mar 2016 15:58:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svgzwippCnY5 for <6tisch@ietfa.amsl.com>; Thu, 10 Mar 2016 15:58:04 -0800 (PST)
Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BCDB12DEFA for <6tisch@ietf.org>; Thu, 10 Mar 2016 15:57:56 -0800 (PST)
Received: by mail-yk0-x231.google.com with SMTP id y66so42466078ykd.2 for <6tisch@ietf.org>; Thu, 10 Mar 2016 15:57:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eDAoEtA/EuxyM2ZwaaZdWKNldY5lNMB4B6B3hFfeJWQ=; b=mnqoH9QdlOtTCMPy2C7uqi3WhzQU7RL1lvPi37Ox9ZnwyEau8xQBm4X448yxGTsRua E+rq0/B/XXrolq6vaK6LG/KsTH7UpzPewwZ1Y9HhIpjwunzkdvQbQzJd7fZnzZrQDmT2 piRN10KZYn8lQ+nMlCVhbVuZtE9GQFUMHLut7j+YfjDsMYZmXYRS7Dcl4Leyh2KZYsGT Jc10w5RnUwycOoO9E6uf9f9xDoQWP6g/hAcE1vhZenmbsz8UX3FhrCeBGGilIdyakz6t mzfNl3KUEJmPuXC6QD8Mw3URV1V5Oq4IT7qIX+Cqa03UjrnQ0i/suXWAm6nCppvqJLzH uROw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eDAoEtA/EuxyM2ZwaaZdWKNldY5lNMB4B6B3hFfeJWQ=; b=USDbPGYmKVPtIvy1dW/4/pHhxTzFVvPZe6mCE6FMLjJSw9Rcwrm+3bxx6mQj8X97PR T0L0c/mClL5YWK3Fwuwghv5HtfMPQhPRUl7Hf5wKKvU7LiTlsLShwqPoP3oQOBhmP6Ix jen88kmY/wH19t+9csJFdpMLaaZX8Qn6VqRQfiMBxVYYO02rcCSfRugcCmZEAY+QT9T6 btf4+9bsIEb9/V7gF9nQ6D9JB3QsU4V5ytMvuUh7OWcU3b+M8XXGf8TPnjKlO5AfK+hW 835RR8Kg4+ArxMHcWf5i76aU6XXd5oGFhSuWWG3RY/NIL/asOPhUWtxm4K1YoQEGVuLO ppDQ==
X-Gm-Message-State: AD7BkJJ6hIVT2sEzBHgtWHQD3p29obsUNj2CGymMgFJ1ra/GUeKzS2o1FEYF4187L9tii9etSy5s4lIC6lMbOA==
MIME-Version: 1.0
X-Received: by 10.37.231.140 with SMTP id e134mr3466564ybh.51.1457654275570; Thu, 10 Mar 2016 15:57:55 -0800 (PST)
Received: by 10.37.230.214 with HTTP; Thu, 10 Mar 2016 15:57:55 -0800 (PST)
In-Reply-To: <CAH7SZV-1N57uZzyV=KNJSnin5bBAeYXfSUbDWQM4AS0ZkbAUmw@mail.gmail.com>
References: <CAH7SZV_o4rObdYF0ocBHHaHK=Lma_aDxb7xZcVoyyuLcTykPKw@mail.gmail.com> <CAAdgstQKhJOQGGRfLq6RgW-yTVW4PxpCRtvop0F30PXHhFMccg@mail.gmail.com> <CAH7SZV-1N57uZzyV=KNJSnin5bBAeYXfSUbDWQM4AS0ZkbAUmw@mail.gmail.com>
Date: Fri, 11 Mar 2016 00:57:55 +0100
Message-ID: <CAAdgstTJ_E-Ru59KgNCO671-HLHVDLHEaHicp5Y_Yae+rAk36A@mail.gmail.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Content-Type: multipart/alternative; boundary=94eb2c0b1dba4d04be052dba95be
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/6Qi8Y20d1fJ_VIQso2abKIOfqPA>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] 6P and Sf0 issue: Examples of error handling
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Mar 2016 23:58:06 -0000

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

On Thu, Mar 10, 2016 at 11:56 PM, Prof. Diego Dujovne <
diego.dujovne@mail.udp.cl> wrote:

> 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 <tengfei.chang@gmail.com>om>:
>
>> 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 <
>> diego.dujovne@mail.udp.cl> wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> 6tisch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>
>
> --
> 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
>