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

From: [email-masked] (Dale R. Worley)
Date: Mon, 03 Oct 2016 14:45:46 -0400

Xavier Vilajosana <[email-masked]> writes:
>>    - 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.

I've seen situations in another protocol (SIP) where a single request
could be responded to with multiple error codes.  There has been no
pressure to specify which of the possible error codes MUST be returned.

The understanding is that different implementations process various
aspects of a request in different orders, and that an implementation
will generally return the first error condition that it discovers and
then abort processing of the request.  A rule for which of the multiple
errors must be returned would require either that an implementation
process the request in a fixed order, or that it must somehow complete
processing and then select the "best" error code.  Worse, if a request
is erroneous in one particular aspect, then it may be ill-defined
whether it is erroneous in another particular aspect.

Dale

---

From: Qin Wang <[email-masked]>
Date: Mon, 3 Oct 2016 19:20:38 +0000 (UTC)

Hi,
Regarding to how to choose a error code when multiple error codes could be candidate, I think we can use a simple rule as follows. If a specific error code, such as RC_ERR_NORES, is matched to the abnormal situation, then the specific error code must be used. If there is no specific error code is matched to the abnormal situation, then the generic error code RC_ERR must be used. 
BTW, I haven't seen there is any overlap among different specific error codes. Did I miss something?
ThanksQin

    On Monday, October 3, 2016 2:55 PM, Dale R. Worley <[email-masked]> wrote:

Dale

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

---

From: Tengfei Chang <[email-masked]>
Date: Tue, 4 Oct 2016 10:37:00 +0200

Hi Professor, all

Probably there is no overlap between specific error code. But some concept
of the error code is not that clear for me.
=================================
In section 4.3.8 about aborting a 6P Transaction:

4.3.8 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#section-4.3.8>.
Aborting a 6P Transaction

   In case the receiver of a 6top request fails during a 6P Transaction
   and is unable to complete it, it SHOULD reply to that request with a
   6P Response with return code RC_ERR_RESET.  Upon receiving this 6top
   reply, the initiator of the 6P Transaction MUST consider the 6P

   Transaction as failed.

I am thinking here when it says
a 6top request fails during a 6P Transaction

   and is unable to complete it

what is the definition of  6top request fails OR is unable to complete it?
If there is specific reason, we can use an specific ERROR code for that.
The current content (for now) says, the nodes doesn't know the reason, so
return with RC_ERR_RESET. If this is the case, the content trying to say,
it more like a undefined error, in case we can't cover all error.

Also what does the RESET mean?  Reset the sixtop transaction? then what the
default status of sixtop transaction? May somewhere in the draft/concept I
missed? Please let me know.

=================================
Xavi,

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.

RC_ERR is defined as generic error in the table. However, this content is
saying a specific case, rather than a generic error. Maybe generic is not
the right term

Also when should we use a generic error?

=================================
Dale,

Indeed, there is an order for sure when the sixtop is implemented.

I am wondering If we didn't define this order in the draft and let the
implementer choose.
what happens when we do interoperability test, if one sixtop implementation
return error code is not expected  as the other sixtop implementation.

Maybe it's fine, but at least we need keep the following error codes with
higher return priority than other.

RC_ERR_VER

RC_ERR_SFID

maybe also RC_ERR_GEN

Please let me know if there is something I misunderstand from the draft.

Tengfei

On Mon, Oct 3, 2016 at 9:20 PM, Qin Wang <[email-masked]> wrote:

> Hi,
>
> Regarding to how to choose a error code when multiple error codes could be
> candidate, I think we can use a simple rule as follows. If a specific error
> code, such as RC_ERR_NORES, is matched to the abnormal situation, then the
> specific error code must be used. If there is no specific error code is
> matched to the abnormal situation, then the generic error code RC_ERR must
> be used.
>
> Thanks
> Qin

-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 6 Oct 2016 21:31:14 +0200

Hi Tengfei,

thanks for your effort on going through the details of the error codes.

see inline:

2016-10-04 10:37 GMT+02:00 Tengfei Chang <[email-masked]>:

> 4.3.8 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02#section-4.3.8>.  Aborting a 6P Transaction
>
> Also what does the RESET mean?  Reset the sixtop transaction? then what
> the default status of sixtop transaction? May somewhere in the
> draft/concept I missed? Please let me know.
>

XV>> I think that reset means CLEAR the transaction state, that is for
example unlock the cells that have been temporally reserved for the
transaction, clear any state machine or state variable that indicates that
a transaction has been initiated.

XV>> as a consequence of your comment, maybe we have to clarify that in the
draft.

XV>> good point. Generic is not a good term. We should definitely be more
clear with the errors. I would say this is an error that indicates that the
operation is not permitted as there is an ongoing transaction.

> what happens when we do interoperability test, if one sixtop
> implementation return error code is not expected  as the other sixtop
> implementation.
>
>> Regarding to how to choose a error code when multiple error codes could
>> be candidate, I think we can use a simple rule as follows. If a specific
>> error code, such as RC_ERR_NORES, is matched to the abnormal situation,
>> then the specific error code must be used. If there is no specific error
>> code is matched to the abnormal situation, then the generic error code
>> RC_ERR must be used.
>>

-- 
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya

+34 646 633 681| [email-masked] | Skype: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 7 Oct 2016 14:58:33 +0200

All,
I have captured this discussion in
https://trac.tools.ietf.org/wg/6tisch/trac/ticket/45. Let's discuss at the
interim and make a decision.
Thomas

On Thu, Oct 6, 2016 at 9:31 PM, Xavi Vilajosana Guillen <[email-masked]
> wrote:

>> Probably there is no overlap between specific error code. But some
>> concept of the error code is not that clear for me.
>> what is the definition of  6top request fails OR is unable to complete
>> it? If there is specific reason, we can use an specific ERROR code for
>> that. The current content (for now) says, the nodes doesn't know the
>> reason, so return with RC_ERR_RESET. If this is the case, the content
>> trying to say, it more like a undefined error, in case we can't cover all
>> error.
>>
> XV>> as a consequence of your comment, maybe we have to clarify that in
> the draft.
>
>>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________