Subject: Re: [6tisch] 6P unclarities

From: Thomas Watteyne <[email-masked]>
Date: Fri, 9 Dec 2016 15:15:38 +0100

Simon, Yatch,
We are planning to discuss these points during the 6TISCH call in 45min.
Thomas

On Wed, Nov 23, 2016 at 2:12 AM, Yasuyuki Tanaka <
[email-masked]> wrote:

> Hi all,
>
> I also have comments on draft-ietf-6tisch-6top-protocol-03; some of
> them are covered by Simon. :-)
> # I put a tag for each item: [C] for comment/suggestion, [Q] for
> # question.
>
> * Section 4.2.2:
>
> - [Q] Why must the value of SeqNum increment *by exactly one* at each
>       new 6P request to a certain neighbor?
>
> * Section 4.2.6:
>
> - [C] There are ineffective combinations of CellOptions in Figure 11,
>       for example, "TX=0,RX=0,S=1".
>
> - [C] I'd suggest listing only valid combinations of CellOption bits
>       and mentioning others are invalid.
>
> - [C] The phrase, "marked as", in Figure 11 is a bit ambiguous... Something
>       like "its linkOptions matches exactly" is better?
>
> * Section 4.2.13:
>
> - [C] The length of "Num. Cells" is 2-octet long in the text, but
>       1-octet in the figure.
>       # The Wirehark patch for draft-03 treats the field as a
>       # one-octet field.
>
> draft> When responding to an STATUS request, the "Other Field"
> draft> contains the number of cells scheduled between node A and node
> draft> B that match the CellOptions field, encoded as a 2-octet
> draft> unsigned integer.  This is shown in Figure 12.
> draft>
> draft>                       1                   2                   3
> draft>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> draft>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> draft>  |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
> draft>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> draft>  | Num. Cells    |
> draft>  +-+-+-+-+-+-+-+-+
> draft>
> draft>                              Figure 12
>
> * Section 4.3:
>
> simon> do we wait for a link-layer ACK on the Response (or
> simon> Confirmation) before committing the transaction?
>
> I came up with the same question while thinking about the
> inconsistency handling thing.
>
> - [C] I guess, most of implementation send a data frame with an
>       acknowledged transmission. But, according to IEEE 802.15.4, it
>       seems an option even for the Data frame. If a 6P frame is always
>       expected to require a MAC level acknowledgement, it'd be better
>       to mention like, "a 6P frame SHOULD/MUST have one in the AR
>       field".
>
> - [Q] If yes to the question by Simon, is it a right thing for 6P, an
>       upper layer protocol on IEEE 802.15.4 MAC, to use the MAC level
>       acknowledgement as signaling for its own purpose?
>
> - [C] If an operation is executed after sending a response, I guess so
>       as per 4.3.11, the description of RC_SUCCESS in Figure 9 would
>       need to be updated. Strictly speaking, an ADD/DELETE/CLEAR
>       operation is yet to be done at the time of sending a response
>       with RC_SUCCESS to a corresponding request. The current
>       description for RC_SUCCESS is "operation succeeded".
>
> * Section 4.3.3:
>
> - [Q] Are the following sentences correct? They allow a pair of nodes
>       to open two transactions in parallel. I think these transactions
>       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.
>
>       Here is a simple example in which nodes update their schedule
>       generation counters after receiving a MAC-level ACK for a 6P
>       Response frame:
>
>       Step-1: Node A Send Request  (GAB=0, GBA=0) : Queued
>       Step-2: Node B Send Request  (GAB=0, GBA=0) : Queued
>
>       Step-3: Node B Recv Request                 : Send MAC-ACK
>       Step-4: Node B Send Response (GAB=0, GBA=0) : Queued
>       Step-5: Node A Recv Request                 : Send MAC-ACK
>       Step-6: Node A Send Response (GAB=0, GBA=0) : Queued
>
>       Step-7: Node A Recv Response                : Send MAC-ACK
>       Step-8: Node B Update GTX/GRX               : (GTX=0, GRX=1)
>       Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect Inconsistency
>
> * Section 4.3.10
>
> - [C] I'm not sure typical use cases of the LIST operation. When does
>       a SF use STATUS and LIST...? I think these commands would be
>       useful for the purpose of management or administration. But,
>       it's not within the scope of SF, is it? I'd be nice that a
>       typical use case of LIST is provided in the text.
>
> * General / open:
>
> simon> is there any option to install broadcast cells? (a bit tricky
> simon> as this needs consensus over 2+ nodes, this probably takes a
> simon> 2PC or 3PC, but can be needed)
>
> +1.
>
> - [C] The draft implies that a MAC address of the peer is set to the
>       "macNodeAddress" attribute of a allocated cell. If this is the
>       case, it'd be better to mention that in the text.
>
> I have a couple of related questions in addition to what Simon asked:
>
> - [Q] What if a node has a short address as well as an extended
>       address?
>
> - [Q] Is there any plan for 6P to support the following cells?
>       - a cell whose macNodeAddress is a group MAC address or a 16-bit
>         multicast address
>       - a dedicated TX cell to multiple recipients
>       - a RX cell shared with multiple senders
>
> That's all! Thank you!!
>
> Best,
> Yatch
>
>
> On 2016/11/22 20:40, Simon Duquennoy wrote:
>
>> Hi all,
>>
>> Reading the current draft draft-ietf-6tisch-6top-protocol-03, a few
>> points were not clear to me:
>>
>> * Section 4.2.7: why do cells only have a recommended format? I guess
>> it's up to the SF, but if so, this is worth stating explicitly.
>>
>> * Section 4.2.7: what happens when cells don't fit a single packet?
>> This was answered here [1] but I couldn't find any info in the text.
>>
>> * Section 4.3: protocol behavior. only 2-way transactions are
>> detailed, why not 3-way?
>>
>> * Section 4.3: when to use 2 or 3-way transactions? Is the latter for
>> added reliability or only to handle the case where the request has
>> CellList == []. Clarification needed IMO.
>>
>> * Section 4.3: do we wait for a link-layer ACK on the Response (or
>> Confirmation) before committing the transaction?
>>
>> * Section 4.3: no description of the STATUS command?
>>
>> * Section 4.3.2: interaction among different SFs: does LIST return
>> only the current SF's cells or all cells in the system? Can DELETE
>> remove cells installed by other SFs? Does CLEAR clear cells installed
>> by other SFs?
>>
>> * Section 4.3.11.1: single bit for the GTX/GRX count value means two
>> consecutive failed transactions will be forever unnoticed. Is that ok?
>> Couldn't we use a single 4-bit counter instead of two 2-bit? Wouldn't
>> a simple counter work instead of lollipop?
>>
>> * Terminology: I've seen both "2-steps" and "2-ways" used in the document
>>
>> * General / open: is there any option to install broadcast cells? (a
>> bit tricky as this needs consensus over 2+ nodes, this probably takes
>> a 2PC or 3PC, but can be needed)
>>
>> * General / open: should we recommend / force having at least one
>> rendez-vous cell (via minimal or otherwise), so as to guarantee
>> reachability of all nodes? Else, a single failed CLEAR transaction
>> results in definitive loss of connectivity between two nodes.
>>
>> Apologies if this was covered in previous discussions I might have
>> missed. Please let me know if I should have opened tickets on the
>> issue tracker instead.
>>
>> Thanks,
>> Simon
>>
>> [1] https://www.ietf.org/mail-archive/web/6tisch/current/msg04758.html
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
_______________________________________

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: Simon Duquennoy <[email-masked]>
Date: Fri, 9 Dec 2016 15:31:22 +0100

Talk to you then!
Simon

On Fri, Dec 9, 2016 at 3:15 PM, Thomas Watteyne
<[email-masked]> wrote:
> On Wed, Nov 23, 2016 at 2:12 AM, Yasuyuki Tanaka
> <[email-masked]> wrote:
>>
>> Hi all,
>>