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

[Xavi Vilajosana Guillen <[e-mail]>]

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 <[e-mail]>:

> 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.
>

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.

>
> =================================
> 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?
>

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.

>
> =================================
> 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 <[e-mail]> 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.
>>
>> BTW, I haven't seen there is any overlap among different specific error
>> codes. Did I miss something?
>>
>> Thanks
>> Qin
>>
>>
>>
>>
>> On Monday, October 3, 2016 2:55 PM, Dale R. Worley <[e-mail]>
>> wrote:
>>
>>
>> Xavier Vilajosana <[e-mail]> 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
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>>
>
>
> --
> Chang Tengfei,
> Pre-Postdoctoral Research Engineer, Inria
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


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

[phone]| [e-mail]­ | 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)



­