Re: [6tisch] draft-ietf-6tisch-msf-06 is published

Hi,

This is an open issue, what return code to return when there is no available cell.

Christian raised it before:

   https://mailarchive.ietf.org/arch/msg/6tisch/Awiip2xOfwZTPyg1jQIeIOyqSgk

As per RFC8480:

- RC_SUCCESS with an empty list will be returned
- RC_ERR_BUSY is defined to be returned when there is not enough resource to handle a new *transaction*
- RC_ERR defined is be returned for a request having an invalid CellOptions value, or for a response having an unknown return code (in the 3-step case)

> I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS

Between the two, RC_ERR_BUSY would be better since RC_ERR is basically telling that the responder doesn't understand your 6P message.
But, RC_ERR_BUSY is not good either. It is a return code suggesting "retry it later", not "give up this neighbor."

If possible, I would define a dedicated return code for this case, like RC_ERR_NO_AVAILABLE_CELL or RC_ERR_NO_CELL, though.

One solution within RFC8480 is to perform a 3-step ADD transaction on receiving an empty cell with RC_SUCCESS to an (2-step) ADD request.
If the responder doesn't have enough cells, it will return an empty cell list as the candidate cell list in its response.

Best,
Yatch

> On Aug 14, 2019, at 19:03, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
> 
> I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS
> 
> ________________________________________ 
> 
> Thomas Watteyne, PhD 
> Sr Research Scientist & Innovator, Inria 
> Sr Networking Design Eng, Analog Devices 
> Founder & Advisor, Wattson Elements/Falco
> Founder & co-lead, UC Berkeley OpenWSN 
> Co-chair, IETF 6TiSCH 
> 
> www.thomaswatteyne.com 
> ________________________________________ 
> 
> De: "tengfei chang" <tengfei.chang@gmail.com>
> À: "Thomas Watteyne" <thomas.watteyne@inria.fr>
> Cc: "6tisch" <6tisch@ietf.org>
> Envoyé: Mercredi 14 Août 2019 08:46:25
> Objet: Re: [6tisch] draft-ietf-6tisch-msf-06 is published
> Hi Thomas,
> 
> Yes, you understood correctly.
> 
> There are two related part in RFC8480 mentioned this case: 
> 
> Upon receiving the request, node B checks to see if the length of the
>    Candidate CellList is greater than or equal to NumCells.  Node B's SF
>    verifies that all the cells in the Relocation CellList are scheduled
>    with node A and are associated with the options specified in the
>    CellOptions field.  If either check fails, node B MUST send a 6P
>    Response to node A with return code RC_ERR_CELLLIST.  If both checks
>    pass, node B's SF verifies which of the cells in the Candidate
>    CellList it can install in its schedule.  How that selection is done
>    is specified in the SF and is out of scope for this document.  That
>    verification for the Candidate CellList can succeed (NumCells cells
>    from the Candidate CellList can be used), fail (none of the cells
>    from the Candidate CellList can be used), or partially succeed (fewer
>    than NumCells cells from the Candidate CellList can be used).  In all
>    cases, node B MUST send a 6P Response that includes a return code set
>    to RC_SUCCESS and that specifies the list of cells that will be
>    rescheduled following the CellOptions field.  That list can contain
>    NumCells elements (succeed), 0 elements (fail), or between 0 and
>    NumCells elements (partially succeed).  If N < NumCells cells appear
>    in the CellList, this means that the first N cells in the Relocation
>    CellList have been relocated and the remainder have not.
> 
> 
> Here it clarified the return code for this case MUST be RC_SUCCESS. 
> I would say it may implies that the case should be the option 1 I mentioned above.
> 
> Another part in concurrent 6P transaction section, it says: 
> 
>  If a
>    node does not have enough resources to handle concurrent 6P
>    Transactions from different neighbors, it MUST reply with a 6P
>    Response with return code RC_ERR_BUSY (as per Figure 38 in
>    
> Section 6.2.4). 
> 
> I says 
> 
> enough resources to handle concurrent 6P Transactions, 
> 
> but the option 2 I mentioned doesn't need to be concurrent 6P transaction. 
> Also the RC_BUSY doesn't sound the right return code name for this case.
> 
> So does the RC_BUSY is the return code for option 2 I mentioned?
> 
> Tengfei
> 
> 
> On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
> Tengfei,
> 
> Trying to understand you point about " handle Sixtop ADD Response with return code SUCCESS but 0 cells in cellList"
> 
> If the response code is SUCCESS, IMO that means option 1. if option 2 is happening (I assume you mean "there is no memory for allocating more cells"), I would expect another return code, no?
> 
> THomas
> 
> 
> 
> ________________________________________ 
> 
> Thomas Watteyne, PhD 
> Sr Research Scientist & Innovator, Inria 
> Sr Networking Design Eng, Analog Devices 
> Founder & Advisor, Wattson Elements/Falco
> Founder & co-lead, UC Berkeley OpenWSN 
> Co-chair, IETF 6TiSCH 
> 
> www.thomaswatteyne.com 
> ________________________________________ 
> 
> De: "tengfei chang" <tengfei.chang@gmail.com>
> À: "6tisch" <6tisch@ietf.org>
> Envoyé: Lundi 12 Août 2019 08:52:37
> Objet: [6tisch] draft-ietf-6tisch-msf-06 is published
> Dear all,
> The  draft-ietf-6tisch-msf-06 is just published, it mainly resolved what we discussed during the IETF meeting. 
> 
> - add rules for celllist
> - update the downstream cell adaptation strategy
> 
> 
> Right now, there is one issue remained to be resolved and I am not sure what is the right solution. So I need suggestions and feedback from you:
> 
> - handle Sixtop ADD Response with return code SUCCESS but 0 cells in cellList
> 
> There are two possible reason for this situation
> 1. the proposed celllist doesn't meet the requirement from neighbor side
> 2. there is schedule memory for adding more cells. 
> 
> For the 1st  reason, the node may try to send another 6P request later.
> For the 2nd reason, the node may switch to another parent but it's layer violated.
> 
> Any solutions for this case?
> 
> Tengfei
> 
> -- 
> Chang Tengfei,
> Postdoctoral Research Engineer, Inria
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
> 
> 
> -- 
> Chang Tengfei,
> Postdoctoral Research Engineer, Inria
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch