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 <simon...@sics.se>
wrote:
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 <tengfei.ch...@inria.fr> wrote:
> @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/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
>>
>> _______________________________________________
>> 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
>
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
