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

From: Tengfei Chang <[email-masked]>
Date: Mon, 12 Aug 2019 17:52:37 +0200

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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 14 Aug 2019 16:45:12 +0200 (CEST)

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" <[email-masked]>
> À: "6tisch" <[email-masked]>
> Envoyé: Lundi 12 Août 2019 08:52:37
> Objet: [6tisch] draft-ietf-6tisch-msf-06 is published

> 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

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

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

---

From: Tengfei Chang <[email-masked]>
Date: Wed, 14 Aug 2019 17:46:25 +0200

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 <https://tools.ietf.org/html/rfc8480#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 <[email-masked]>
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
>
>
>
> ------------------------------
>
> *De: *"tengfei chang" <[email-masked]>
> *À: *"6tisch" <[email-masked]>
> *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

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 14 Aug 2019 19:03:21 +0200 (CEST)

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

Thomas Watteyne, PhD 

www.thomaswatteyne.com 

> À: "Thomas Watteyne" <[email-masked]>
> Cc: "6tisch" <[email-masked]>
> Envoyé: Mercredi 14 Août 2019 08:46:25
> Objet: Re: [6tisch] draft-ietf-6tisch-msf-06 is published

> I would say it may implies that the case should be the option 1 I mentioned
> above.

>   Response with return code RC_ERR_BUSY (as per Figure 38 in [
>    https://tools.ietf.org/html/rfc8480#section-6.2.4 | Section 6.2.4 ] ).

> On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne < [
> mailto:[email-masked] | [email-masked] ] > wrote:

>> happening (I assume you mean "there is no memory for allocating more cells"), I
>> would expect another return code, no?

>> [ http://www.thomaswatteyne.com/ | www.thomaswatteyne.com ]

>>> De: "tengfei chang" < [ mailto:[email-masked] | [email-masked]
>>> ] >
>>> À: "6tisch" < [ mailto:[email-masked] | [email-masked] ] >

>>> [ mailto:[email-masked] | [email-masked] ]
>>> [ https://www.ietf.org/mailman/listinfo/6tisch |
>>> https://www.ietf.org/mailman/listinfo/6tisch ]

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 14 Aug 2019 19:50:07 +0200

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 <[email-masked]> wrote:
> 
> I would say it may implies that the case should be the option 1 I mentioned above.
> 
> Section 6.2.4). 
> On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne <[email-masked]> wrote:
> Tengfei,
> 
> Trying to understand you point about " handle Sixtop ADD Response with return code SUCCESS but 0 cells in cellList"
> 
> The  draft-ietf-6tisch-msf-06 is just published, it mainly resolved what we discussed during the IETF meeting. 
> 
> - add rules for celllist
> 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:
> 
> For the 2nd reason, the node may switch to another parent but it's layer violated.
>