Subject: [6tisch] 6P "design team" session this Friday, same time as interim meeting

From: Thomas Watteyne <[email-masked]>
Date: Wed, 14 Dec 2016 07:17:07 +0100

All,

Per our discussion at the last interim (
https://www.ietf.org/mail-archive/web/6tisch/current/msg05069.html) we will
have a discussion specific to 6P this Friday, at the same time as the
interim.

We will use the same Webex setup as the iterim
https://www.ietf.org/mail-archive/web/6tisch/current/msg05044.html.

The goal is to have an open discussion about 6P, and wrap up the draft. We
will start by the slides on 6P we haven't covered during the interim (
https://bitbucket.org/6tisch/meetings/src/master/161209_webex/).

Thomas

-- 
_______________________________________

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
_______________________________________

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 14 Dec 2016 21:21:02 +0100

Thank you, Thomas.

Let me add comments on a couple of the ppt slides in advance, which
could save time of the coming meeting, I hope...:

   The ppt sides Thomas provided:
   https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt

------------------------------------------------------------------------

(6P unclarities 2 [1/4], slide-19)

ppt> Section 4.2.2: [Q] Why must the value of SeqNum increment *by
ppt> exactly one* at each new 6P request to a certain neighbor?
ppt>
ppt> -> Why not?

I think "MUST" is too strict. I thought an idea behind that
requirement was to try to have different SeqNum to previous
requests. If this was true, "incrementing by exactly one at each new
6P request" could be just an example of implementation.

In addition, there is no validation defined in the draft to see if the
SeqNum of a receiving request is off by one from the previous one. If
it was a really "MUST" thing, some validation should be in place,
shouldn't it? But, of course, such a validation is not practical at
all since a request could be lost in the air.

I may be wrong; just wanted to know the reason of the restriction,
"MUST increment by exactly one at each new 6P request issued to the
same neighbor."

------------------------------------------------------------------------

ppt> [C] I'd suggest listing only valid combinations of CellOption
ppt> bits and mentioning others are invalid.
ppt> -> isn’t that policy?

Indeed, 6P doesn't care about the meanings of bits in CellOptions in
its operation. However, the definitions in Figure 11 are RECOMMENDED
by the draft. I cannot see any reason to have ineffective CellOptions
values separately in the recommendation...

draft> 4.2.6.  6P CellOptions
draft> (snip)
draft> Figure 11 contains the RECOMMENDED meaning of the 6P
draft> CellOptions field for the 6P STATUS and 6P LIST requests.

In this context, we may have to define a return code to respond to
CellOptions invalid to a corresponding SF, something like
RC_ERR_CELL_OPTIONS. Or, should RC_ERR (generic error) be returned? In
any case, it'd be nice to have some text on checking CellOptions value
in Section 4.3.

------------------------------------------------------------------------

(6P unclarities 2 [4/4], slide-22)

ppt> [C] I'm not sure typical use cases of the LIST operation. When
ppt> does a SF use STATUS and LIST...? I think these commands would be
ppt> useful for the purpose of management or administration. But, it's
ppt> not within the scope of SF, is it? I'd be nice that a typical use
ppt> case of LIST is provided in the text.
ppt> -> Recover after reset

Such recovery doesn't work due to generation inconsistency.

Let's say, there are two 6P nodes, Node A and Node B. Node A resets
after having some Add or Delete operations with node B. Now, both of
GTX and GRX on Node A are 0b00. At least GTX or GRX on Node B is
either 0b01 or 0b10.

Then, Node A sends a Status request to Node B for recovery. Node B
responds with RC_ERR_GEN since GAB and GBA of the request are zero
while node-B has non-zero GTX and/or non-zero GRX. The Status request
fails. The same thing will happen to a List request. In the end, Node
A cannot recover the cells.

Here is an excerpt of Section 4.3.11.3 of draft-03:

draft> Upon receiving a 6P message, a node MUST do the following
draft> checks:
draft>
draft> o When node B receives a 6P Request of 6P confirmation from node A,
draft>   it verifies that GAB==GRX and GBA==GTX.
draft>
draft> (snip)
draft>
draft> If any of these comparisons is false, the node has detected a
draft> schedule generation inconsistency.
draft>
draft> When a schedule generation inconsistency is detected:
draft>
draft>    o If the code of the 6P Request is different from CMD_CLEAR, the
draft>      node MUST reply with error code RC_ERR_GEN.

This is related to the topic in the thread of "Handling Inconsistent
Allocation in 6P."

------------------------------------------------------------------------

ppt> - Is there any plan for 6P to support the following cells?
ppt>
ppt>   - a cell whose macNodeAddress is a group MAC address or a
ppt>     16-bit multicast address
ppt> -> No. Use case?

A use-case in my mind is allocating cells for IPv6 multicast. RFC 4944
defines the mapping rule between IPv6 multicast address and IEEE
802.15.4 16-bit multicast address.

# I'm not sure the exact meaning of "mesh-enabled LoWPAN" in Section 9
# of RFC 4944, though... I think Section 9 could be applied to a
# 6TiSCH network.

I think this has some potential to enable to dynamically allocate
cells dedicated to ff02::1a (all-RPL-node) or ff0X::fc
(ALL_MPL_FORWARDERS), for example.

Now, I understand this is out of scope of the draft at this point as
well as allocating cells for broadcast.

I'm a person interested in multicast, by the way ;-)

------------------------------------------------------------------------

ppt> - Is there any plan for 6P to support the following cells?
ppt> (snip)
ppt>    - a dedicated TX cell to multiple recipients
ppt> -> IEEE802.15.4e question, multiple cells?

Tero told me that such a TX cell is possible as per the IEEE 802.15.4
specification.

https://www.ietf.org/mail-archive/web/6tisch/current/msg04909.html

mail> > Therefore, in theory, we may have a dedicated (non-shared) TX
mail> > cell whose macNodeAddress is the broadcast address.
mail>
mail> Yes. I.e. you are the only one allowed to send to that link, but
mail> there are multiple listeneres in there. So, as it does not have
mail> shared bit on, there will not be other transmitters, but there
mail> can be multiple listeners on it.

------------------------------------------------------------------------

ppt> - Is there any plan for 6P to support the following cells?
ppt> (snip)
ppt>    - a RX cell shared with multiple senders
ppt> -> supported

OK, then another question comes up... how is a cell having multiple
senders (or multiple recipients) allocated or deallocated?

For example, one of senders may request to delete such a cell with a
recipient. However, the recipient is not supposed to delete the cell
by the request alone since there are other senders on the cell.

If it's supported, some explanation would be needed, about how it
works, although this kind of detail may be up to SF.

This could be related to the topic about what value is set to
"macNodeAddress" as a result of 6P Add transaction.

------------------------------------------------------------------------

That's it! Thanks.

Best,
Yatch

---

From: Tengfei Chang <[email-masked]>
Date: Thu, 15 Dec 2016 17:03:03 +0100

@Thomas, Thanks a lot for the meeting!

@Yatch, I like your comments. Looking forwarding to discuss on it. Here are
two more comments(tiny) from my side :

[slide-17]

ppt>*Section 4.3*: do we wait for a link-layer ACK on the Response (or
Confirmation) before committing the transaction?
ppt> à reponse/confirmation. L2 ACK doesn’t carry any 6P meaning

I agree L2 ACK doesn't carry any 6P meaning. But the node indeed commits
the transaction (adding cell in schedule) after the ACK is sent
out/received.

[slide-21]

ppt> [Q] Are the following sentences correct? They allow a pair of nodes
ppt> to open two transactions in parallel. I think these transactions
ppy> might cause inconsistency in their schedule generations.

draft> Only a single 6P Transaction between two neighbors, in a given
draft> direction, can take place at the same time.
draft> (snip)
draft> Nodes A and B MAY support having two transactions going on at
draft> the same time, one in each direction.

ppt>      Here is a simple example in which nodes update their schedule

ppt>      generation counters after receiving a MAC-level ACK for a 6P

ppt>      Response frame:

ppt>      Step-1: Node A Send Request  (GAB=0, GBA=0) : Queued

ppt>     Step-2: Node B Send Request  (GAB=0, GBA=0) : Queued

ppt>      Step-3: Node B Recv Request                 : Send MAC-ACK

ppt>     Step-4: Node B Send Response (GAB=0, GBA=0) : Queued

ppt>      Step-5: Node A Recv Request                 : Send MAC-ACK

ppt>     Step-6: Node A Send Response (GAB=0, GBA=0) : Queued

ppt>      Step-7: Node A Recv Response                : Send MAC-ACK

ppt>      Step-8: Node B Update GTX/GRX               : (GTX=0, GRX=1)

ppt>      Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect Inconsistency

This is a good point. So this is called because the GAB/GBA is prepended
early.
At the implementation view, this could be solved to add GAB/GBA at when the
queued packet has already being chosen to sent on a cell. This will look
like the ASN in EB.

Tengfei

On Wed, Dec 14, 2016 at 9:21 PM, Yasuyuki Tanaka <
[email-masked]> wrote:

>   https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588
> abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

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

---

From: Qin Wang <[email-masked]>
Date: Thu, 15 Dec 2016 16:24:31 +0000 (UTC)

Hi Yatch and all,
I think 6top as a sublayer should support broadcast/multicast, but it may not necessary for 6P to support scheduling cells for broadcast/multicast dynamically. There may be two solutions for broadcast/multicast. One is use EB cell in slotframe 0, because it is not supposed that every EB cell will be used to broadcast TSCH EB. Another way is to use hardcell reservation.
What do you think?
ThanksQin

    On Wednesday, December 14, 2016 3:21 PM, Yasuyuki Tanaka <[email-masked]> wrote:

 Thank you, Thomas.

That's it! Thanks.

Best,
Yatch

---

From: Simon Duquennoy <[email-masked]>
Date: Fri, 16 Dec 2016 21:05:33 +0100

Hi all,

Thanks for an fruitful discussion today!

I wanted to follow up on Nicola's thoughts about adding a final 6P
Confirmation to all transactions.
There is a fundamental difference in having a 2-way vs 3-way transaction:
* 2-way: at the end, the initiator A either (1) commits but does not
know B's state or (2) knows both agreed to abort.
* 3-way: at the end, the initiator A either (1) aborts but does not
know B's state or (2) knows both agreed to commit.

In the 2-way case, the initiator never has the guarantee of a successful commit.
In the 3-way case, a SF could choose to re-attempt a transaction
hoping to reach an agreement to commit. The SF can retry as many times
as it sees fit, and CLEAR should it not reach an agreement.

Details below:

2-way transaction:
PoV of A:
* Aborts if not getting Response:
  => Sends no ACK. Knows B also aborts.             <<< agree to abort
* Commits if getting Response:
  => Sends an ACK. Does not know B's final state.   <<< !uncertainty!
PoV of B:
* Aborts if Response not ACKed:
  => Does not know A's final state.                 <<< !uncertainty!
* Commits if Response ACKed:
  => Knows A also committed.                        <<< agree to commit

3-way transaction:
PoV of A:
* Aborts if Confirmation not ACKed:
  => Does not know B's final state.                 <<< !uncertainty!
* Commits if Confirmation ACKed:
  => Knows B also committed.                        <<< agree to commit
PoV of B:
* Aborts if not getting Confirmation:
  => Sends no ACK. Knows A also aborts.             <<< agree to abort
* Commits if getting Confirmation:
  => Sends an ACK. Does not know A's final state.   <<< !uncertainty!

Thanks,
Simon

On Thu, Dec 15, 2016 at 5:03 PM, Tengfei Chang <[email-masked]> wrote:
> ppt>Section 4.3: do we wait for a link-layer ACK on the Response (or
> I agree L2 ACK doesn't carry any 6P meaning. But the node indeed commits the
> transaction (adding cell in schedule) after the ACK is sent out/received.
>
> [slide-21]
>
> On Wed, Dec 14, 2016 at 9:21 PM, Yasuyuki Tanaka
> <[email-masked]> wrote:
>>
>> Thank you, Thomas.
>>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 16 Dec 2016 18:20:01 -0300

Dear all,
              From the part of the meeting I could attend,
I could not detect an agreement on the timeout calculation,
as 6P requires. Can we discuss this on the ML?
Regards,

                                     Diego

2016-12-16 17:05 GMT-03:00 Simon Duquennoy <[email-masked]>:

> the
> >> https://bitbucket.org/6tisch/meetings/raw/
> c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/
> slides_161209_webex.ppt
> >>

-- 
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Qin Wang <[email-masked]>
Date: Fri, 16 Dec 2016 21:51:39 +0000 (UTC)

Hi Simon,
I agree to your detailed analysis about with/without adding Confirmation. I would like add the possible processes after the transactions.
After 2-way transaction, node A will find the inconsistency by generation counter when it starts a new transaction.  And then, node A can send CLEAR to node B. There is a side-effect: if node A uses the new cells for data before it starts a new transaction in which node A finds out the inconsistency, failure of data communication will happen.
After 3-way transaction, node A can send CLEAR to node B or re-attempt transaction immediately if the ACK for Confirmation does not come. But it may be a over-reaction, because no ACK for Confirmation just means Uncertainty.
Bottom line is both of the two schemes work and both of them are not perfect.
Thought?
ThanksQin

    On Friday, December 16, 2016 3:05 PM, Simon Duquennoy <[email-masked]> wrote:

 Hi all,

Details below:

2-way transaction:
PoV of A:

3-way transaction:
PoV of A:

Thanks,
Simon

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Mon, 19 Dec 2016 12:18:09 +0100

Hi,

I tried to summarize the action items we identified during the call. Please
comment if you do not agree. Here a list:

1 clarify the use of RC_END_OF_LIST text upon receiving a list command and
reaching the end of the list

2 Clarify that if a node has too many cells to add that do not fit in the
packet, the node has to issue multiple ADD requests.
    * add a section saying what happens if you have to many cells to add.

3 Detail 3-way transaction as 2 way is done (4.3.7.  Adding Cells with
2-way Transaction). Explain how 3-way transaction works in the same manner
as it is done in 4.3.7 for 2-way transaction.

4 Add sentence detailing why there is a 3-way transaction and what it
enables --> add an example use case -> why use 3-way:
  -> It is useful when:
        - when we want the destination to select candidate cells,
        - when the origin doesn't care which cells to be allocated.
        - when the destination is not able to allocate the requested cells.
        - the selection of the transaction type is up to the SF.

5 Clarify in the case of 2-WAY and 3-WAY transaction what happen if a
requesting node cannot be allocated any cell in the destination.

6 Indicate that we wait for link layer ACK at the 6P transaction to commit.
-> In a response the node commits after succesful transmission.
They will commit at the end of the slot.

7- Add a section describing when there is a real inconsistency after all
the retransmissions failed.

8- Merge GBA GAB using 2 bits and rename it as Generation. We update it
when we commit. Use lolipop counter (0, 1-2). GTX and GRX are also merged
and renamed to Generatin counter.

9-RELOCATION: content-> what cell to relocate.
relocation request uses first cell of the cell list to indicate the cell to
be moved. The rest of the cells are candidate cells being proposed. if it
is empty the other side decides.

10-Add error code for figure 6 when the response is proposing other cells
as there is no match -> add error RC_NOMATCH
* In STATUS and list commands return the content in the payload but also
return an error code in case of the schedule mismatch.

Items that for me are not still clear:

11- Handling multiple SFs in LIST, STATUS. The SFID represents the used SF.
Indicate that if 0xFFFF is used as SFID in the LIST, STATUS query, the
response includes all cells handled by the different SFs.

12- Indicate that it is recommended that when a cell is allocated by a
particular SF, the SFID needs to be stored together with the cell
information. This is useful when multiple SFs are running in parallel.

13- Say maybe that multiple SFs cannot be modifiying the same slotframe?

impact on minimal ->
14- minimal slotframe handle -> move from 0 to 0x80. This is to enable
higher priority slotframes to be added. If not minimal will always be the
highest priority. Alternative. Do not say which handle minimal uses and let
it be chosen by the network operator. This is announced in the EB so can be
changed. Maybe say default value but others can be used and properly
announced in the EB.

regards,
Xavi

2016-12-16 22:51 GMT+01:00 Qin Wang <[email-masked]>:

> Hi Simon,
>
> I agree to your detailed analysis about with/without adding Confirmation.
> I would like add the possible processes after the transactions.
>
> After 2-way transaction, node A will find the inconsistency by generation
> counter when it starts a new transaction.  And then, node A can send CLEAR
> to node B. There is a side-effect: if node A uses the new cells for data
> before it starts a new transaction in which node A finds out the
> inconsistency, failure of data communication will happen.
>
> After 3-way transaction, node A can send CLEAR to node B or re-attempt
> transaction immediately if the ACK for Confirmation does not come. But it
> may be a over-reaction, because no ACK for Confirmation just means
> Uncertainty.
>
> Thanks
> Qin

-- 
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: Qin Wang <[email-masked]>
Date: Mon, 19 Dec 2016 16:44:40 +0000 (UTC)

Hi Xavi,

Thanks for the summary. Please see inline.

>
>
>I tried to summarize the action items we identified during the call. Please comment if you do not agree. Here a list:
>
>
>1 clarify the use of RC_END_OF_LIST text upon receiving a list command and reaching the end of the list
[Qin]: agree
>
>2 Clarify that if a node has too many cells to add that do not fit in the packet, the node has to issue multiple ADD requests. 
[Qin]: agree
>
>3 Detail 3-way transaction as 2 way is done (4.3.7.  Adding Cells with 2-way Transaction). Explain how 3-way transaction works in the same manner as it is done in 4.3.7 for 2-way transaction. 

[Qin]: agree
>>4 Add sentence detailing why there is a 3-way transaction and what it enables --> add an example use case -> why use 3-way: 
>  -> It is useful when:

[Qin]: Remove the second scenario, Because when the origin doesn't care which cells to be allocated, the origin node can use 2-way transaction as well.

>        - when the destination is not able to allocate the requested cells.>        
>        - the selection of the transaction type is up to the SF.>
>
>5 Clarify in the case of 2-WAY and 3-WAY transaction what happen if a requesting node cannot be allocated any cell in the destination.

[Qin]: I think it is a case different from pure 2-way and 3-way cases. The origin node starts a 2-way transaction, but ends up 3-way transaction because the destination node cannot allocate any cell from the candidate celllist. Should we use another name for it to distinguish from pure 3-way transaction?
>>6 Indicate that we wait for link layer ACK at the 6P transaction to commit. -> In a response the node commits after succesful transmission.

[Qin]: agree
>>7- Add a section describing when there is a real inconsistency after all the retransmissions failed.
>

[Qin]: agree
>>8- Merge GBA GAB using 2 bits and rename it as Generation. We update it when we commit. Use lolipop counter (0, 1-2). GTX and GRX are also merged and renamed to Generatin counter.

[Qin]: agree
>relocation request uses first cell of the cell list to indicate the cell to be moved. The rest of the cells are candidate cells being proposed. if it is empty the other side decides.

[Qin] propose that relocation request can use NumCells to indicate how many cells need to be removed, and accordingly, uses the first NumCells cells in the celllist to indicate the cells to be removed, the rest of cells are candidate cels being proposed. Thought?
>>10-Add error code for figure 6 when the response is proposing other cells as there is no match -> add error RC_NOMATCH
>
>* In STATUS and list commands return the content in the payload but also return an error code in case of the schedule mismatch.

[Qin]: I think it happens when Generation counter is mismatched>

>11- Handling multiple SFs in LIST, STATUS. The SFID represents the used SF. Indicate that if 0xFFFF is used as SFID in the LIST, STATUS query, the response includes all cells handled by the different SFs.
>

[Qin]: agree>
>12- Indicate that it is recommended that when a cell is allocated by a particular SF, the SFID needs to be stored together with the cell information. This is useful when multiple SFs are running in parallel.

[Qin]: Considering #11, I think it has to be a strong recommendation.>

[Qin]: agree>
>impact on minimal ->
>
>14- minimal slotframe handle -> move from 0 to 0x80. This is to enable higher priority slotframes to be added. If not minimal will always be the highest priority. Alternative. Do not say which handle minimal uses and let it be chosen by the network operator. This is announced in the EB so can be changed. Maybe say default value but others can be used and properly announced in the EB.

[Qin]: agree to "Alternative">
Thanks
Qin