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

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Thu, 10 March 2016 22:56 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
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 1D9F512DE7A for <6tisch@ietfa.amsl.com>; Thu, 10 Mar 2016 14:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 xjJjgwqfPr7p for <6tisch@ietfa.amsl.com>; Thu, 10 Mar 2016 14:56:34 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 02EB612DE76 for <6tisch@ietf.org>; Thu, 10 Mar 2016 14:56:33 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id p65so6956224wmp.1 for <6tisch@ietf.org>; Thu, 10 Mar 2016 14:56:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xL0Tixb1C6xC1GCN/jPis6jOoWXbO1+Xacud46BT0go=; b=xsW+mhwqiSs0v4pg41dYNzE+iZU8ArHV95vyQe9W7zBSPtQ/Rk1VjviXmxfWu22vx3 XXUQE70l8R0nQ0/6AHs2nHQKVZcNGZNJc3aVJsiFCqglJhlZxo5YYBSTWK+0IvCJIvlR N+Ew1Xu8HFlFFnC6gYnSqoEtNL8nKXQ/wRxYqfOxe3NKfabACvwoK7GDD5n27lFOC0u4 6aHfNdXFXB+ABWqyM8TqP1rNDT7VEWvsHDtUOMwh8RQ7moUcf1OGN16EDmm3DPbgbeie jAem9tdID38lHEXk6j+yFm+IaWl88AzJYnlKHPPtikjZNOVo3nF/U0428tur81ZQogaM y5hg==
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=xL0Tixb1C6xC1GCN/jPis6jOoWXbO1+Xacud46BT0go=; b=hqyrk/czlaUyFo3Tre+6bjBLg7o6JI9WGZRPgMH5I/L4EJsQB1BI/0i70U86tSzs4a LdXmRHv/GbcMKWN/fhtjOkNeQSjaHJs0Ba1sgCoySY4ISYTF0lq/QVU1BDdWLz8EwtH9 Yxyno+dTyJxVOUMWwDY6Nke9yp4v905t3YOZ+uMzEcKzBph16BkEvL206CzA5lTyOStH UWFPI5luhg0fcYURPbhZEpfHVj07XK6RmvYD626R9gSAibs7nyer58jGkSOQZuFa+gOd tkQyq6yWzzG8rKJqWEkYVFplczT4i3I7OPSAoyEdSGCUiO1mzGzY2iuoQpydg374zW09 30rw==
X-Gm-Message-State: AD7BkJLr820WU+LCYr6e68kFWpQGRUGevIWKiMCgaUO4H6OMKulAsvJVadMHtr78qPiKDwkNSDl1jrA9hW2v5Q==
MIME-Version: 1.0
X-Received: by 10.28.195.9 with SMTP id t9mr836843wmf.0.1457650592322; Thu, 10 Mar 2016 14:56:32 -0800 (PST)
Received: by 10.28.11.195 with HTTP; Thu, 10 Mar 2016 14:56:31 -0800 (PST)
In-Reply-To: <CAAdgstQKhJOQGGRfLq6RgW-yTVW4PxpCRtvop0F30PXHhFMccg@mail.gmail.com>
References: <CAH7SZV_o4rObdYF0ocBHHaHK=Lma_aDxb7xZcVoyyuLcTykPKw@mail.gmail.com> <CAAdgstQKhJOQGGRfLq6RgW-yTVW4PxpCRtvop0F30PXHhFMccg@mail.gmail.com>
Date: Thu, 10 Mar 2016 19:56:31 -0300
Message-ID: <CAH7SZV-1N57uZzyV=KNJSnin5bBAeYXfSUbDWQM4AS0ZkbAUmw@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: Tengfei Chang <tengfei.chang@gmail.com>
Content-Type: multipart/alternative; boundary=001a1148d9fec33235052db9b970
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/jUyAcS49Jc0y0tE1LfpikDZdU0M>
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 22:56:37 -0000

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