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

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Thu, 03 March 2016 20:41 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B319B1B43AA for <6tisch@ietfa.amsl.com>; Thu, 3 Mar 2016 12:41:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=no
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 zHTOOksbYRw1 for <6tisch@ietfa.amsl.com>; Thu, 3 Mar 2016 12:41:44 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 44FC81B43A9 for <6tisch@ietf.org>; Thu, 3 Mar 2016 12:41:43 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id l68so51761580wml.0 for <6tisch@ietf.org>; Thu, 03 Mar 2016 12:41:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=wnbz4jtbTV7VIYGU6yLmPWSZuBqrcXPQtr0xbXQcg7A=; b=z23BHp2irfsZRh12firjbNzlBA4olT2wwH4mkhH0D7inPZ8v9T1iTu6VWOgJcxQJ8/ n2gO4EB/Tl3kcrTQVWkKfLrwutZKcGyIBJLTn7cNjBvTqpkrXjK0PeMfGJst9LdyIRYJ 2spcBSAROy/t6R8bsOG8OI8YVt5TyANH9/Yn8FjfD826mHExrWj9fl9abRQwSMtUDWmO Bl3kOgsZlsZe2ZlYtm+mT01QJjxk6GH1tN6oAnte0JqjVHOcV0YTQHHYGico3wuKp9rM E7EAPLpaDWMkVKvR4i5uvLWf082hddwGqXAhuKQaP+NE5geD2BBbk48RB0YGoMyjdVMS oyVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=wnbz4jtbTV7VIYGU6yLmPWSZuBqrcXPQtr0xbXQcg7A=; b=aE69GQkW1WarR1wYs0X3GCxGFAEJxuCduvb8HL7lfCjFIEFCm6Brpi3SR4JhfCcjg0 Iy3MG+g88HSLNiDHZ+OMjbqCxABLx5D2vyVb9OYXfuT0UYMudByzNtufFIcVnmSZqJ2M boXAc1N1oaiefKQ1AhsXK4TuiI+jD7os8RVP2wZIpHet6xaoO1HwHk2d3rV3cWX/lgQG sPhlp5mRI9qdiABrEmu8h9h9GGHjFRypSTx3bGexwHmu7FMAL0KuDmjBGoSY4EoGbYej M3jQ5JNTZYQXUzngEI0KAoeD/vU+HvS2ksTLMBBAYWeBXOqWhNqZYhdVdblpa++lGTgu oZ/g==
X-Gm-Message-State: AD7BkJI6Gp2GHeaGkOfzZhHzL4mG5QRv5k3VxtFXy2tzZ0lIvg6Z/7V5hak5P275KIhebsz8fXgDyG0SpfzE1A==
MIME-Version: 1.0
X-Received: by 10.28.50.138 with SMTP id y132mr1152326wmy.52.1457037702113; Thu, 03 Mar 2016 12:41:42 -0800 (PST)
Received: by 10.28.11.195 with HTTP; Thu, 3 Mar 2016 12:41:42 -0800 (PST)
Date: Thu, 03 Mar 2016 17:41:42 -0300
Message-ID: <CAH7SZV_o4rObdYF0ocBHHaHK=Lma_aDxb7xZcVoyyuLcTykPKw@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="001a1141ee0ca8c59d052d2b069e"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/rEvuDgvQjwqmLYnaX_qIDJanwkM>
Subject: [6tisch] 6P and Sf0 issue: Examples of error handling
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
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, 03 Mar 2016 20:41:47 -0000

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