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 protected]>:
> 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 protected]>
> 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
> > <[email protected]> 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
> >> [email protected]
> >> https://www.ietf.org/mailman/listinfo/6tisch
> >
> >
> >
> >
> > --
> > Chang Tengfei,
> > Pre-Postdoctoral Research Engineer, Inria
> >
> > _______________________________________________
> > 6tisch mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/6tisch
> >
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
>
--
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
