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

[Tengfei Chang <[e-mail]>]

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

> 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/c9bd4d78fa452a0588
> abefc104d08520d32e0c26/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
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>



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