@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 < yasuyuki9.tan...@toshiba.co.jp> 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 > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch