Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft

Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Sat, 01 October 2016 04:29 UTC

Return-Path: <xvilajosana@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 3908E12B02F for <6tisch@ietfa.amsl.com>; Fri, 30 Sep 2016 21:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 bh5zONZqXhbj for <6tisch@ietfa.amsl.com>; Fri, 30 Sep 2016 21:28:59 -0700 (PDT)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010: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 8250412B008 for <6tisch@ietf.org>; Fri, 30 Sep 2016 21:28:58 -0700 (PDT)
Received: by mail-lf0-x231.google.com with SMTP id g62so120468087lfe.3 for <6tisch@ietf.org>; Fri, 30 Sep 2016 21:28:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=XP5QrC5fjq0dqy+6ZE7ZFfkichobJwCY5KBL05LlHFM=; b=q8rVj5WdA6vMXRWARxqFzmAt+m3iLT1x9YFP+mahv97W/+kK/P922hthzWHDKewK05 GwVe21+Ys0l33IQubLU5vMbLPgR8keT98gVkBTxThvd8B5ozV5RrlI8XAKub5gZ5Y2kQ 44tq5VTaoffAVo3kKhFWNu/DsdqfUGVaKZn8eErytpY3b4ussHzxM6DHn1Cal06XrFUJ 3WnOwo524o9e4PZ9bvBhSRuB+OB1oR939jvQj96cPe4N9393l3gMLKJdr8IGzGsAccwE 8D5/sbX4acESmHBbRcHsuT9b4wZRuoYBQfhw6XbCjgQctZNJ5arC4bYMnzorJuz6ofuK F9ug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=XP5QrC5fjq0dqy+6ZE7ZFfkichobJwCY5KBL05LlHFM=; b=dhuGGfsSdjUJRa9BCGB2la13HQIB3H76OhAFrNiWNyj9zS3Y3z806CXCFxhDGouE3c ybgPwo45bbXJMutbibLxELwqQaU1suFG02RN0wCU6VdwLMBLIXtNufYkLipUZkJH0+5J xUCPJnxAIOnGgg9SaoBjlP51nsmYok9VG+R4MM+646VxOuzux5BzKa5jxDq7oJV4E0DW gdnvg5lHKRsKF3Y65EOTj5aFXYgjDRdyxmd8LPofnU28NoVA25AgF4ytAbmcEtxiSR8c WQlM6G7wZQb471tigJo/GiHBotee2rFf2dB4kZ12Z1PLuMb5zxZRIt1tvGmd3rKDAmR3 4pfw==
X-Gm-Message-State: AA6/9Rnt3j4y4UWMNxzs/CG5KtstOhhF8rgnbSHtjzkQRv6vSY1WvVxD08p1AVjMOkuA2mfvDqI7uDrasOesAw==
X-Received: by 10.46.71.75 with SMTP id u72mr4102582lja.74.1475296136641; Fri, 30 Sep 2016 21:28:56 -0700 (PDT)
MIME-Version: 1.0
Sender: xvilajosana@gmail.com
Received: by 10.25.16.92 with HTTP; Fri, 30 Sep 2016 21:28:56 -0700 (PDT)
In-Reply-To: <CAAdgstQ=dvdU7PYZLts7=mRyXowS5_zCh7dFndwEhOdT5yuRMg@mail.gmail.com>
References: <CAAdgstQ=dvdU7PYZLts7=mRyXowS5_zCh7dFndwEhOdT5yuRMg@mail.gmail.com>
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
Date: Sat, 01 Oct 2016 06:28:56 +0200
X-Google-Sender-Auth: Yah-xZQeBcuBw4uZsTRn961cCAc
Message-ID: <CAMsDxWQNAH4_VT10_Y30aeiFSbmt27GBtdWiOB=ttcrpWvcbRg@mail.gmail.com>
To: Tengfei Chang <tengfei.chang@inria.fr>
Content-Type: multipart/alternative; boundary="001a11403b6429c16b053dc626ac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/uQTHLjh7KsZ9OVuNsd_S7zFBzu4>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Subject: Re: [6tisch] [6TiSCH] return code in 6p response defined in sixtop draft
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: Sat, 01 Oct 2016 04:29:01 -0000

Hi Tengfei,

see inline

2016-09-23 12:22 GMT+02:00 Tengfei Chang <tengfei.chang@inria.fr>:

> Dear all,
>
>
> I have some question about the return code (mainly about the ERROR code)
> in 6p response packet define in the draft:
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02
>
> In figure 7: https://tools.ietf.org/html/draft-ietf-6tisch-6top-
> protocol-02#section-4.2.4
>
>  Return Code              Value          Description
>    +--------------+------------------------+---------------------------+
>    | RC_SUCCESS   | IANA_6TOP_RC_SUCCESS   | operation succeeded       |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_VER   | IANA_6TOP_RC_ERR_VER   | unsupported 6P version    |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_SFID  | IANA_6TOP_RC_ERR_SFID  | unsupported SFID          |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_GEN   | IANA_6TOP_RC_ERR_GEN   | schedule generation error |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_BUSY  | IANA_6TOP_RC_ERR_BUSY  | handling previous request |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_NORES | IANA_6TOP_RC_ERR_NORES | not enough resources      |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR_RESET | IANA_6TOP_RC_ERR_RESET | abort 6P Transaction      |
>    +--------------+------------------------+---------------------------+
>    | RC_ERR       | IANA_6TOP_RC_ERR       | generic error             |
>    +--------------+------------------------+---------------------------+
>    | reserved     | TODO-0xf               |                           |
>    +--------------+------------------------+---------------------------+
>
>
> As it defined a lots of error return code and also it has generic error:
> RC_ERR.
>


>
>
>    - When should the nodes use the generic RC_ERROR? I assume it
>    indicates the request cells are not available (the cell is occupied already
>    when adding OR can't find the cell when deleting)?
>
> If a node receives a 6P Request from a given neighbor before
   having sent the 6P Response to the previous 6P Request from that
   neighbor, it MUST send back a 6P Response with a return code of

   RC_ERR.

this is, a Node A has still not received from Node B the response of a
command while A issues again a command to B. In this case B responds with
RC_ERR.

>
>    - Also, if the 6p response has multiple cases matched (for example,
>    the candidate cells are occupied RC_ERROR and also no enough resource
>    ERROR_NORES...), which one should the mote choose? (add priority for the
>    error code? at least we need a decision)
>
>
that is a good point. The two options I see are, either returning the list
of error codes or defining priorities and returning the most important. We
should consider that in the next version of the draft.



> Looking forward to talk to you during the meeting soon!
>
> Tengfei
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>