Re: [6tisch] Progressing draft-tiloca-6tisch-robust-scheduling

[Yasuyuki Tanaka]

Hi Marco,

Although I'm still not sure how effective the selective jamming attack 
is in reality, the proposed operation is considered as part of the 
6TiSCH scheduling function.


> At IETF 105, this work was put on hold, without proceeding to check
> for WG adoption as requested by the authors. The reasons were: i)
> possible termination of the WG later in 2019; ii) possible better
> belonging of this work to IEEE rather than IETF.
> ...
> 1) I do believe that this document belongs to the IETF and its
> 6TiSCH WG.

Then, regarding ii), I agree with you.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

[Yasuyuki Tanaka]

Hi Tengfei,

If NumTX is one-byte long, which is recommended, it won't reach 256 
(MAX_NUMTX):

  ...  When
   NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided by
   2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and
   NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one
   frame is sent to the parent with an Acknowledgment received.

It would be nicer to avoid a potential coding error taking the text 
literally, checking if a 8-bit unsigned integer variable is equal to 
256, even although a smart compiler may give a warning or end with an error.


With MAX_NUMTX of 255, the resulting NumTx by division is then 127, by 
the way :-)


> Even NumTx is recommended to use 1 byte later,  when comparing NumTx
> and MAX_NUMTX, a casting can be applied and doesn't break 1 byte
> torage of NumTx.

Yes, this is one of ways of implementation.

Thank you!
Yatch

On 12/13/2019 1:06 AM, Tengfei Chang wrote:

Yatch,

 >    2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and
--> "..., when MAX_NUMTX is set to 255, ..."

For the whole sentence,

/"when NumTx reaches MAX_NUMTX, both NumTx and NumTxAck MUST be divided 
by 2/
/For example, when MAX_NUMTX is set to 256, from NumTx=255 and 
NumTxAck=127, the counters become NumTx=128 and NumTxAck=64 if one frame 
is sent to the parent with an Acknowledgment received."/


In this case, MAX_NUMTX should be set to 256.

Even NumTx is recommended to use 1 byte later,  when comparing NumTx and 
MAX_NUMTX, a casting can be applied and doesn't break 1 byte storage of 
NumTx.


Tengfei

On Fri, Dec 13, 2019 at 9:57 AM Tengfei Chang <mailto:tengfei.ch...@gmail.com>> wrote:


Thanks Yatch!  I will have those comments integrated into next version.



---- Original message 
From: Yasuyuki Tanaka mailto:yasuyuki.tan...@inria.fr>>
Date: Fri, Dec 13, 2019, 12:01 AM
To: Tengfei Chang mailto:tengfei.ch...@gmail.com>>
Cc: 6tisch@ietf.org <mailto:6tisch@ietf.org>,
yasuyuki.tan...@inria.fr <mailto:yasuyuki.tan...@inria.fr>
Subject: Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

Hi Tengfei,

Thank you for the updates. The new version addresses my
comments. Here
are a couple of trivial comments:

 > (Section 5.1)
 >    The node MUST maintain the following counters for the
selected parent
 >    on both negotiated Tx and Rx cells:

To my understanding, we have separate pairs of NumCellsElapsed and
NumCellsUsed for the negotiated TX cell and the negotiated RX
cell. It
would be better to modify the sentence a little bit like:

--> "The node MUST maintain the following counters for each of the
negotiated Tx cells, and the negotiated RX cells, that are
scheduled
with the selected parent."

 > (Section 5.3)
 >    2.  For example, when MAX_NUMTX is set to 256, from
NumTx=255 and

--> "..., when MAX_NUMTX is set to 255, ..."

Best,
Yatch



--
——

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/ <http://www.tchang.org/>
——


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC on draft-ietf-6tisch-msf-09

[Yasuyuki Tanaka]

Hi Tengfei,

Thank you for the updates. The new version addresses my comments. Here 
are a couple of trivial comments:



(Section 5.1)
   The node MUST maintain the following counters for the selected parent
   on both negotiated Tx and Rx cells:


To my understanding, we have separate pairs of NumCellsElapsed and 
NumCellsUsed for the negotiated TX cell and the negotiated RX cell. It 
would be better to modify the sentence a little bit like:


--> "The node MUST maintain the following counters for each of the 
negotiated Tx cells, and the negotiated RX cells, that are scheduled 
with the selected parent."



(Section 5.3)
   2.  For example, when MAX_NUMTX is set to 256, from NumTx=255 and


--> "..., when MAX_NUMTX is set to 255, ..."

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Yasuyuki Tanaka]

Thank you, Tengfei.

> On Dec 6, 2019, at 22:49, Tengfei Chang  wrote:
> 
> Handling DSCP value will be a per-packet process. Can we pass DCSP value 
> to the TSCH layer using the interface for transmission defined by 
> IEEE802.15.4? I don't think so.
>  
> TC: Not sure this is a standard way to do so. For implementing, tut this 
> value or a flag could have a default value.
> TC: If this value is not given, i.e. frame from IEEE802.15.4 layer, just use 
> the default value.

What we would do are:

- 1. don't update NumCellsUsed for AF43 packets, otherwise update them
- 2. don't update NumTX/NumTxAck for AF43 packets, otherwise update them

The first one may cause undesirable deallocations. If a node has relayed join 
request continuously for a certain period of time, the computed cell 
utilization (NumCellsUsed / NumCellsElapsed) goes down, then a negotiated TX 
cell will be deleted, even if the negotiated TX cell was scheduled to handle 
application traffic to forward. This behavior may degrade end-to-end 
reliability.

The second one may prevent the node from monitoring link PDRs on scheduled 
cells correctly. This could affect the scheduling collision detection.

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Hi Tengfei,

How do we distinguish multiple MSF sessions?
What if two MSF sessions have a same "selected parent", and then one of 
them selects another selected parent? How many negotiated cells should 
be taken over to the new selected parent?


These are not covered by the current text, and I think they are out of 
the scope of MSF.



This specification only describes how MSF works with one routing parent, which is phrased 
as "selected parent".


So, yes, I believe we should have this case only in the text. If we 
mention some other possibilities without concrete ideas to implement, 
they would just confuse future readers.


I think, Pascal has a different opinion.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Yasuyuki Tanaka]

Hi Pascal, Tengfei,

On 12/6/2019 6:48 PM, Tengfei Chang wrote:
Yes, MSF indeed aware of the routing information such as RPL parent, I 
consider this is like an information stored at IPv6 layer that MSF can 
read it from without touching the frame L2 payload.
In such sense, I could consider the DSCP value can be another 
information stored at upper layer that MSF have read access to it..


I think these two are different things...

Handling DSCP value will be a per-packet process. Can we pass DCSP value 
to the TSCH layer using the interface for transmission defined by 
IEEE802.15.4? I don't think so.


I don't see any problem in allocating additional cells for "acceptable" 
amount of traffic including relayed join requests. To prevent 
application packet drops, such allocations could be a good thing.


Rather than giving some L3 information to L2, the L3 may need L2 
information, like available bandwidth (cells) for a certain link. For 
the MSF case, if the IPv6 layer on an intermediate node limits outgoing 
traffic of relayed join requests below 20% of available bandwidth, 
undesired cell allocations could be avoided, assuming 
LIM_NUMCELLSUSED_HIGH is 75% and the link has almost the perfect link PDR.


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Yasuyuki Tanaka]

Hi Malisa.

Thanks to your explanation, I get the point.


how could we ensure that the “acceptable” amount of unauthenticated traffic 
that actually gets forwarded does not trigger cell allocation?


It'd be fine to trigger cell allocations by *acceptable* amount of 
unauthenticated traffic if necessary. Otherwise, important packets, 
authenticated traffic for applications, could be dropped because of no 
room in the TX queue filled with unauthenticated packets.


Or, the intermediate route should drop more "unauthenticated" traffic if 
you don't want to trigger. But, even doing this, we cannot ensure the 
first relayed join request since the last hour or year does not trigger 
a cell allocation.



The cells used to transport the join traffic will be marked as used by MSF, and 
depending on the amount of regular traffic as well as the join rate limit, this 
may cause the cell allocation threshold to be surpassed. Right?


Yes, it causes another cell allocation.

Any L2 component including MSF doesn't case about information in the MAC 
frame payload field, although MSF (a 6TisCH scheduling function) is not 
on the path of outgoing packets in the protocol stack:



https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-3.7
  +++
  | Applis |  CoJP  |
  +++--+-+
  | CoAP / OSCORE   |  6LoWPAN ND  | RPL |
  +-+--+-+
  |   UDP   |  ICMPv6|
  +-++
  | IPv6 |
  +--+--+
  | 6LoWPAN HC   /   6LoRH HC| Scheduling Functions |
  +--+--+
  |   6top inc. 6top protocol   |
  +-+
  | IEEE Std. 802.15.4 TSCH |
  +-+

  Figure 4: 6TiSCH Protocol Stack

Thank you, again!
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF adapts to traffic only for secured packets

[Yasuyuki Tanaka]

Hi,

On 12/5/2019 5:17 PM, Tengfei Chang wrote:
Does anyone know other way to make the SF not adapt to unsecured traffic 
without knowing upper layer field?


I have no idea...

Why can't the "join rate" avoid such undesired cell allocations? If the 
join rate is properly configured, incoming join requests don't cause 
such allocations, do they?



https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-14#section-8.4
   o  join rate: Average data rate (in units of bytes/second) of join
  traffic forwarded into the network that should not be exceeded
  when a joined node operates as a JP, encoded as an unsigned
  integer.


https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-14#section-7.2
   The PROBING_RATE value at the JP is controlled by the join rate
   parameter, see Section 8.4.2.  Following [RFC7252], the average data
   rate in sending to the JRC must not exceed PROBING_RATE.  For
   security reasons, the average data rate SHOULD be measured over a
   rather short window, e.g.  ACK_TIMEOUT, see Section 9.

The recommended PROBING_RATE is 1 byte/second. I'm not sure how to 
interpret this value, though The time window to calculate the "rate" 
should be small enough, I believe.


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Yatch's review on draft-ietf-6tisch-msf-08 - Re: MSF review

[Yasuyuki Tanaka]

Hi Tengfei,

Related to MAX_NUMCELLS, LIM_NUMCELLSUSED_HIGH and LIM_NUMCELLSUSED_LOW 
need to be revisited.


In Section 5.1., these values are used in the following way:

   The counters are used as follows:

   1.  Both NumCellsElapsed and NumCellsUsed are initialized to 0 when
   the node boots.
   2.  When the value of NumCellsElapsed reaches MAX_NUMCELLS:

   *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
  single cell to the preferred parent
   *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
  single cell to the preferred parent
   *  Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
  step 2.

NumCellUsed should have an integer value which is equal to or greater 
than 0. Then, LIM_NUMCELLSUSED_HIGH and LIM_NUMCELLSUSED_LOW should be 
the same type of value. However, these recommended values are expressed 
in percentage, which cannot be compared directly with NumCellsUsed.


   Figure 2 lists MSF Constants and their RECOMMENDED values.

   +--+---+
   | Name | RECOMMENDED value |
   +--+---+
   | NUM_CH_OFFSET|   16  |
   | KA_PERIOD|1 min  |
   | LIM_NUMCELLSUSED_HIGH|   75 %|
   | LIM_NUMCELLSUSED_LOW |   25 %|

A correction would be either replacing NumCellsUsed in Section 5.1 with 
(NumCellsUsed / NumCellsElapse), or removing '%' in Figure 2 with 
changing the recommended values to something which can work with a 
recommended value of MAX_NUMCELLS.


On 11/27/2019 9:05 PM, Tengfei Chang wrote:

By the way, the default or recommended value of MAX_NUMCELLS is 8?
MAX_NUMCELLS is not listed in Figure 3.


TC: 8 is just a value in the example, not recommended. For periodic 
traffic, or traffic load changes slowly, a larger MAX_NUMCELLS is preferred.
Some proposal for the recommended value of MAX_NUMCELLS: 64 (power of 
2), or 100.


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Thank you, Pascal for your comment.

On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:

RPL underneath is designed to operate with multiple parents, and for a good 
reason.


I understand that point.

My point is, rephrasing the word alone couldn't be enough.


Bandwidth allocation doesn’t care what traffic that is or it’s direction. It 
cares about the amount of traffic that needs to circulate over the hop.


In general, yes. According to the current text of MSF, the direction is 
relevant. For a upward neighbor, MSF allocates one negotiated TX cell 
just after recognizing it. For a downward neighbor, it doesn't.


On parent switch, the number of negotiated cells is carried over to a 
new parent. But what if a node has one parents at some point, then it 
selects an additional parent to handle some portion of traffic? How many 
negotiated cells should be scheduled with the new (additional) parent? 
MSF would have no idea.


To me, this seems a totally new thing to MSF.

Again, having multiple MSF instances could be a solution, which doesn't 
need the rephrasing.



And it is possible to run an MSF session at L2 with each of them totally 
independently.


What do you mean by "MSF session"? If you have multiple MSF instances 
with different SFIDs or values for the Metadata field, they can be 
associated with different RPL DODAGsm and they will work independently.


On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> Would it be then a neighbour instead of a parent? (Assuming the
> neighbour has joined the network)

I don't think so.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] MSF Shepherd review

[Yasuyuki Tanaka]

Hi Pascal,

pascal> My problem is that there’s only one preferred parent, but a
pascal> node may use several parents for data traffic. This is why we
pascal> build dodags in the first place.
pascal>
pascal> I believe that the node may allocate cells with all of those
pascal> “selected parents” if it likes. The use of “preferred parent”
pascal> in that text would prevent this.

I feel this scenario is outside of the scope of the *minimal*
scheduling function. If I remember correctly, such a case hasn't been
discussed nor evaluated with implementations.

The latest MSF spec may be able to be applied to the multiple parents
case without any modification, or may not. We don't know because we'd
not taken it into account. Regarding the multiple DODAGs case, a
possible solution is having a separate MSF instance per DODAG, using a
different SFID. Another idea is using the Metadata field to associate
a 6P transaction with a DODAG.

In any case, I prefer having "the preferred parent" in the text,
although "parent" sounds like a L3 term. L2 doesn't maintain
parent-child relationships.

My two cents.

Best,
Yatch


On 11/29/2019 4:23 PM, Pascal Thubert (pthubert) wrote:
Please do not call him preferred parent that’s something specific in 
RPL, the best parent for forwarding up the dodag.


Why not just say “the parent “ explaining that the 6P protocol can be 
used in parallel with multiple parents?



Regards,

Pascal


Le 29 nov. 2019 à 16:19, Tengfei Chang  a écrit :


Hi Pascal,

For the preferred parent issue:

When running MSF, the node is deal with one parent at a time out of 
the parent set, which we called preferred parent.

It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which 
responded in the switching_parent section in MSF.


For the sentence:

It is recommended to set MAX_NUMCELLS value at least 4x of the
maximum link traffic load of the network with unit of packets per
slotframe.


The following example helps to understand the meaning:

For example, a 2 packets/slotframe traffic load results an average
4 cells scheduled, using the value of double number of scheduled
cells (which is 8) as MAX_NUM_CELLS gives a good resolution on
cell usage calculation.

Any recommendation on the rephrasing?

Tengfei



On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert) 
mailto:pthub...@cisco.com>> wrote:


Hello Tengfei


Please see below


Le 27 nov. 2019 à 21:44, Tengfei Chang mailto:tengfei.ch...@gmail.com>> a écrit :


Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
mailto:pthub...@cisco.com>> wrote:

Dear all

__ __

Please find some comments below: 

__ __

__ __

__ __

__ __

Please migrate to XML2RFC v3. This will save time in the future.


TC: got it! Will used in version 9.


:)




__ __

__ __

__ __



   However, an implementor MAY implement MSF without
implementing

   Minimal 6TiSCH Configuration. 

__ __

__ __

This is not helpful without explanations. What is the
tradeoff? How does the  network operates in that case?


TC: Yes, the sentence is misleading. What we try to say is MSF
can work with other specifications protocols, rather then minimal
6TiSCH configuration, as long as the protocols gives a way to
communicate the EB and DIO among the network.


Those words in the draft will make me a happy shepherd...




__ __

__ __

__ __

__ __

For example, a Trickle Timer defined in

[RFC6550  ] MAY be applied on 
DIOs. However, this behavior is

implementation-specific which is out of the scope of MSF.

__ __

__ __

This is not for this spec to define. RPL already mandates
trickle. Suggestion:

__ __

For example, the Trickle operation defined in [RFC6206]

is applied on DIO Messages [RFC6550  
]. This behavior is

out of the scope of MSF.

__

TC: agreed!

__

__ __

__ __

__ __

__ __

MSF RECOMMENDS the use of 3 slotframes. 

__ __

Discussion on slotframes and cells comes without an
introduction to TSCH. 

I’d suggest you add a few words on RFC 7554 appendix A and
6TiSCH architecture section 4.3.5. to introduce those
concepts.

They should probably be normative references.


TC: I added the following text at beginning of section 2:
            In a TSCH network, time is sliced up into time slots.
            The time slots are 

Re: [6tisch] Yatch's review on draft-ietf-6tisch-msf-08 - Re: MSF review

[Yasuyuki Tanaka]

Thank you, Tengfei.


TC: we only mentioned 6P SIGNAL, because that's 6P leaves it to scheduling 
function, which must mention how it is used.


I understand that Section 6 corresponds to the following point mentioned 
Section 4.2 of RFC 8480:


rfc8480> The specification for an SF
rfc8480> ...
rfc8480>o  SHOULD define the format of the SIGNAL command payload and
rfc8480>   its use.

I'm looking forward to the next version :-)

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] draft-ietf-6tisch-msf-06 is published

[Yasuyuki Tanaka]

Hi,

This is an open issue, what return code to return when there is no available 
cell.

Christian raised it before:

   https://mailarchive.ietf.org/arch/msg/6tisch/Awiip2xOfwZTPyg1jQIeIOyqSgk

As per RFC8480:

- RC_SUCCESS with an empty list will be returned
- RC_ERR_BUSY is defined to be returned when there is not enough resource to 
handle a new *transaction*
- RC_ERR defined is be returned for a request having an invalid CellOptions 
value, or for a response having an unknown return code (in the 3-step case)

> I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS

Between the two, RC_ERR_BUSY would be better since RC_ERR is basically telling 
that the responder doesn't understand your 6P message.
But, RC_ERR_BUSY is not good either. It is a return code suggesting "retry it 
later", not "give up this neighbor."

If possible, I would define a dedicated return code for this case, like 
RC_ERR_NO_AVAILABLE_CELL or RC_ERR_NO_CELL, though.

One solution within RFC8480 is to perform a 3-step ADD transaction on receiving 
an empty cell with RC_SUCCESS to an (2-step) ADD request.
If the responder doesn't have enough cells, it will return an empty cell list 
as the candidate cell list in its response.

Best,
Yatch


> On Aug 14, 2019, at 19:03, Thomas Watteyne  wrote:
> 
> I woud send back either an RC_ERR_BUSY or RC_ERR, definitely NOT RC_SUCCESSS
> 
>  
> 
> Thomas Watteyne, PhD 
> Sr Research Scientist & Innovator, Inria 
> Sr Networking Design Eng, Analog Devices 
> Founder & Advisor, Wattson Elements/Falco
> Founder & co-lead, UC Berkeley OpenWSN 
> Co-chair, IETF 6TiSCH 
> 
> www.thomaswatteyne.com 
>  
> 
> De: "tengfei chang" 
> À: "Thomas Watteyne" 
> Cc: "6tisch" <6tisch@ietf.org>
> Envoyé: Mercredi 14 Août 2019 08:46:25
> Objet: Re: [6tisch] draft-ietf-6tisch-msf-06 is published
> Hi Thomas,
> 
> Yes, you understood correctly.
> 
> There are two related part in RFC8480 mentioned this case: 
> 
> Upon receiving the request, node B checks to see if the length of the
>Candidate CellList is greater than or equal to NumCells.  Node B's SF
>verifies that all the cells in the Relocation CellList are scheduled
>with node A and are associated with the options specified in the
>CellOptions field.  If either check fails, node B MUST send a 6P
>Response to node A with return code RC_ERR_CELLLIST.  If both checks
>pass, node B's SF verifies which of the cells in the Candidate
>CellList it can install in its schedule.  How that selection is done
>is specified in the SF and is out of scope for this document.  That
>verification for the Candidate CellList can succeed (NumCells cells
>from the Candidate CellList can be used), fail (none of the cells
>from the Candidate CellList can be used), or partially succeed (fewer
>than NumCells cells from the Candidate CellList can be used).  In all
>cases, node B MUST send a 6P Response that includes a return code set
>to RC_SUCCESS and that specifies the list of cells that will be
>rescheduled following the CellOptions field.  That list can contain
>NumCells elements (succeed), 0 elements (fail), or between 0 and
>NumCells elements (partially succeed).  If N < NumCells cells appear
>in the CellList, this means that the first N cells in the Relocation
>CellList have been relocated and the remainder have not.
> 
> 
> Here it clarified the return code for this case MUST be RC_SUCCESS. 
> I would say it may implies that the case should be the option 1 I mentioned 
> above.
> 
> Another part in concurrent 6P transaction section, it says: 
> 
>  If a
>node does not have enough resources to handle concurrent 6P
>Transactions from different neighbors, it MUST reply with a 6P
>Response with return code RC_ERR_BUSY (as per Figure 38 in
>
> Section 6.2.4). 
> 
> I says 
> 
> enough resources to handle concurrent 6P Transactions, 
> 
> but the option 2 I mentioned doesn't need to be concurrent 6P transaction. 
> Also the RC_BUSY doesn't sound the right return code name for this case.
> 
> So does the RC_BUSY is the return code for option 2 I mentioned?
> 
> Tengfei
> 
> 
> On Wed, Aug 14, 2019 at 4:45 PM Thomas Watteyne  
> wrote:
> Tengfei,
> 
> Trying to understand you point about " handle Sixtop ADD Response with return 
> code SUCCESS but 0 cells in cellList"
> 
> If the response code is SUCCESS, IMO that means option 1. if option 2 is 
> happening (I assume you mean "there is no memory for allocating more cells"), 
> I would expect another return code, no?
> 
> THomas
> 
> 
> 
>  
> 
> Thomas Watteyne, PhD 
> Sr Research Scientist & Innovator, Inria 
> Sr Networking Design Eng, Analog Devices 
> Founder & Advisor, Wattson Elements/Falco
> Founder & co-lead, UC Berkeley OpenWSN 
> Co-chair, IETF 6TiSCH 
> 
> www.thomaswatteyne.com 
> 

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Yasuyuki Tanaka]

Hi Esteban,

> * Maybe out of the scope but, should not be defined here a housekeeping
> function that removes unused negotiated cells (TX or RX)? For example
> for cells that can't be removed with a 6P transaction (e.g. nodes are
> not in range any more).

It'd be nice to mention something there, at least like this:

  A node may remove negotiated cells scheduled with a neighbor which is
  considered as "unreachable", without having a 6P transaction. In that
  case, the node SHOULD reset the (6P) SeqNum for the neighbor. Specifying
  mechanisms to detect unreachable neighbors is out of scope of this
  document.

We used to have such a mechanism in previous versions, by the way:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.8

I'm not sure what is the best way to do for that purpose when using MSF.

Best,
Yatch

> On Jul 11, 2019, at 15:47, Esteban Municio  
> wrote:
> 
> Hi Tengfei,
> 
> I like the new changes, especially the concept of autonomous cells by
> demand and always having by default 1 downlink negotiated cell. 
> 
> Here are some minor comments (checking msf-05):
> 
> * In Section 5.2, it is not clear for me if the parent switch occurs
> before, during or after the 3-step procedure. My intuition says that is
> should be after point 2: "the node triggers one or more 6P ADD commands
> ". I guess it may be interesting to clarify when the actual parent
> switch occurs.
> 
> * Also in the same section 5.2, it could be convenient (although maybe
> redundant) to say in point 2 that the node has to schedule the same
> number "and options" of negotiated cells. This would keep also the
> ratio TX/RX with the new parent.
> 
> * Maybe out of the scope but, should not be defined here a housekeeping
> function that removes unused negotiated cells (TX or RX)? For example
> for cells that can't be removed with a 6P transaction (e.g. nodes are
> not in range any more).
> 
> And some minor edit comments:
> 
> - "increaase"
> - two "AutoUpCells" are still there
> - two "managed unicast cell" are still there
> - "it is possible for negotiated cell to avoid the collision with
> AutoRxCell." Maybe "for a negotiated"?
> - "For burst traffic type, larger value of MAX_NUMCELLS indeed
> introduces higher latency." Maybe "a larger value"?
> 
> Kind regards,
> Esteban
> 
> On Tue, 2019-07-02 at 12:57 +0200, Tengfei Chang wrote:
>> Dear all,
>> 
>> As you may noticed that a new version of MSF is just published at
>> here:
>> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04  
>> There are some moderate changes comparing to previous one.
>> 
>> Mainly in two aspects:
>> 
>> 1. change the concept of autonomous cell
>> 
>> In the new version, there will be two type of autonomous cells:
>> - autoTxCell, which is scheduled on demand for just transmitting
>> -autoTxCell, which is schedule permanently, for just receiving
>> (the previous version the autonomous cell are used as bidirectional)
>> 
>> More details about how to use those autonomous cell is available in
>> the draft.
>> 
>> 2. re-added the downstream traffic adaptation feature
>> 
>> Though, there are cases that the node doesn't receive packet because
>> of collision, we assume the influence won't be much to adapt the
>> downstream traffic.
>> We will evaluate the performance of this changes.
>> 
>> We are targeting to have a new version before the submission
>> deadline.
>> During the time, we will evaluate the v4 MSF and would like to have
>> your comments as well.
>> 
>> Thanks in advance!
>> 
>> Tengfei
>> 
>> -- 
>> Chang Tengfei,
>> Postdoctoral Research Engineer, Inria
> -- 
> Esteban Municio
> PhD Researcher, IDLab, University of Antwerp, in collaboration with
> imec
> esteban.muni...@uantwerpen.be
> The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium 
> 
> 
> ___
> 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

Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Yasuyuki Tanaka]

Thank you, Tengfei and the other authors, for the update!

Here are my comments:

[Major] Negotiated RX cell (Section 4.6)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6

If MSF is designed for regular upstream traffic, I don't think we need
the negotiated RX cell that is introduced by this new version.

I presume the purpose of the negotiated RX cell is, to have a
collision-free channel directed from parent to child. The parent may
have collisions on the autonomous TX cell to a node since children of
the node also use the cell to transmit their frames. However, once the
network converges, the children have negotiated TX cells to the
node. The parent of the node will be the only one who uses the
autonomous TX cell until a topological change happens.

I would rather keep unused cells in the slotframe for negotiated TX
cells to handle "regular upstream traffic" instead of using some of
them for negotiated RX cells (to receive frames from the parent).

I'm looking forward to seeing Tengfei's evaluation results, by the way
:-)


[Minor] AutoTxCell usage (Section 3)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

Sorry for bringing this again and again, but *in general*, L2/TSCH
layer has no idea about its upper layers. Although you can implement a
6TiSCH stack in which TSCH is aware of upper layer contents of a frame
to transmit, that may not be always the case. That is, the second
bullet point, starting with "frame is used for...", may not be able to
be implemented.

In this sense, applying "MUST" to the second bullet point seems too
strict.

draft> AutoTxCell is not permanent in the schedule but added/deleted on
draft>demand when there is a frame to sent.  Throughout the network
draft>lifetime, nodes MUST maintain the autonomous cells as follows:
draft>
draft>o  Add an AutoTxCell to the layer 2 source address which is indicated
draft>   in a frame when:
draft>
draft>   *  there is no 6P negotiated Tx cell in schedule for that frame to
draft>  transmit, and
draft>   *  the frame is used for protocol management purposes , such as
draft>  Join Request/Response, 6P Request/Response and any link-local
draft>  communication for RPL routing control.


[Minor] Unprotected frames on negotiated cells? (Section 5.1)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1

draft>   Both NumCellsElapsed and NumCellsUsed counters can be used to
draft>   negotiated cells with cell option TX=1 or Rx=1.  All the frames used
draft>   for increasing/decreasing the counters MUST be encrypted or
draft>   decryptable with the key get from joining process.

Will we have unprotected frames transmitted on negotiated TX/RX cells,
which are expected to be scheduled with *joined* nodes? I'm not sure
why the last sentence is necessary...


[Minor] Length of CellList (Section 8)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8

What should a node do when it receives a CellList shorter than 5?
Return RC_ERR_CELLLIST?

draft> 8.  Rules for CellList
draft>
draft>MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
draft>only initiated by a node towards its preferred parent.  As a result,
draft>the cells to put in the CellList of a 6P ADD command, and in the
draft>candidate CellList of a RELOCATE command, are chosen by the node
draft>initiating the 6P Transaction.  In both cases, the same rules apply:
draft>
draft>o  The CellList SHOULD contain 5 or more cells.


[Trivial] Section 3. Autonomous Cells

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

draft>  o  The AutoRxCell MUST always remain scheduled.

*Always* is ambiguous. A node cannot schedule an AutoRxCell until it's
get synchronized, when the length of slotframe 1 is available.


[Trivial] nits / editorial

- "AutoUpCells" is still there
- s/behvaior/behavior/
- s/boostrap/bootstrap/
- s/sheduling/scheduling/
- s/negoitated/negotiated/
- s/neogtiated/negotiated/
- s/transcation/transaction/
- s/calulated/calculated/

That's all!
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka]

Thanks, Diego!

I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been defining a separate return
code from RC_ERR_SEQNUM.

> On Apr 24, 2019, at 12:47, Prof. Diego Dujovne  
> wrote:
> 
> As far as I can remember, it is important to know that the peer has forgotten 
> all the states and has lost his schedule, so all the allocated cells with 
> that neighbour are currently not valid anymore and should be wiped from the 
> local schedule.

Actually, a node having such a peer should remove outdated cells somehow
without having an explicit signaling.

This is not a job of 6P, though. The SF should take care of it. A peer
may move away from the node without sending a CLEAR request. Even if the
peer sends a CLEAR request before moving somewhere, the CLEAR request may
be lost in the air. 

RPL may do something for this case. If a node has some dedicated TX cells to
its parent, and the parent reboots, RPL on the node could notice there is
something wrong with the parent since measured link quality to the parent
is getting worse. Then, parent switch will be performed.

Or, a SF like MSF would try to relocate badly performed cells. Then, it 
receives RC_ERR_SEQNUM from the parent and take actions to resolve the schedule
inconsistency in the same manner as for other scheduling consistency cases.
The node can see whether the peer loses all the states nor not by having a 
following
COUNT transaction if the SF really wants to know. If the SF always issues a
CLEAR request to a peer which sent RC_ERR_SEQNUM, the SF doesn't care about
the power-cycle event. Another possibility is that the RELOCATE transaction
ends by 6P Timeout. Again, some actions will be taken by the SF.

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka]

Hi Xavi,

> What is the issue you see with this?

At least, there is an inconsistency in RFC8480. Here is another example:

https://tools.ietf.org/html/rfc8480#section-3.2.2

rfc8480>   6P Request, 6P Response, and 6P Confirmation messages for a given
rfc8480>   transaction MUST share the same Version, SFID, and SeqNum values.

Such an inconsistency could bring confusion and/or an interoperability issue.

According to you, a response having SeqNum=0 AND RC_ERR_SEQNUM has a special
meaning which is "I've lost all the states completely (due to power-cycle)",
although this is another case we will receive such a response as shown in
Figure 32... Honestly, I'm not sure how valuable it is to know the peer has
performed power-cycle, by the way.

So, if setting 0 to SeqNum of a response is a right thing, I would add some
text to the SeqNum definition in Section 3.2.2, to tell there is an exception. 

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka]

Hi Xavi,

Thank you for your reply.

On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:

When node B power cycles loses the last seen seqNum. Its stored value is then 0 
and hence when it receives the request responds with the error and with the 
stored last seen seqnum (0).

does it make sense?


I don't think so... Why doesn't Node B just use SeqNum received from Node A for 
its response?

Node A in Figure 31 would drop the response with SeqNum=0 at 6P layer because 
it is not considered as part of the transaction started by the request with 
SeqNum=88.

Again, the definition of SeqNum is:


   SeqNum:  The sequence number associated with the 6P Transaction.
 Used to match the 6P Request, 6P Response, and 6P Confirmation
 of the same 6P Transaction.  


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] SeqNum definition in RFC8480 (6P)

[Yasuyuki Tanaka]

Hi,

I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.

Section 3.2.2 defines SeqNum like this:

[https://tools.ietf.org/html/rfc8480#section-3.2.2]
>   SeqNum:  The sequence number associated with the 6P Transaction.
> Used to match the 6P Request, 6P Response, and 6P Confirmation
> of the same 6P Transaction.

So, basically, a response and a confirmation have the same SeqNum
value as the corresponding request. This is very normal.

However, Section 3.4.6.2 says, if a node detect schedule inconsistency
with a received request, the node does a different thing. A response
in this case has a different SeqNum value from the corresponding
request. This is strange...

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>   If the inconsistency is detected during a 6P Transaction (Figure 31),
>   the node that has detected it MUST send back a 6P Response or 6P
>   Confirmation with an error code of RC_ERR_SEQNUM.  In this 6P
>   Response or 6P Confirmation, the SeqNum field MUST be set to the
>   value of the sender of the message (0 in the example in Figure 31).

In Figure 31, Node A receives 6P Response (SeqNum=0, RC_ERR_SEQNUM) in
the last part of the message sequence. But, according to the
definition by Section 3.2.2, Node A doesn't consider the response to
be part of the transaction initiated by 6P Request (SeqNum=88),

[https://tools.ietf.org/html/rfc8480#section-3.4.6.2]
>   +--+   +--+
>   |  Node A  |   |  Node B  |
>   ++-+   +-++
>  SeqNum=87 |   | SeqNum=87
>|   |
>| 6P Request  (SeqNum=87)   |
>|-->|
>|L2 ACK |
>|<- - - - - - - - - - - - - - - - - - - |
>|   |
>| 6P Response  (SeqNum=87)  |
>|<--|
>| L2 ACK|
>| - - - - - - - - - - - - - - - - - - ->|
>|  power-cycle
>|   |
>  SeqNum=88 |   | SeqNum=0
>|   |
>| 6P Request (SeqNum=88)|
>|-->| Inconsistency
>|L2 ACK | detected
>|<- - - - - - - - - - - - - - - - - - - |
>|   |
>| 6P Response (SeqNum=0, RC_ERR_SEQNUM) |
>|<--|
>| L2 ACK|
>| - - - - - - - - - - - - - - - - - - ->|
>
> Figure 31: Example of Inconsistency Because Node B Resets
>   (Detected by Node B)

If this is an error, I'm going to file an errata entry. Otherwise, I'd
like to know why Node B in Figure 31 MUST set 0 to SeqNum for the 6P
Response having RC_ERR_SEQNUM. Node A becomes aware of schedule
inconsistency anyway, seeing RC_ERR_SEQNUM in the response.

By the way, the 5th paragraph in Section 3.4.6 supports Section
3.2.2. The response in an example of the paragraph has the same SeqNum
value as the response, which is 0. This is the same case as explained
with Figure 32.

[https://tools.ietf.org/html/rfc8480#section-3.4.6]
>   When node B receives a 6P Request from node A with SeqNum equal to 0,
>   it checks the stored SeqNum for A.  If A is a new neighbor, the
>   stored SeqNum in B will be 0.  The transaction can continue.  If the
>   stored SeqNum for A in B is different than 0, a potential
>   inconsistency is detected.  In this case, B MUST return RC_ERR_SEQNUM
>   with SeqNum=0.  The SF of node A MAY decide what to do next, as
>   described in Section 3.4.6.2.

Or, am I just confused...?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Review of draft-ietf-6tisch-msf-03

[Yasuyuki Tanaka]

Thank you, the authors!

I confirmed most of my comments to the previous version have been
addressed. It reads better :-)

Here are my comments: two comments are major, the rest are minor.


[major: usage of the autonomous cell and the managed cell]

The draft specifies rules what type of frames MUST be sent over the
autonomous cell. How can we implement the rules on top of TSCH MAC
defined by IEEE802.15.4?

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>  The traffic on the autonomous cells are scheduled as:
draft-03>
draft-03>  o  Join Request packets and 6P ADD/DELETE Request frames to the
draft-03> node's Join Proxy or its RPL routing parent MUST be sent on
draft-03> AutoUpCell.
draft-03>  o  Join Response packets and 6P ADD/DELETE Response frames to the
draft-03> pledge or its RPL routing child MUST be sent on AutoDownCell.
draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child MUST be
draft-03> sent on AutoDownCell.
draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST be sent
draft-03> on AutoUpCell.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   Adding/removing/relocating cells involves exchanging frames that
draft-03>   contain 6P commands.  All 6P Request frames to its parent MUST be
draft-03>   sent on the AutoUpCell All 6P Response frames to non-parent neighbor
draft-03>   MUST be sent on AutoDownCell.

At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
to the same neighbor are used without distinction. This is totally
fine and straightforward. Why do we need the change to this part?

https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1
draft-02>   Autonomous cells are used indistinguishably
draft-02>   together with dedicated cells, for broadcast or unicast traffic with
draft-02>   the target neighbor.  The procedure to remove autonomous cells is
draft-02>   described in Section 3.

To my understandings, TSCH MAC selects a cell (link) to transmit a
frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
cares only the destination MAC address and the frame type of a TX
frame, doesn't it?


[major: some confusions in Section 5]

We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
cells because managed cells have always only TX=1.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   NumCellsElapsed :  Counts the number of managed cells that have
draft-03>   elapsed since the counter was initialized.  This counter is
draft-03>   initialized at 0.  Each time the TSCH state machine indicates
draft-03>   that the current cell is a managed cell to the preferred parent,
draft-03>   NumCellsElapsed is incremented by exactly 1, regardless of
draft-03>   whether the cell is used to transmit/receive a frame.

"to transmit/receive a frame" in the last sentence should be replaced
with "to transmit a frame", and

draft-03>   Both NumCellsElapsed and NumCellsUsed counters can be used to cell
draft-03>   with cell option TX=1 or RX=1.

"with cell option TX=1 or RX=1" should be replaced with "with cell
option TX=1"?

Another thing is related to what Fabrice pointed out. There is
something wrong in text about the RELOCATE operation. Since NumTx and
NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
request is never issued for an RX cell. Then, the direction in the
following text is opposite...

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child MUST be
draft-03> sent on AutoDownCell.
draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST be sent
draft-03> on AutoUpCell.

One more thing:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
draft-03>  4.  For any other cell, it compares its PDR against that of the cell
draft-03>  with the highest PDR.  If the different is less than
draft-03>  RELOCATE_PDRTHRES, it triggers the relocation of that cell using
draft-03>  a 6P RELOCATE command.

- s/different/difference/
- s/less than/larger than/ ??

Can you check the entire text in Section 5?


[minor comment #1]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2
draft-03>   For example, a Trickle Timer defined in [RFC6550] MAY be
draft-03>   applied on DIOs.

Do we need "MAY" here? If you implement RFC6550, DIO is automatically
controlled by Trickle Timer.


[minor comment #2]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>   MUST use the hash function SAX [SAX-DASFAA].  The coordinates are
draft-03>   computed to distribute the cells across all channel offsets, and all
draft-03>   but the first time offsets of Slotframe 1.  The first time offset is
draft-03>   skipped to avoid colliding with the minimal cell in Slotframe 0.

s/time offset/slot 

Re: [6tisch] Fwd: New Version Notification for draft-tiloca-6tisch-robust-scheduling-01.txt

[Yasuyuki Tanaka]

Hi Marco,

I'd like to ask you to help me understand the attack (>_<)

https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01#section-3.2
> 3.2.  Attack Example
>
> (snip)
>
>2.  The adversary picks a channel 'f*' at random, and monitors it for
>N_C consecutive slotframes to determine the timeslots in which
>the victim node communicates on that channel.  Due to the usage
>property, the number of such timeslots is equal to the number of
>cells assigned to the victim node.

How does the adversary identify communication of the victim? It
assumes the adversary knows the EUI-64 address of the victim in
advance, or the adversary randomly picks out a victim node?

If the adversary attacks based on a target EUI-64 address, it seems
using EUI-16 (short) address which can be assigned through the join
process could mitigate the attack.


https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-10

I'm wondering how severe the attack is...

Best,
Yatch

On 12/17/2018 12:38 PM, Marco Tiloca wrote:

Hi all,

We have just submitted a new version of our draft describing how to 
alter the communication pattern of network nodes to counteract selective 
jamming.


https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01

This update especially addresses the comments from IETF 103, by 
clarifying the attack importance and the adversary model. Also, the 
draft is now aligned with the CoJP Join Response from the latest minimal 
security framework.


Comments are welcome!

Thanks,
/Marco


 Forwarded Message 
Subject: 	New Version Notification for 
draft-tiloca-6tisch-robust-scheduling-01.txt

Date:   Mon, 17 Dec 2018 03:27:31 -0800
From:   internet-dra...@ietf.org
To: 	Marco Tiloca , Gianluca Dini 
, Simon Duquennoy 






A new version of I-D, draft-tiloca-6tisch-robust-scheduling-01.txt
has been successfully submitted by Marco Tiloca and posted to the
IETF repository.

Name: draft-tiloca-6tisch-robust-scheduling
Revision: 01
Title: Robust Scheduling against Selective Jamming in 6TiSCH Networks
Document date: 2018-12-17
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/internet-drafts/draft-tiloca-6tisch-robust-scheduling-01.txt
Status: 
https://datatracker.ietf.org/doc/draft-tiloca-6tisch-robust-scheduling/
Htmlized: 
https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-tiloca-6tisch-robust-scheduling
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-tiloca-6tisch-robust-scheduling-01


Abstract:
This document defines a method to generate robust TSCH schedules in a
6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4-2015) network, so as
to protect network nodes against selective jamming attack. Network
nodes independently compute the new schedule at each slotframe, by
altering the one originally available from 6top or alternative
protocols, while preserving a consistent and collision-free
communication pattern. This method can be added on top of the
minimal security framework for 6TiSCH.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


___
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

Re: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Yasuyuki Tanaka]

Thank you, Tengfei.

Additional and following-up comments:


[Section 5.1, what to do after timeout of a 6P transaction]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5

The draft does not say anything about how to handle timeout of a 6P
transaction. I know, the initiator of the timed out transaction will
resend a 6P request to the same peer ;-) But, it's better to mention
that as well as the maximum number of retries if we have.


[Section 9, 6P Timeout Value]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-9

A couple of questions:

- "C" includes the autonomous cell to the neighbor or it is the number
  of the managed cells?
- How can the timeout value be calculated while PDR is not available?


[Section 4.5, Step 4 of the bootstrap process]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.5

tengfei> I don't know whether there is a specification for how the
tengfei> neighbor table should be managed. If no, I think PERSONALLY
tengfei> it's better not keeping the address from pledge in neighbor
tengfei> table.

Although the actual way to manage neighbor information is
implementation-dependent, the minimal security framework draft
suggests to have separate memory for joined nodes and for pledges
respectively:


https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6

Again, my comment on Section 4.5 is just that, I think we need some
text in "Security Considerations" section for this operation described
in Step 4. And, it seems the term of "the neighbor table" in the Step
4 is ambiguous. Some may think it's IPv6 neighbor cache, some may
think L2 neighbor table.


[Appendix-B, SAX configuration]

tengfei> This is a pre-configured (offline) for interoperability
tengfei> purpose only.

It's better to mention how a pledge gets the SAX parameters used in
the network where it is trying to join. There are always two options:

- pre-configured
- advertised in EBs

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

[Yasuyuki Tanaka]

Hi,

Thank you, Tengfei and the other authors, for updating the draft!

I'm sharing my comments on the latest version.

   https://tools.ietf.org/html/draft-ietf-6tisch-msf-02

[Security Consideration on autonomous SHARED cell allocation]


4.5.  Step 4 - Installing Autonomous Cells for each neighbor in neighbor
  table

   Because it has learnt the link-layer keying material used in the
   network, the joined node can now decrypt any packets sent by its
   neighbors.  Once a new neighbor is added to the neighbor table, a new
   autonomous SHARED cell MUST be added to that neighbor.


As per the second sentence in this section, a JP MUST allocate an
autonomous SHARED cell to a pledge during its secure joining process.

Tengfei's email says no action required on the JP side, but the JP
need to have a neighbor table entry (neighbor cache entry) for the JP
in order to send back a join response, doesn't it? I may miss
something.

tengfei> [Resolved. During join process, only pledge required to
tengfei> install autonomous SHARED cell to JP, no action required from
tengfei> JP side.]

If this is the case, I would propose to add some note in Security
Considerations section where we mention risks of this kind allocation,
and may suggest a mitigation technique such as "on-demand allocation".

Basically this is the same comment as the first one in the following
email:

   https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao


[Join request packets can still increment NumCellUsed?]

tengfei> non-trusted packet shouldn't be accounted for for adapting
tengfei> traffic
tengfei> 
tengfei> Mention that the untrusted packet (e.g. join
tengfei> request/response) shouldn't be counted for adapting the
tengfei> traffic.  Issues link:
tengfei> https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15
tengfei>
tengfei> [Resolved. clarified in adapting traffic section.]

I think this issue hasn't been resolved yet by the latest draft. I
expect text describing how to handle packets having code point AF42 or
AF43.


https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-09#section-6.1


[EB / DIO transmission rules]

I would propose to remove the third and fourth paragraphs mainly for
these two reasons:

- This is an implementation-specific optimization
- This is irrevalnt to the scheduling function itself


2.  Interface to the Minimal 6TiSCH Configuration

(snip)

   Because the minimal cell is SHARED, the back-off algorithm defined in
   [IEEE802154-2015] is used to resolve collisions. To ensure there is
   enough bandwidth available on the minimal cell, a node implementing
   MSF SHOULD enforce the following rules for broadcast frames:

   1.  send EBs on a portion of the minimal cells not exceeding
   1/(3(N+1)), where N is the number of neighbors of the node.
   2.  send any other broadcast packets on a portion of the minimal
   cells not exceeding 1/(3(N+1)), where N is the number of
   neighbors of the node.  For example, the broadcast DIO and DIS,
   IPv6 Neighbor Discovery (ND)[RFC4861] and any other application
   layer broadcast packets.

   The RECOMMENDED behavior for sending EBs is to have a node send EBs
   with a probability of 1/(3(N+1)).  The RECOMMENDED behavior for
   sending DIOs is to use a Trickle timer with rate-limiting.  There is
   no recommendation behavior for sending any other broadcast.  However,
   the traffic portion of all broadcast packets on minimal cell, except
   EBs, MUST not exceed 1/(3(N+1)).


Here is Xavi's comment on this:

xavi> here we place a SHOULD and not a MUST. We want to make sure the
xavi> network works as if there is over-use of the minimal cell
xavi> collapses. We think this should be said here so an adopter is
xavi> aware of the limitations and implements a working measure.

   https://mailarchive.ietf.org/arch/msg/6tisch/3SrQj7LXzfFZUSEYasWcwGSrFRM

I'd like to hear what others think :-)

Aside from that, it's unclear how to implement "Trickle timer with
rate-limiting", and having such a modification to Trickle is
discouraged by RFC6206:

   https://tools.ietf.org/html/rfc6206#section-6.7


[SAX Configuration]

How can a mote know what values should be used for l_bit and r_bit? Do
we assume they are configured offline? Or they can be advertised in
EBs?


Appendix B.  Example of Implementation of SAX hash function

(snip)

   For interoperability purpose, the values of h0, l_bit and r_bit in
   Step 1 and 2 are configured as:

   o  h0 = 0
   o  l_bit = 0
   o  r_bit = 1

   The appropriate values of l_bit and r_bit could vary depending on the
   the set of motes' EUI64 address.  How to find those values is out of
   the scope of this specification.


Additionally, it'd be nice to have test vectors of the SAX computation
with the set of parameters (h0=0, l_bit=0, r_bit=1) for
interoperability.


[Autonomous Cell]

We need a clearer description on the two types of the autonomous cell:


3.  

Re: [6tisch] frame pending bit - Re: Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Hi Tero,

Thank you for the clear explanation!

Yatch

> On Dec 11, 2018, at 11:13, Tero Kivinen  wrote:
> 
> Yasuyuki Tanaka writes:
>> Is there any update on CID 93? I checked LB150 Consolidated Comments
>> (rev.12)[1], but the item for CID 93 is filtered out for some
>> reason...
>> 
>> [1] 
>> https://mentor.ieee.org/802.15/dcn/18/15-18-0433-12-04md-lb150-consolidated-comments.xlsx
> 
> While we are working on the sheet we quite often filter comments in
> some way, i.e., only show those do not have any resolution yet, and go
> through them. CID 93 has been marked as Defer and was assigned to
> person taking care of most of the other TSCH comments too. We try to
> go through all comments once before coming back to the comments we
> have deferred or postponed for later. We have now managed to go
> through the main letter ballot comments once, and moved to go through
> the rogue comments once before coming back to finish those comments we
> skipped over.
> -- 
> kivi...@iki.fi
> 
> ___
> 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

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

[Yasuyuki Tanaka]

Thank you, Pascal.

> Please let me know if you intend to provide a review soon.

Yes. Here are my additional but minor comments:

---

[Definition of 6P / Section 2.2 and Figure 1]

In the terminology section, 6top is explained as follows:

   6top (6TiSCH Operation Sublayer):  The next highest layer of the IEEE
   Std 802.15.4 TSCH medium access control layer.  It
   implements and terminates 6P, and contains at least one
   SF.

However, 6top doesn't contain SFs in Figure 1. My understanding on 6top is the 
same as Figure 1. In addition, the original text says that 6top "contains at 
least one SF". However, 6TiSCH could work without SF. Then, the explanations of 
6top and 6P in Section 2.2 would be:

   6top (6TiSCH Operation Sublayer):  The next higher layer of the IEEE
   Std 802.15.4 TSCH medium access control layer.  It
   provides the abstraction of an IP link over a TSCH
   MAC, schedules packets over TSCH cells, and expose a management
   interface to schedule TSCH cells.

   6P (6top Protocol):  Allows neighbor nodes to communicate to add/
   delete cells to one another in their TSCH schedule. 6P is 
terminated at
   the 6top layer.

[Terminology / Section 2.2]

Are these terms common? It seems so, but they are not used in the draft nor in 
RFC7554/RFC8180/RFC8480, are they?: 

   blacklist of frequencies:  A set of frequencies which should not be
   used for communication.

   broadcast cell:  A scheduled cell used for broadcast transmission.

Does "broadcast cell" means a cell having the broadcast MAC address in its 
neighbor MAC address field? I'd like to have more text on them or to remove 
them.

["6P protocol"]
"6P protocol" is used three times in the draft, which should be replaced with 
"6P" (or "6top Protocol").

---

That's all :-) 

> Maybe we'll work on them in PAW ML. Did you register?

Yes, I did.

Thanks!
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] WGLC for https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt

[Yasuyuki Tanaka]

Hi Pascal,

I'm reviewing the architecture draft, although the deadline has already 
passed... I have one comment.

I see some ideas which don't have concrete protocol specifications discussed as 
WG drafts, for instance, centralized reservation and tracks. They look like 
kind of "concepts" at this moment. 

Can we keep them in the architecture draft whose intended status is now 
Standards Track? I read RFC7127, "Characterization of Proposed Standards", but, 
I'm not sure...

This should have been raised when you asked by 
https://mailarchive.ietf.org/arch/msg/6tisch/qxeFuhVNGV5wXjgz1yHY8Mp8e1I

Sorry for the late comment.

Best,
Yatch


> On Nov 11, 2018, at 3:22, Pascal Thubert (pthubert)  
> wrote:
> 
> Dear WG :
> 
>  
> 
> We are now starting the working group last call for the 6TiSCH Architecture 
> based on https://www.ietf.org/id/draft-ietf-6tisch-architecture-17.txt. This 
> document is the merge of the previous architecture and terminology documents.
> 
>  
> 
> Authors of our WIP WG docs draft-ietf-6tisch-dtsecurity-zerotouch-join-03, 
> draft-ietf-6tisch-enrollment-enhanced-beacon-00, 
> draft-ietf-6tisch-minimal-security-08 and draft-ietf-6tisch-msf-01 are 
> requested to pay particular attention on how their work is reflected in the 
> Architecture, and are strongly encouraged to propose new text to improve the 
> correctness of that representation.
> 
>  
> 
> The architecture is a foundational product of the WG, providing the view on 
> the whole stack that we designed, implemented and interop tested over the 5 
> years of activity of the group; it is in some form a testimony of the WG.
> 
> With this in mind, please pay a very special attention when reviewing it.
> 
>  
> 
> The WGLC ends on Friday November 30th, 2018.
> 
>  
> 
> Many thanks in advance;
> 
>  
> 
> The chairs.
> 
> ___
> 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] frame pending bit - Re: Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Hi Tero, 

Is there any update on CID 93? I checked LB150 Consolidated Comments 
(rev.12)[1], but the item for CID 93 is filtered out for some reason... 

[1] 
https://mentor.ieee.org/802.15/dcn/18/15-18-0433-12-04md-lb150-consolidated-comments.xlsx

Best,
Yatch

> On Oct 6, 2018, at 3:28, Tero Kivinen  wrote:
> 
> The frame pending bit operations in TSCH is bit underspecified in the
> 802.15.4-2015. We do have comment CID 93 about that in the current
> letter ballot. The TG4md documents can be found from [1] and there is
> consolidated comments from the last letter ballot [2], and from there
> you can find the CID 93 that is talking about the frame pending bit on
> TSCH.
> ...
> [1] https://mentor.ieee.org/802.15/documents?is_group=04md
> [2] 
> https://mentor.ieee.org/802.15/dcn/18/15-18-0433-06-04md-lb150-consolidated-comments.xlsx

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Thank you, Tero!

> The TG4md documents can be found from [1] and there is
> consolidated comments from the last letter ballot [2], and from there
> you can find the CID 93 that is talking about the frame pending bit on
> TSCH.

Yes, I found CID 93. Nice.

> This rewrite will most likely add some more text there specifying what
> link scheduled means, and when to send the pending bit and so on, I
> will make sure it also covers the case where there is no ACK.

That is great. It will be helpful!

My question is about a frame loss in the following case:

[at ASN n]
- a transmitter sends a frame having the pending bit on
- the receiver receives the frame and sends backan ACK to the transmitter
- the receiver decides to stay on the same physical channel in the next slot 
(because "there is no link scheduled")
- the transmitter receives the ACK and decides to send a next frame on the same 
physical channel in the next slot

[at ASN n+1]
- the transmitter sends the second frame
- the transmitter doesn't receive an ACK; it sees the frame is lost

> The transmitter has no idea which of those two things happened, thus
> only safe thing it can do is to abort also and continue normal
> schedule.

I agree!

My point here is that, it's unclear if the transmitter should start the TSCH 
retransmission algorithm by the loss of the latter frame. The condition to 
start the process in the current test is:

   "When a packet is transmitted on a shared link for which an acknowledgment 
is expected and none is received, the transmitting device shall invoke the TSCH 
retransmission algorithm." (Section 6.2.5.3 of IEEE 802.15.4-2015)

The latter frame is not transmitted on a shared link nor on a dedicated link. 
There is no link scheduled :-)

Best,
Yatch


> On Oct 6, 2018, at 3:28, Tero Kivinen  wrote:
> 
> Yasuyuki Tanaka writes:
>> I came across another question on the retransmission algorithm.
>> Could you help...? 
>> 
>> What should we do when a frame sent in an un-scheduled slot is not
>> acknowledged? 
>> 
>> As you know, with the frame pending bit, we can send a frame even if
>> we don't have a cell scheduled at that time (Section 7.2.1.3 of IEEE
>> 802.15.4-2015). While I don't think the back-off wait is necessary
>> in this case, this topic is not covered by IEEE 802.15.4-2015... 
> 
> The frame pending bit operations in TSCH is bit underspecified in the
> 802.15.4-2015. We do have comment CID 93 about that in the current
> letter ballot. The TG4md documents can be found from [1] and there is
> consolidated comments from the last letter ballot [2], and from there
> you can find the CID 93 that is talking about the frame pending bit on
> TSCH.
> 
> This rewrite will most likely add some more text there specifying what
> link scheduled means, and when to send the pending bit and so on, I
> will make sure it also covers the case where there is no ACK.
> 
> My guess is that if there is no ACK, then you abort sending further
> frames, and move to the normal TSCH operation, i.e., the
> retransmission happens using normal rules.
> 
> The reason why we do not have ACK, could be:
> 
> 1) Transmitted frame did not reach recipient. In this case recipient
> will time out as it is not receiving any frames in timeslot even when
> the frame pending bit was on on previous frame, so it should most
> likely stop listening on that channel and resume operations.
> 
> 2) Transmitted frame did reach other end, but the ACK did not reach
> back. In this case the recipient will process the frame, and if that
> frame it received has frame pending bit on, it will stay on this
> channel for next frame.
> 
> The transmitter has no idea which of those two things happened, thus
> only safe thing it can do is to abort also and continue normal
> schedule.
> 
> But, that is just my guess what should happen, I am not sure what
> implementations do, and I do not think we have text in standard
> describing exactly what to do.
> 
> [1] https://mentor.ieee.org/802.15/documents?is_group=04md
> [2] 
> https://mentor.ieee.org/802.15/dcn/18/15-18-0433-06-04md-lb150-consolidated-comments.xlsx
> -- 
> kivi...@iki.fi

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-msf-00

[Yasuyuki Tanaka]

Hi,

I have additional comments on the latest MSF:

* discussion: scheduling adaptation

MSF can adapts to traffic changes in the manner described in section 5.1. It
seems this mechanism doesn't work well under a heavy loaded situation.

After joining process, a joined node (child) has one autonomous cell to its
parent, which is the autonomous RX cell from the viewpoint of the parent. If the
network is inactive and the link quality is pretty good, the child can send a
frame over the autonomous cell anytime it wants. And, if it has always frames to
send, then the adaptation mechanism will determines to allocate additional
cells.

However, if there are many siblings of the child around and its network load is
high, frames sent by the child on the autonomous cell of the parent are likely
to be lost because of collisions. When the child has an un-acknowledged frame,
it has to perform the retransmission algorithm since the autonomous cell has the
SHARED bit on. A bad thing to the adaptation mechanism is that "NumCellsUsed" is
not incremented during the backoff wait, although "NumCellsPassed" is counted
up. As a result, the child cannot have additional (dedicated) cells here even
though it may have many cells in its TX queue.

It may be fine, by the way, since these frames in the TX queue will be sent
continuously thanks to the pending bit once the first frame is received
successfully by the parent. But, an additional dedicated cell is not allocated
in this case, anyway.

A simple solution is to increment "NumCellsUsed" during the backoff wait if it's
desirable to have a dedicated cell to the parent in such a case.

* trivial comment: channel to listen on for EBs

The pledge may not know in advance which channels are used in a network to
join. So, it'd be better to try a different frequency if it cannot receive any
EB for a while.

draft> 4.2.  Step 1 - Choosing Frequency
draft> 
draft>When switched on, the pledge SHOULD randomly choose a frequency among
draft>the available frequencies, and start listening for EBs on that
draft>frequency.
draft> 
draft> 4.3.  Step 2 - Receiving EBs
draft> 
draft>Upon receiving the first EB, the pledge SHOULD continue listening for
draft>additional EBs to learn:

Best,
Yatch


On Aug 31, 2018, at 15:33, Yasuyuki Tanaka  wrote:
> 
> Thank you, Simon and Xavi!
> 
> A couple of things:
> 
>>>> 'MUST' here sounds too strong... Some may want to use MSF with a base 
>>>> schedule
>>>> other than one defined RFC 8180 with full understands on implications by 
>>>> not
>>>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>>> 
>>>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
>>>> document or not.
>>> 
>>> MSF assumes the presence of the minimal cell, but might be able to run 
>>> without the full RFC8180.
>>> Happy to hear what others think
>>> 
>> XV>> MSF needs at least one pre-existing cell in the schedule so a node can 
>> receive/send EBs and form/join into the network. To ensure this we enforce 
>> RFC8180.
> 
> If the minimal shared cell is only the dependency for MSF, it'd be much 
> clearer to say that instead of saying, "MSF MUST implement RFC 8180". RFC 
> 8180 defines far more things than having the minimal shared cell. And, it 
> concerns 2.4 GHz O-QPSK PHY alone.
> 
>>>> * minor comment 6
>>>> 
>>>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
>>>> section?
>>>> 
>>> I'll let other co-authors answer
>>> 
>> XV> I think this was though to handle pagination when the LIST command is 
>> received. This is, define what are the cells to return when a list command 
>> is requesting cells from a particular offset. 
> 
> I see; then, I'd like to have such explanation in Section 10 :-)
> 
>   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10
> 
> Best,
> Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Hi Tero,

I came across another question on the retransmission algorithm. Could you 
help...?

What should we do when a frame sent in an un-scheduled slot is not acknowledged?

As you know, with the frame pending bit, we can send a frame even if we don't 
have a cell scheduled at that time (Section 7.2.1.3 of IEEE 802.15.4-2015). 
While I don't think the back-off wait is necessary in this case, this topic is 
not covered by IEEE 802.15.4-2015...
 
Thank you!
Yatch

> On Jun 22, 2018, at 17:52, Yasuyuki Tanaka  wrote:
> 
> Thank you, Tero!!
> 
> tero> I.e., the text this refers to ("A device upon encountering a
> tero> transmission failure in a shared link shall initialize the BE to
> tero> macMinBe.") is on page 66, not in page 65.
> 
> OK, we're on the same page now :-)
> 
> tero> Note, that CCA will NOT fail for other tsch transmissions on the
> tero> slot, as those transmissions all start at the same time, thus
> tero> there is no way to detect them. 
> 
> Right, it won't. This is another interesting point of TSCH. I learned
> this from Thomas 1.5 years ago.
> 
>   https://mailarchive.ietf.org/arch/msg/6tisch/E8IDY4-dkuPMIjD3rh54bGdaQ80
> 
> By the way, it seems I misunderstood what you told me two days ago:
> 
> tero>> if CCA fails, we just assume the sending of the frame failed,
> tero>> increment NB (which has slightly different meaning than in 6-5
> tero>> here) and try again.
> 
> I thought, it meant "CCA failure is treated as a transmission failure
> in *Figure 6-5*". This is wrong. But it does for figure 6-6; CCA
> failure is treated in the same manner for retransmission failure (no ACK)
> in figure 6-6. Oh, I am very clear!
> 
> tero> If TschCca is not set we skip CCA, regardless wheter this is
> tero> shared or dedicated link. In initial tranmission we do CCA for
> tero> shared links always, and for dedicated links we check TschCca.
> 
> That's good to know! I totally overlooked this part!!
> 
> tero> I think it is clear from the figures 6-5 and 6-6. Note, that
> tero> figures in standard are normative.
> 
> Thanks to you, figure 6-5 and 6-6 are my friends now.
> 
> One question for clarification: if a node gets out of the CSMA-CA
> algorithm (figure 6-5) with NB == (macMaxFrameRetries - 1) and doesn't
> receive an ACK to a frame transmitted over a shared link, it enters
> the TSCH Retransmission backoff algorithm (figure 6-6) keeping the NB
> value. Then, this node can attempt only one retransmission at most,
> because NB reaches macMaxFrameRetries by one retransmission failure
> (no ACK or channel busy). This is correct, isn't it?
> 
> And, I'd suggest one correction in figure 6-6.
> 
> tero>> Hmm... it seems we did have sponsor ballot comment i-9 from Pat
> tero>> Kinney which included part saying:
> tero>>
> tero>>8. In box 'NB = NB +1, BE = min(BE-1, macMinBe) change
> tero>>'BE = min(BE-1, macMinBe)' to 'BE = min(BE+1, macMaxBe)'
> tero>>to correspond with page 31 text.
> 
> In fact, 'BE = min(BE+1, macMaxBe)' should be applied if and only if a
> retransmission fails in a shared link. Then, we would need a decision
> box having 'shared link?' above the BE update. If it goes to 'Y', then
> execute 'BE = min(BE+1, macMaxBe)'. Otherwise, keep the current BE
> value.
> 
> tero> On the other hand there is no reason why I should not be able to
> tero> use dedicated link to B to send the frame to it even when it is
> tero> not first in queue. I think this kind of text is explictly left
> tero> out from the standard, i.e., there is nothing saying it is
> tero> allowed, but there is nothing saying you cannot do it.
> 
> To my knowledge, this kind of operation commonly happens in 6TiSCH
> implementations which implement the following protocols:
> 
>  https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-12#section-3.1
>  https://tools.ietf.org/html/draft-chang-6tisch-msf-01#section-2
> 
> tero> This of course means that NB variables needs to be per frame,
> tero> but on the otherhand we want the BE to be global, not per frame,
> tero> and this is not really reflected in the figure now.
> 
> It'd be really great if we could have some text on such a case.
> 
> Here is a little input: MSF allocates dedicated *cells* having SHARED
> bit on, and a node could have multiple frames under retransmission
> processes. I have no idea if having one global BE would be enough for
> this case.
> 
> tero> So even if we managed to send last frame using the dedicated
> tero> link, we should keep the large BE value as we have not
> tero> successfully used shared link, so

Re: [6tisch] MSF / 6top - Error Handling for Bandwidth Allocation exceeding available capacity

[Yasuyuki Tanaka]

Hi Christian,

Indeed, there is no return code found in draft-ietf-6tisch-6top-protocol-12 for 
such a case. 

> Node C indicates a 6P ADD to node A which is answered with 6P_SUCCESS but 
> with an empty cellist (2-step transaction). I guess next time node C can try 
> 3-step transaction giving node A the opportunity to propose a cellist. 
> In case Node A has no cells to propose the response should contain 
> RC_ERR_CELLLIST error correct?

Node A can respond with an empty cell list to the ADD request to indicate that 
it cannot give any candidate cell to add. The 6P draft implies this, although 
the text assumes only 2-step ADD transaction.

(https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-12#section-3.3.1)
>CellList can be used).  In all cases, node B MUST send a 6P Response
>with return code set to RC_SUCCESS, and which specifies the list of
>cells that were scheduled following the CellOptions field.  That can
>contain NumCells elements (succeed), 0 elements (fail), or between 0
>and NumCells elements (partially succeed).

Then, you can do something on receiving an empty cell list in the response 
message for a 3-step ADD transaction.

> If there would be an error code signaling “out of bandwidth” the SF may 
> trigger a parent switch towards a neighbor which can handle the required 
> traffic.


Best,
Yatch

> On Sep 25, 2018, at 10:49, Christian Hopfner 
>  wrote:
> 
> Hello,
>  
> I have not found an answer to my question yet, reading through 6top and msf 
> draft. Is there anything foreseen signaling that a node does not have any 
> bandwidth capacity remaining (max active cells reached, with respect to given 
> policy).
>  
> Let’s assume we have a network with 4 nodes where node R is parent of nodes A 
> and B. Node C is child of A and requires more bandwidth. But A has no 
> additional bandwidth available.
>  
> Node C indicates a 6P ADD to node A which is answered with 6P_SUCCESS but 
> with an empty cellist (2-step transaction). I guess next time node C can try 
> 3-step transaction giving node A the opportunity to propose a cellist. 
> In case Node A has no cells to propose the response should contain 
> RC_ERR_CELLLIST error correct?
>  
> But at the end Node C may end up in a loop trying to get more bandwidth 
> unless node B becomes its preferred parent isn’t it?
>  
> If there would be an error code signaling “out of bandwidth” the SF may 
> trigger a parent switch towards a neighbor which can handle the required 
> traffic.
>  
>  
> 
> Mit freundlichen Grüßen I Best regards 
> 
> Christian Hopfner
> 
> Developer | TPI F Plattform Informatik
> Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
> Phone: +49 7622 28 1883
> christian.hopf...@pcm.endress.com | www.pcm.endress.com 
> 
> 
> Endress+Hauser SE+Co. KG
> Registergericht: Amtsgericht Freiburg i.Br. HRA 670225
> Sitz der Gesellschaft: Maulburg
> Persönlich haftender Gesellschafter: Endress+Hauser Administration SE
> Sitz des persönlich haftenden Gesellschafters: Maulburg
> Registergericht: Amtsgericht Freiburg i.Br. HRB 717326
> Vorstand: Dr. Andreas Mayr
> Aufsichtsratsvorsitzender: Matthias Altendorf
> 
> Gemäss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet, Sie 
> zu informieren,
> wenn wir personenbezogene Daten von Ihnen erheben.
> 
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis nach.
> 
> Endress+Hauser SE+Co. KG
> Register Court: Local Court of Freiburg i.Br. HRA 670225
> Registered Office: Maulburg
> General Partner: Endress+Hauser Administration SE
> Registered Office of General Partner: Maulburg
> Register Court: Local Court of Freiburg i.Br. HRB 717326
> Chief Executive Officer: Dr. Andreas Mayr
> Chairman of the Board: Matthias Altendorf
> 
> According to the General Data Protection Regulation,
> we are obliged to inform you when collecting your personal data.
> We comply with this information duty with the following Data Protection 
> Statement
> 
>  
> Disclaimer: 
> 
> The information transmitted is intended only for the person or entity to 
> which it is addressed and may contain confidential, proprietary, and/or 
> privileged
> material. Any review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon, this information by persons or entities
> other than the intended recipient is prohibited. If you receive this in 
> error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or an 
> acceptance of a contract offer unless explicitly and conspicuously designated 
> or stated as such.
> 
>  
> ___
> 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

Re: [6tisch] Feedback on the 6TiSCH MSF

[Yasuyuki Tanaka]

Hello Atis,

> So, I suggest adding a requirement/recommendation for the implementer to 
> prioritize 6top packets over data packets.

I agree with you. I prefer recommendation here.

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Comments on draft-ietf-6tisch-msf-00

[Yasuyuki Tanaka]

Thank you, Simon and Xavi!

A couple of things:

>>> 'MUST' here sounds too strong... Some may want to use MSF with a base 
>>> schedule
>>> other than one defined RFC 8180 with full understands on implications by not
>>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>> 
>>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
>>> document or not.
>> 
>> MSF assumes the presence of the minimal cell, but might be able to run 
>> without the full RFC8180.
>> Happy to hear what others think
>> 
> XV>> MSF needs at least one pre-existing cell in the schedule so a node can 
> receive/send EBs and form/join into the network. To ensure this we enforce 
> RFC8180.

If the minimal shared cell is only the dependency for MSF, it'd be much clearer 
to say that instead of saying, "MSF MUST implement RFC 8180". RFC 8180 defines 
far more things than having the minimal shared cell. And, it concerns 2.4 GHz 
O-QPSK PHY alone.

>>> * minor comment 6
>>> 
>>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
>>> section?
>>> 
>> I'll let other co-authors answer
>> 
> XV> I think this was though to handle pagination when the LIST command is 
> received. This is, define what are the cells to return when a list command is 
> requesting cells from a particular offset. 

I see; then, I'd like to have such explanation in Section 10 :-)

   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6TiSCH Simulator v1.1.5 Release Announcement

[Yasuyuki Tanaka]

Hi all,

We've released v1.1.5 of the 6TiSCH Simulator, a high-level 6TiSCH simulator
written in Python:

  https://bitbucket.org/6tisch/simulator/src/v1.1.5/

There are a lot of changes/improvements made since v1.0.0 that Malisa announced
last March. Here are a couple of key updates, which may be interesting to you:

  * draft-ietf-6tisch-msf-00 is implemented
  * 6P (draft-ietf-6tisch-6top-protocol-12) is fully supported

MSF of v1.1.5 supports the autonomous cell defined in draft-ietf-6tisch-msf-00
as well as scheduling adaptation to traffic changes. Regarding 6P, all the
commands, return codes, and the 3-step transaction are supported now.

Feel free to contact me if you have any question :-)

Enjoy!
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on RPL Settings in RFC 8180

[Yasuyuki Tanaka]

Hi Pascal,

pascal> Maybe we could amend/ERRATA the RFC to recommend different settings.

It'd be nice to have some amendment or an errata entry for the following
sentence.

rfc8180> (5.3.  Trickle Timer, RFC 8180)
rfc8180>
rfc8180> For this specification, the Trickle timer MUST be used with the
rfc8180> RPL-defined default values (see Section 8.3.1 of [RFC6550]).

At least, "MUST" in this sentence should be replaced with something, in my
opinion.

Best,
Yatch


> On Aug 27, 2018, at 17:45, Pascal Thubert (pthubert)  
> wrote:
> 
> Starting a discussion on your last point, Yatch:
> 
> RFC 6206 says:
> 
> "
>   Finally, a protocol SHOULD set k and Imin such that Imin is at least
>   two to three times as long as it takes to transmit k packets.
> "
> By default k n RPL is set to very conservative 
> DEFAULT_DIO_REDUNDANCY_CONSTANT of 10, so there is not suppression unless 
> there is a high density. 
> So with the 1.01s slotframe, RFC 6206 recommends that Imin should be 20 to 30 
> seconds...
> 
> Maybe we could amend/ERRATA the RFC to recommend different settings.
> 
> What do others think?
> 
> Pascal
> 
>> -----Original Message-
>> From: Pascal Thubert (pthubert)
>> Sent: lundi 27 août 2018 17:29
>> To: 'Yasuyuki Tanaka' ; 6tisch@ietf.org
>> Subject: RE: [6tisch] Questions on RPL Settings in RFC 8180
>> 
>> Hello Yatch
>>> 
>>> (1) Rank Computation
>>> 
>>> RFC 8180 says:
>>> 
>>> rfc8180> 5.1.1.  Rank Computation
>>> rfc8180> (...)
>>> rfc8180> Sp SHOULD be calculated as (3*ETX)-2.  The minimum value of
>>> rfc8180> Sp
>>> rfc8180> (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The
>>> rfc8180> maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor
>>> rfc8180> quality link.  The default value of Sp (DEFAULT_STEP_OF_RANK)
>>> rfc8180> indicates an average quality link.  Candidate parents with
>>> rfc8180> ETX greater than 3 SHOULD NOT be selected.
>>> 
>>>  https://tools.ietf.org/html/rfc8180#section-5.1.1
>>> 
>>> MAXIMUM_STEP_OF_RANK is defined to 9. Why?
>>> 
>> [PT>] This is defined in OF0. 9 denotes a worst possible quality that is 
>> still
>> acceptable and makes it equivalent to 9 hops at the best quality for that
>> technology.
>> The number enables 7 hops at the worst rank factor (4) and with the worst
>> quality.
>> 
>> 
>>> Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is 3.
>>> It looks like 7 is the possible largest value of Sp...
>>> 
>> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max
>> ETX of 3 is arbitrary, we could have gone up to 11/3...
>> 
>> 
>>> (2) Trickle Timer
>>> 
>>> RFC 8180 says:
>>> 
>>> rfc8180> 5.3.  Trickle Timer
>>> rfc8180> (...)
>>> rfc8180> For this specification, the Trickle timer MUST be used with
>>> rfc8180> the RPL-defined default values (see Section 8.3.1 of [RFC6550]).
>>> 
>>>  https://tools.ietf.org/html/rfc8180#section-5.3
>>> 
>>> So, Imin for DIO Trickle timer starts with 8 ms, which looks too short
>>> for the minimal TSCH schedule where one shared cell in a slotframe of
>>> 1.01s. This setting could cause congestion by DIO traffic...
>>> 
>>> Why is this default value (DEFAULT_DIO_INTERVAL_MIN) reasonable for
>>> the 6TiSCH minimal configuration...?
>> [PT>]
>> [PT>] I agree that this needs discussion. Note that the minimal schedule of 
>> 1.01s
>> is just an example.
>> The initial value of I (see RFC 6206) is between Imin and Imax. With the 
>> default,
>> that is between 8ms and 2.3 hours. Hopefully I is not always 8ms! The DIO 
>> will
>> not fire before I/2.
>> I agree we should use a somewhat higher Imin, but then that pushes Imax to 
>> the
>> say and I may be set to that.
>> IOW I'd have liked to restraint the initial setting of I to something in 
>> between,
>> like between a few seconds and a few minutes while keeping Imax to 2^20 times
>> Imin.
>> 
>> Take care,
>> 
>> Pascal
>>> ___
>>> 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

Re: [6tisch] Questions on RPL Settings in RFC 8180

[Yasuyuki Tanaka]

Thank you, Pascal!

> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max 
> ETX of 3 is arbitrary, we could have gone up to 11/3...

OK! That is what I understood. It's very clear now.

> The initial value of I (see RFC 6206) is between Imin and Imax. With the 
> default, that is between 8ms and 2.3 hours. Hopefully I is not always 8ms! 
> The DIO will not fire before I/2.


Regarding the Trickle timer, yes, the initial value of "I" is chosen between 
Imin and Imax. And it's not always 8ms.

But, "I" is reset to Imin (8 ms) when Trickle hears something "inconsistent". 
After that, "I" will be just doubled at the end of interval: 16ms, 32ms, 64ms, 
... This could pile up DIOs in the TX queue and consume bandwidth for nothing. 
:-/

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Questions on RPL Settings in RFC 8180

[Yasuyuki Tanaka]

Hi all,

I have a few questions on the RPL settings described in RFC
8180. Could anyone help me find answers...?

  https://tools.ietf.org/html/rfc8180#section-5

---

(1) Rank Computation

RFC 8180 says:

rfc8180> 5.1.1.  Rank Computation
rfc8180> (...)
rfc8180> Sp SHOULD be calculated as (3*ETX)-2.  The minimum value of
rfc8180> Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The
rfc8180> maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor
rfc8180> quality link.  The default value of Sp (DEFAULT_STEP_OF_RANK)
rfc8180> indicates an average quality link.  Candidate parents with
rfc8180> ETX greater than 3 SHOULD NOT be selected.

  https://tools.ietf.org/html/rfc8180#section-5.1.1

MAXIMUM_STEP_OF_RANK is defined to 9. Why?

Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is
3. It looks like 7 is the possible largest value of Sp...

(2) Trickle Timer

RFC 8180 says:

rfc8180> 5.3.  Trickle Timer
rfc8180> (...)
rfc8180> For this specification, the Trickle timer MUST be used with the
rfc8180> RPL-defined default values (see Section 8.3.1 of [RFC6550]).

  https://tools.ietf.org/html/rfc8180#section-5.3

So, Imin for DIO Trickle timer starts with 8 ms, which looks too short
for the minimal TSCH schedule where one shared cell in a slotframe of
1.01s. This setting could cause congestion by DIO traffic...

Why is this default value (DEFAULT_DIO_INTERVAL_MIN) reasonable for
the 6TiSCH minimal configuration...?

rfc6550> 17.  RPL Constants and Variables
rfc6550> (...)
rfc6550> DEFAULT_DIO_INTERVAL_MIN: This is the default value used to
rfc6550>  configure Imin for the DIO Trickle timer.
rfc6550>  DEFAULT_DIO_INTERVAL_MIN has a value of 3.  This
rfc6550>  configuration results in Imin of 8 ms.

  https://tools.ietf.org/html/rfc6550#section-17

---

There are some email threads on RPL configuration found in 6TiSCH ML
archive. But, I could not find any discussion about above mentioned
points...

- [6tisch] On 2*ETX in Minimal
  https://mailarchive.ietf.org/arch/msg/6tisch/oWmlpcq2evOlf4gH90moG2gyxzg

- [6tisch] 6TiSCH Minimal: step_of_rank
  https://mailarchive.ietf.org/arch/msg/6tisch/BXbfFtysPHJTekkeQXScv1GVxCM

- [6tsch] Zero Objective Function discussion
  https://mailarchive.ietf.org/arch/msg/6tisch/McGiW7IPnhITB74Vz2y2SKXot80

Thank you!
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Hello Tero,

I think I'm very close to the full understanding. Bear with me...

tero> As commented already the text in page 65 consider the case where
tero> we are doing initial transmission, not retransmission.

I see; this would clear my confusion. (note: "page 65" here is a page
number including the cover page, which corresponds to the printed page
number of 64).

So, the text in page 65 uses the term of "transmission" for the two
case: initial transmission and retransmission. In the latter part of
this email, I'll put annotations to each key sentence of section
6.2.5.3 in page 65 (printed-page 64), saying which a sentence refers,
initial transmission or retransmission.

I think, the following topic is the last piece that I don't have a
clear idea of yet.

tero> In those cases we do CCA for macMaxCsmaBackoffs times, but with
tero> TSCH this is not feasible, so if CCA fails, we just assume the
tero> sending of the frame failed, increment NB (which has slightly
tero> different meaning than in 6-5 here) and try again.
tero> ...
tero> Note, that in Figure 6-5 the NB is defined as "NB is the number
tero> of times the CSMA-CA algorithm was required to back off while
tero> attempting the current transmission; this value shall be
tero> initialized to zero before each new transmission attempt." In
tero> Figure 6-6 the NB also includes actual failed retransmissions.
tero> ...
tero> NB was initialized in the Figure 6-5 when we did initial
tero> transmission, and if there was any CCA failures there which
tero> caused us to increment NB, they carry on to Figure 6-6.

Supposing an initial transmission in a shared link fails by CCA, NB is
incremented to 1. Then, should it stay in the CSMA-CA algorithm as
Figure 6-5 explains? Or, if we could take a CCA failure as a
transmission failure, this CCA failure would trigger the
retransmission algorithm with having NB=1. Which is correct?

- (A) CCA failures don't trigger the retransmission algorithm unless
  NB reaches macMaxFrameRetries.

- (B) A CCA failure during a initial transmission process in a shared
  link triggers the retransmission algorithm with keeping the NB
  value, that will be used for retransmissions, unless NB reaches
  macMaxFrameRetries.

I think you meant (B) in your email, which isn't written in the
standard.

>From here, I leave key sentences, prefixed with "std>", in page 65
with annotations.

--- key sentences of 6.2.5.3 in page 65, IEEE 802.15.4-2015

   std> When a packet is transmitted on a shared link for which an
   std> acknowledgment is expected and none is received, the
   std> transmitting device shall invoke the TSCH retransmission
   std> algorithm.

This is talking about the initial transmission of a packet.

   std> Subsequent retransmissions may be in either shared links or
   std> dedicated links as retransmission occurs in the next link to
   std> the destination.

This is obviously about retransmissions.

   std> The retransmission backoff wait applies only to the
   std> transmission on shared links.

This is about retransmissions as well.

I believe, an assumption here is that, once the retransmission
algorithm starts for a certain packet, no initial transmissions for
other packets happen in *shared* links until the retransmission
algorithm ends. While I'd like to discuss this further, it's out of
scope of this thread.

   std> There is no waiting for transmission on dedicated links.

This "waiting" means "the retransmission backoff wait". Then, this
sentence talks about retransmission on dedicated links (without SHARED
bit on), although any transmission in dedicated links have no wait,
either.

   std> The retransmission backoff is calculated in the number of
   std> shared transmission links.

Yes, this is an interesting point of this algorithm and optimization
for TSCH.

   std> The backoff window increases for each consecutive failed
   std> transmission in a shared link.

This is about retransmission failures in shared links.

   std> A successful transmission in a shared link resets the backoff
   std> window to the minimum value.

This is about a retransmission success in a shared link. But this
operation is not necessary since the backoff window (or BE) is reset
on the next execution of the retransmission algorithm.

   std> The backoff window does not change when a transmission is a
   std> failure in a dedicated link.

This is talking about any type of transmission failure in a dedicated
link during the retransmission process (algorithm).

   std> The backoff window does not change when a transmission is
   std> successful in a dedicated link and the transmission queue is
   std> still not empty afterwards.

This is confusing, but now I understand what it is trying to say.

A transmission success in a dedicated cell has no impact on the
backoff window (or BE) unless it is a retransmission for a packet
under on-going retransmission process (algorithm).

And, it should be fine to reset the backoff window by 

Re: [6tisch] WG adoption of the “IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information” document

[Yasuyuki Tanaka]

Hi,

This proposal looks useful. I like the idea of Network ID!

I'm sharing my comments on the draft:

  
https://tools.ietf.org/html/draft-richardson-6tisch-enrollment-enhanced-beacon-01

[1] (trivial comment)

draft>   There are a limited number of timeslots designated as a broadcast
draft>   slot by each router.  These slots are rare, and with 10ms slots, with
draft>   a slot-frame length of 100, there may be only 1 slot/s for the
draft>   beacon.

It may be more natural to use a slot-frame length of *101* since RFC
8180 is referred in the beginning of the same section...

[2] RS/RA confusion...?

draft> 1.3.  Layer-3 synchronization IPv6 Router solicitations and
draft>   advertisements
draft> ...
draft>   unsolicited RAs; if a pledge node does not hear an RA, and decides to
draft>   send a RS (consuming a broadcast aloha slot with unencrypted
draft>   traffic), many unicast RS may be sent in response.

The last sentence should be "many unicast RA may be sent in response"?

draft>  2.  it may require many seconds of on-time before a new pledge hears
draft>   a Router Soliciation that it can use.

This also should be "Router Advertisement" instead of "Router
Solicitation"?

draft>   3.  a new pledge may listen to many Enhanced Beacons before it can
draft>   pick an appropriate network and/or closest Join Assistant to
draft>   attach to.  If it must listen for a RS as well as find the
draft>   Enhanced Beacon, then the process may take a very long time.

Same here. s/RS/RA/

[3] (trivial comment)

draft> 2.  Protocol Definition
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>|   TBD-XXX |R|P| res |  proxy prio |rank priority  |
draft>+-+-+-+-+-+-+-+-+-+-+-+-+
draft> ...
draft>|   |
draft>+-+-+-+-+-+-+-+-+
draft> 
draft>proxy priority  the proxy prority value contains a number from 0 to
draft>   0x7f.  Lower numbers are considered to be a higher preference.  A
draft>   priority of 0x7f indicates that the announcer should never be
draft>   considered as a viable enrollment proxy.  Lower value indicates
draft>   willing to act as a Join Proxy as described in
draft>   [I-D.ietf-6tisch-minimal-security].  Only unenrolled pledges look
draft>   at this value.
draft> 
draft>pan priority  the pan priority is a value set by the DODAG root to
draft>   indicate the relative priority of this LLN compared to those with
draft>   different PANIDs.  This value may be used as part of the
draft>   enrollment priority, but typically is used by devices which have
draft>   already enrolled, and need to determine which PAN to pick.
draft>   Unenrolled pledges MAY consider this value when selecting a PAN to
draft>   join.  Enrolled devices MAY consider this value when looking for
draft>   an eligible parent device.

It would be easier for readers if the order of the field definitions
is the same as the order the fields appear in the figure.

[4] Proxy Address bit

draft>   P  if the Proxy Address bit is set, then the lower 64-bits of the
draft>  Join Proxy's Link Layer address follows the network ID.

It seems the lower 64-bits of the Join Proxy's Link Layer address *is
followed by* the Network ID in the figure.

draft>   Join Proxy's Link Layer address follows the network ID.  If the
draft>   Proxy Address bit is not set, then the Link Layer address of the
draft>   Join Proxy is identical to the Layer-2 8-byte address used to
draft>   originate this enhanced beacon.

By definition, an Enhanced Beacon cannot have a 2-octet link-layer
address in its source address field? Or, if P bit is set, a
transmitter should set its 8-octet link-layer address to the source
address field of an enhanced beacon?

[5] Join-Proxy Address

draft>join-proxy lower-64  if the P bit is set, then 64 bits (8 bytes) of
draft>   address are present.  The Link Layer address of the Join Proxy is
draft>   fe80 (as for any Link Layer address), and the bits given in this
draft>   field.

The last sentence is unclear to me... Does it mean that a link-local
IPv6 address of the Join Proxy can be generated by the bits given in
the field with the link-local prefix, fe80::/64?

[6] Network ID

dfaft>network ID  this is an variable length field, up to 16-bytes in size
dfaft>   that uniquely identifies this network, potentially among many
dfaft>   networks that are operating in the same frequencies in overlapping
dfaft>   physical space.

Can we omit the network ID field?

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Thank you for your comment, Thomas!

> On Jun 14, 2018, at 18:30, Thomas Watteyne  wrote:
> 
> I agree with Fabrice's comments, that's how I read the document.

>> the backoff window is selected randomly between 0 and 2^BE-1. 

I may miss something, but I don't think so

My understanding right now is:

[basics]
- "the backoff window" means the range between 0 and 2^BE -1 
- "the retransmission backoff wait" (delay before the next retransmission) is 
chosen randomly in the backoff window
- the minimum value of BE is macMinBE; the minimum backoff window is the range 
between 0 and 2^macMinBE - 1
- the maximum value of BE is macMaxBE; the maxmum backoff window is the range 
between 0 and 2^macMaxBE - 1 
- after resetting the backoff window, the length of the backoff windows is 
2^macMinBE - 1 long
- only first-attempt transmission (non-retransmission) failures in *shared* 
cells can trigger the retransmission algorithm

[how the backoff window changes as per page-64]
- the backoff window increases for each consecutive failed transmission in a 
shared link
- the backoff window is reset by
   a transmission success in a shared link
   a transmission success in a dedicated link, which makes the TX queue 
empty
- the backoff window is NOT reset by
   a transmission failure a dedicated link
   a transmission success in a dedicated link, which doesn't make the 
TX queue empty

On page-66, it says, "A device upon encountering a transmission failure in a 
shared link shall initialize the BE to macMinBe." In other words,

the backoff window is reset by a first-attempt transmission 
failure, a failure of non-retransmission, in a *shared* link

Supposing that there are two frames in the TX queue and the retransmission 
process for one of the frames ends with a transmission success in a dedicated 
link, the backoff window could remain larger than 2^macMinBE - 1 . 
Then, if a device starts another retransmission process for the next frame in 
the TX queue by a transmission failure in a shared link, the device resets the 
backoff window . 

I think, what made me confused is that rule-4 part. I couldn't see why the 
device should keep the backoff window by rule-4. The backoff window isn't used 
for the first-attempt transmission for the second frame because it's not part 
of the retransmission algorithm. So, the backoff window is just reset when the 
retransmission process starts even though the window size is kept by rule-4... 

If rurle-2 and rule-4 ware written as below, it would make sense:

- the backoff window is reset by
   ...
   a transmission success in a dedicated link, the transmission is for 
a frame under a retransmission process

- the backoff window is NOT reset by
   ...
   a transmission success in a dedicated link, the transmission is for 
a frame which is NOT one under a retransmission process
   ...

However, we don't need rule-2' because the backoff window is reset when 
starting a retransmission process, anyway.

Yes, I'm still confused a little bit... (>_<)

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Thank you, Fabrice!

> the backoff window is selected randomly between 0 and 2^BE-1. 

According to you, the term of "the backoff window" seems to be used as the 
retransmission backoff or the retransmission backoff wait. If so, I was 
confused by a sentence in the third paragraph of the section, "A successful 
transmission in a shared link resets the backoff window to the minimum value."

What is "reset" or the minimum value...?

Perhaps, the backoff window there is meant (2^BE - 1) and its minimum value is 
(2^macMinBe - 1).

> dedicated links > no collision / no backoff. 
> You transmit it without delay 
> (NB: you may have the first transmission during a shared link, and its 
> retransmission in a dedicated one)

Yes, that how it works.

> If I understand correctly the standard, in that case, the dedicated link 
> should not impact the BE value: the next packet will be picked in the queue, 
> and transmitted with the same BE value as previously. 

Hmm, what if that next packet is not acknowledged in the first attempt? 

Will it use the *same* BE value in the following retransmission as perviously 
or use macMinBe as described in the standard, which could be different from the 
BE value used previously...?

> "NB is the number of times the CSMA-CA algorithm was required to back off 
> while attempting the current transmission"

Aha, I see; then we need "NB=0" just after the "Retransmission?" box ;-)

> I have also the same doubts as you for the figure 6.6….

It'd be great if someone is woking on revising the figure... (>_<)

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

[Yasuyuki Tanaka]

Hello all,

Could anyone help me understand correctly the TSCH CSMA-CA
retransmission algorithm described in Section 6.2.5.3 of IEEE
802.15.4-2015, starting from page-64?

I have some questions...:

---

[1] What does it mean exactly by "the backoff window"?

There is no "backoff window" found in Figure 6-6 nor in the latter
part of Section 6.2.5.3...

I think that "the backoff window"indicates BE (Backoff Exponent), but
it's unclear...


[2] Should we reset BE every time retransmission process starts?

Two conditions to reset the backoff window (BE?) are mentioned in page-64:

- "A successful transmission in a shared link resets the backoff window
  to the minimum value."

- "The backoff window is reset to the minimum value if the
  transmission in a dedicated link is successful and the transmit
  queue is then empty."

In page-65, I see another condition if the backoff windows and BE are
the same thing:

- "A device upon encountering a transmission failure in a shared link
  shall initialize the BE to macMinBe."

It seems the former conditions and the latter condition conflict each
other.

I'm not sure, after all the retransmissions for the last frame in
shared links failed, the next retransmission process should reset BE or
not. What about the case when the transmission for the last frame in a
dedicated link was successful but the transmission queue was NOT
empty?


[3] Errors in Figure 6-6

I don't think Figure 6-6 is correct...

- In the frist transmission attempt (the right-most branch):

  o Boxes of "transmit frame" and "transmission acknowledged?" are
missing after "N" to "TschCca=On?"

  o It says transmission fails when NB exceeds macMaxFrameRetries; but
I think, it would enter the retransmission process instead of
"Failure". Which is correct?

- In the retransmission process without PCA (the middle branch):

  o "NB" is not initialized; should "NB=0" be there along with
"BE=macMinBe"?

  o BE should be updated by "BE=min(BE+1, macMaxBe)" instead of
"BE=min(BE-1,macMinBe)", shouldn't it?

I didn't look closer the left-most branch (retransmission with PCA), by the
way.


--- 

Thank you for taking the time to read my email!

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] comments on draft-watteyne-6lo-minimal-fragment-00.txt

[Yasuyuki Tanaka]

Hi all,

I'd like to share my comments on draft-watteyne-6lo-minimal-fragment-00.txt.

   LLN Minimal Fragment Forwarding
   https://www.ietf.org/id/draft-watteyne-6lo-minimal-fragment-00.txt

I have four comments:

[1]
> 1.  Overview of 6LoWPAN Fragmentation
> (snip)
>   In Figure 1, node A has sent fragments 1, 2, 3, 5, 6 to node B, node
>   B has received fragments 1, 2, 3, 6 from node A, fragment 5 is still
>   being transmitted at the link layer from node A to node B.

It'd be nice to explain the figure a little bit more, the symbol of '#' and
numbers above the boxes, like this:

   In Figure 1, a packet forwarded by node A to node B is cut into
   nine fragments, from fragment 1 to fragment 9. Each of them is
   represented with '#' symbol. Node A has sent fragments 1, 2, 3, 5,
   6 to node B, node B has received fragments 1, 2, 3, 6 from node A,
   fragment 5 is still being transmitted at the link layer from node A
   to node B.

[2]
> 3.  Virtual Reassembly Buffer (VRB) Implementation
> (snip)
>   next hop to send this fragment to.  It then creates an entry in the
>   VRB table which contains 4 fields: (1) the link-layer address of the
>   sender of the fragment it received, (2) the datagram_tag of the
>   fragment it received, (3) the link-layer address of the next hop, (4)
>   a datagram_tag for the fragments it will send.  The latter
>   datagram_tag must be locally unique.

This would also need another explanatory note after this paragraph;
for instance, "note that if node E has multiple network interfaces,
the VRB would have (5) the link-layer address of the sender of the
fragment it received, and (6) the link-layer address of the sender of
the fragment it will use."

Technically, each fragment is identified by the combination of the
source link-layer address, the destination link-layer address, and the
datagram_tag as explained in Section 1.

(excerpt from Section 1)
>>   to.  Each fragment can be uniquely identified by the source and
>>   destination link-layer addresses of the frame that carries it, and
>>   the datagram_tag.  The value of the datagram_tag only needs to be
>>   locally unique to nodes A and B.

I guess the reason to use the destination link-layer address is
that the text shown above and RFC 4944 take into account cases
when a node has multiple network interfaces.

Then, E's VRB Table in Fugure 3 should have "L2 dest" as a the
"incoming" column and "L2 src" as a the "outgoing" column. But,
putting them into Figure 3 seems too much. Just adding note would
be enough, I think.

[3]
>   Upon forwarding the last fragment of a packet, the VRB table entry
>   can be cleared, and reused for a future packet.  If the last fragment
>   of a packet is dropped, the VRB table entry can be invalidated by
>   timeout.  Its timeout value is set to a maximum of 60 seconds as the
>   reassembly timeout defined in [RFC4944].

For the explanation about the basic mechanism of VRB, can we assume
fragments of an IPv6 packet are always received in order?

In general, fragments could be received out of order. Because of that,
an intermediate node cannot determine which fragment is the last one
for the correspondent packet without any state on received fragments
in the VRB Table. Every active VRB entry is valid until its
expiration.

However, I believe reordering of fragments rarely happens in reality
with networks which 6tisch WG or 6lo WG deal with. If this is the
case, I'd suggest to keep the paragraph as it is since it's simple and
easy to understand. We may add some text clarifying that this
optimization works under a certain condition, that is, fragments are
received in order.

>   A simple implementation may do away with any attempt to keep packet
>   data in the virtual reassembly buffer.  It then has to discard all
>   non-first fragments for which a reassembly buffer is not already
>   available (penalizing reordering, which however may be rare).

I agree.

[4]
> 4.  Critique of VRB
> (snip)
>   It is possible for a network to be composed of some nodes that
>   implement VRB, and others that don't.  Nodes that do not implement
>   VRB reassemble the packet.

The last sentence is forgotten to be removed...?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Comments on draft-chang-6tisch-msf-00

[Yasuyuki Tanaka]

Hi all,

I'd like to share my comments on draft-chang-6tisch-msf-00:

   https://tools.ietf.org/html/draft-chang-6tisch-msf-00

The first one is about 6P CLEAR after detecting unreachability to a neighbor.

> 3.8.  Step 7 - Neighbor Polling
> 
> (snip)
> 
>When a neighbor is declared unreachable, the node MUST issue a 6P
>CLEAR to that neighbor (which can fail at the link-layer), and MUST
>remove all dedicated links with that neighbor from its own schedule.


Why does the node have to issue a 6P CLEAR to a neighbor which is determined to 
be unreachable...? It just wastes time and energy of the initiator since this 
transaction will fail as the draft mentioned. I think it'd be fine to remove 
all the dedicated cells to the unreachable neighbor without 6P CLEAR. By the 
way, the term "cells" should be used instead of "links".

Other comments are trivial.

> 1.  Introduction
> 
> (snip)
> 
>MSF is designed to operate in a wide range of application domains.
>It is optimized for applications with regular upstream traffic (from
>the nodes to the Internet).  

"The internet" sounds too specific. "From the nodes toward the root" would be 
better?

> 2.  Interface to the Minimal 6TiSCH Configuration
> 
> (snip)
> 
>MSF uses the minimal cell to exchange the following packets:
> 
> ...
> 
>4.  The first 6P packet a node issues to a neighbor it doesn't have
>dedicated cells to, as defined by
>[I-D.ietf-6tisch-6top-protocol].  These are unicast frames.

The minimal cell is used for not only the first 6P packet but also subsequent 
packets associated with a 6P transaction initiated by the first packet. In this 
sense, I'd like to propose to replace it with:

   6P packets to schedule the first dedicated cell with a neighbor. There are 
unicast frames.

> 7.  Rules for CellList
> 
> 
>MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
>only initiated by a node towards it preferred parent.  As a result,
>the cells to put in the CellList of a 6P ADD command, and in the
>candidate CellList of a RELOCATE command, are chosen by the node.  In
>both cases, the same rules apply:
> 
>   the CellList SHOULD contain 5 or more cells.
>   Each cell in the CellList MUST have a different slotOffset value.
>   For each cell in the CellList, the node MUST NOT have any
>   scheduled cell on the same slotOffset.
>   The slotOffset value of any cell in the CellList MUST NOT be the
>   same as the slotOffset of the minimal cell (slotOffset=0).
>   The slotOffset of a cell in the CellList SHOULD be randomly and
>   uniformly chosen among all the slotOffset values that satisfy the
>   restriction above.
>   The channelOffset of a cell in the CellList SHOULD be randomly and
>   uniformly in [0..numFrequencies] where numFrequencies represents
>   the number of frequencies a node can communicate on.


Is this a format error...?

> 8.  6P Timeout Value
> 
> 
>The 6P Timeout is not a constant value.  It is calculated a (C/
>PDR)*6PTIMEOUT_SEC_FACTOR, where:


I think it'd be better for a variable name to start with a non-numeric 
character even in a document.

That's it!

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

[Yasuyuki Tanaka]

Hello Pascal,

> I published -13 with the corrected picture and some other refreshes.

Thank you; I like this picture better than one in -12! :-)

Best,
Yatch

On 2017/11/30 14:04, Pascal Thubert (pthubert) wrote:

Hello Yatch:

I published -13 with the corrected picture and some other refreshes.

IPv6 runs over 6top which is the sublayer that decides which time slot 
is used for which packet (scheduler). 6P is considered as part of that 
layer.


  It is unclear whether some future SF also impacts the scheduler but I 
expect it may, e.g. to hint on which time slot gets which flow.


  The picture is better now thanks to your suggestions. I do not see how 
to improve it further on that matter but I’m open to suggestions!


Take care,

Pascal


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

[Yasuyuki Tanaka]

Hello Pascal,

I have one minor comment on Figure 1 of the draft;

  https://tools.ietf.org/html/draft-ietf-6tisch-architecture-12#section-3.1

My suggestion is to put "6LoWPAN HC / 6LoRH" directly on "IEEE Std 
802.15.4 TSCH" and to add one box labeled with "Scheduling Functions". 
It would look like...


(suggested version)

  +-+-+
  |COMI   |
  +-+-+-+--+---+-+
  | CoAP/EDHOC/COSE |  6LoWPAN ND  | RPL |
  +-+-+-+--+---+-+
  |   UDP   |ICMPv6  |
  +-+-+-+-+---+--++
  | IPv6 |  Scheduling Functions  |
  +--++
  |6LoWPAN HC   /   6LoRH|  6top protocol |
  +--++
  | IEEE Std 802.15.4 TSCH|
  +---+

(current version)

  +-+-+
  |COMI   |
  +-+-+-+--+---+-+
  | CoAP/EDHOC/COSE |  6LoWPAN ND  | RPL |
  +-+-+-+--+---+-+
  |   UDP   |  ICMP  |
  +-+-+-+-+---+--++
  | IPv6  |
  +---+
  | 6LoWPAN HC   /   6LoRH|
  +---+
  |   6top|
  +---+
  | IEEE Std 802.15.4 TSCH|
  +---+

"ICMP" is replaced with "ICMPv6" as well.

Thanks!

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] new command for 6P

[Yasuyuki Tanaka]

Xavi,

Thank you for the example!

xavi> do you think makes sense?
Yes, I do :-)

Best,
Yatch


On 2017/07/20 5:19, Xavi Vilajosana Guillen wrote:

Hi Yatch,

here an example,

assume we have a fancy SF (named SFz) that requires to configure certain 
timeouts in a certain manner. Consider that this configuration cannot be 
deployed statically or pre-shared as it may depend on the app 
requirements, node rank or can be varying in time.


When a node in that network starts, joins through minimal and 
minimal-security and the SFz needs to start allocating cells, before 
however, it needs to configure the timeouts to meet the application 
requirements in that node.


Using the SIGNAL command with an IE that is defined by the SFz document, 
two nodes will be able to install the configuration.


In detail, node A is time source of Node B. Assume Node B joins and the 
SFz sends a SIGNAL command to Node A with the timeout configuration for 
the link. Node B verifies the content of the received SFz IE in the 
SIGNAL command and sends back a Response confirming the configuration. 
If all worked both nodes install the configuration.


do you think makes sense?
regards,
Xavi


2017-07-19 22:30 GMT+02:00 Yasuyuki Tanaka <yatch1.tan...@toshiba.co.jp 
<mailto:yatch1.tan...@toshiba.co.jp>>:


Xavi,

That sounds interesting.

Could you share any example what kind of configuration will be
conveyed in a Signal Request and/or Response?

Best,
Yatch

On 2017/07/19 19:22, Xavi Vilajosana Guillen wrote:

Dear all,

I would like to propose a new command to be used to the 6P
Protocol. The command may be used to configure SF or exchange
information between the SF of the communicating nodes. The
command can be named SIGNAL and 6P will not define the content
but only the operation and encapsulation. The content will be
defined by the different SFs as an IE.

I think that a message like this brings flexibility to SFs to
implement configuration operations.

what do you think?
regards,
Xavi

-- 
Dr. Xavier Vilajosana

Wireless Networks Lab
/Internet Interdisciplinary Institute (IN3)
Professor/
(+34) 646 633 681 <tel:%28%2B34%29%20646%20633%20681>
xvilajos...@uoc.edu <mailto:xvilajos...@uoc.edu>
<mailto:usu...@uoc.edu <mailto:usu...@uoc.edu>>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

Universitat Oberta de Catalunya
­





--
Dr. Xavier Vilajosana
Wireless Networks Lab
/Internet Interdisciplinary Institute (IN3)
Professor/
(+34) 646 633 681
xvilajos...@uoc.edu <mailto:usu...@uoc.edu>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

Universitat Oberta de Catalunya
­


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] new command for 6P

[Yasuyuki Tanaka]

Xavi,

That sounds interesting.

Could you share any example what kind of configuration will be conveyed 
in a Signal Request and/or Response?


Best,
Yatch

On 2017/07/19 19:22, Xavi Vilajosana Guillen wrote:

Dear all,

I would like to propose a new command to be used to the 6P Protocol. The 
command may be used to configure SF or exchange information between the 
SF of the communicating nodes. The command can be named SIGNAL and 6P 
will not define the content but only the operation and encapsulation. 
The content will be defined by the different SFs as an IE.


I think that a message like this brings flexibility to SFs to implement 
configuration operations.


what do you think?
regards,
Xavi

--
Dr. Xavier Vilajosana
Wireless Networks Lab
/Internet Interdisciplinary Institute (IN3)
Professor/
(+34) 646 633 681
xvilajos...@uoc.edu 
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

Universitat Oberta de Catalunya
­


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6TiSCH interop: 6LoRH and OSCOAP as a requirement?

[Yasuyuki Tanaka]

Hi,

Here is my understanding...

- 1. If you're sending a LOWPAN_IPHC frame without 6LoRH, it'd be better 
to use page-0 LOWPAN_IPHC, without paging dispatch, in case a receiver 
is a legacy, non-6TiSCH, node.


- 2. Since a node may receive a page-1 LOWPAN_IPHC frame without 6LoRH, 
it'd be better to support paging dispatch even though the node doesn't 
support 6LoRH.


The first thing is the same as what Simon pointed out with the text in 
RFC 8025. The second thing is what is shown in 3.6.1 of 
draft-munoz-6tisch-examples-02.


Best,
Yatch

On 2017/07/05 19:50, Carsten Bormann wrote:

You indeed don’t need page 1 for IPHC.
You need to be on page 1 once you need 6LoRH.

(My proposal was to simply define 6TiSCH to start in page 1.  No idea whether 
that removes any ever-so-remote compatibility with 6LoWPAN or if there is any 
other reason to start off in page 0.)

Grüße, Carsten



On Jul 5, 2017, at 12:02, Simon Duquennoy  wrote:

In Thomas' example
https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-3.6.1
there is a page dispatch to page 1 (0xf1) followed by IPHC (no routing
header). In this case, couldn't one choose to elide the page dispatch
and directly include IPHC? Or is the IPHC different from a page 0
IPHC?
Just checking if we're on the same page (no pun intended ;))

Thanks,
Simon


On Wed, Jun 28, 2017 at 1:41 AM, Michael Richardson
 wrote:


Thomas Watteyne  wrote:

Simon, all, FYI, we agreed on Friday that using paging dispatch is the
right way forward. I propose we continue discussing on the plugtests
ML if that's going to create problems.


Yes, but the point is that a non-6loRH node will not be able to decode other
than "page 1", and we have no signaling mechanism to tell a 6loRH node to
"fall back".

That was intentional... We discussed having a flag in the RPL DIO to say if
there were old nodes present, but decided it wasn't worth it.


--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-





___
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

Re: [6tisch] Wireshark Dissector for draft-ietf-6tisch-6top-protocol-07

[Yasuyuki Tanaka]

Hi Thomas,

Jonathan's 6LoRH patch has not been merged yet; it's under review.

Yatch

On 2017/07/04 13:23, Thomas Watteyne wrote:
Great, thanks for the update. I understand Remy and Jonatyan have also 
been pushing the 6LoRH code to Wireshark. Is the build you point to now 
complete (i.e. parses 6LoRH, 6P, etc)?


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] SFID Definition

[Yasuyuki Tanaka]

Hi,

I found a conflict between the ranges defined in Figure 29 of 
draft-ietf-6tisch-6top-protocol-06:


+---+--+
| Range | Registration Procedures  |
+---+--+
| 0-128 | IETF Review or IESG Approval |
|   128-255 | Expert Review|
+---+--+

 Figure 29: SF Identifier (SFID): Registration Procedures.


https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-06#section-8.2.5

Which registration procedure is needed for SFID 128?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] consolidating 6P/6LoRH Wireshark dissectors

[Yasuyuki Tanaka]

Thank you, Xavi!


Important things have not changed.I see; I won't make an excuse with the draft-06 
release... (>_<)


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] consolidating 6P/6LoRH Wireshark dissectors

[Yasuyuki Tanaka]

Hello Thomas,

As far as I know, the latest official Wireshark stable release, v2.2.7, 
doesn't contain the 6P dissector.



- the latest official Wireshark build contains reasonably-up-to-date dissectors 
of 6P, no 6LoRH


Development versions would have; they are available at the following page.

https://www.wireshark.org/download/automated/

While I'm working on draft-05 support, slow progress... By the way, I 
notice the newer draft, draft-06, is released.


> We will also discuss this at the 6TiSCH interim latest today [1],
> so join if you are working on this.
I'm not sure I can make it...

Best,
Yatch

On 2017/06/23 15:56, Thomas Watteyne wrote:

All,

I'm starting this thread to try to understand the state of the different 
Wireshark dissectors. Through the last plugtests, we have had 
contribution of several of you with Wireshark dissectors for 6P and 
6LoRH. These dissectors were used extensively during plugtest, and as a 
base to put together 
https://tools.ietf.org/html/draft-munoz-6tisch-examples-00.


Per 
https://tools.ietf.org/html/draft-munoz-6tisch-examples-00#section-1, we 
last used dissectors from the OpenWSN project, which were integrated in 
a "private" build of Wiresharkyou can download at 
http://builder.openwsn.org/job/6TiSCH%20Wireshark/.


Drafts have evolved, and some of the dissectors have been pushed to the 
official Wireshark build. I understand that the state is now:
- the latest official Wireshark build contains reasonably-up-to-date 
dissectors of 6P, no 6LoRH

- the OpenWSN dissectors contain an up-to-date 6LoRH implementation

I'd like to make sure the latest build of the official Wireshark is 
completely up-to-date, i.e. both 6P and 6LoRH.


If you have an update about dissectors, please let this thread know. We 
will also discuss this at the 6TiSCH interim latest today [1], so join 
if you are working on this.


Thomas

[1] https://www.ietf.org/mail-archive/web/6tisch/current/msg05379.html

--
___

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 
___


___
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

Re: [6tisch] 6TiSCH Interoperability Event - PRAGUE 14-15/7/2017

[Yasuyuki Tanaka]

Hello Maria Rita,

Thank you! I'm opening the page right now :-)

Best,
Yatch

On 2017/06/02 23:55, Maria Rita Palattella wrote:

Dear all,

I am glad to announce that together with the support of ETSI, in the 
framework of the F-Interop Project, we are organising a 6TiSCH 
Interoperability event.
The Plugfest will take place in Prague, on 14-15 July 2017, before the 
IETF99 meeting.


All details are available here:
http://www.etsi.org/news-events/events/1197-6tisch-interop-prague-2017

Registration is opened!
It will be closed on 30/6/2017.

Looking forward to see you in Prague.
Maria Rita



___
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

Re: [6tisch] Plugtest Registration Site...?

[Yasuyuki Tanaka]

Thank you, Xavi!

> I think this will be announced soon, maybe this Friday.
I'm looking forward to it ;-)

Best,
Yatch


On 2017/05/31 23:18, Xavier Vilajosana wrote:

Hi Yatch,

I think this will be announced soon, maybe this Friday.

regards,
Xavi

2017-05-31 14:36 GMT+02:00 Yasuyuki Tanaka 
<yasuyuki9.tan...@toshiba.co.jp <mailto:yasuyuki9.tan...@toshiba.co.jp>>:


Hi all,

Is there any web page such as a registration site which provides
details on the plugtest in July...?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch
<https://www.ietf.org/mailman/listinfo/6tisch>




___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] Plugtest Registration Site...?

[Yasuyuki Tanaka]

Hi all,

Is there any web page such as a registration site which provides details 
on the plugtest in July...?


Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] effectively used cells - Re: nits on draft-ietf-6tisch-6top-sf0-02

[Yasuyuki Tanaka]

Hi,

I'm reading the new draft of SF0 and noticed the authors have resolved comments
on a phrase of "effectively used cells" in it!

   https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-03

However, there is still one "effectively used cells" remaining in section 2:

draft> ... In order to reduce consumption, this algorithm is triggered only when
draft> there is a change on the number of effectively used cells or if there is
draft> a change on the number of requested cells from a particular node.

Should this "effectively used cells" be replaced with "required cells" or should
"the number of effectively used cells" be replaced with "the current number of
required cells" according to section 4...?

Thank you!
Yatch

On 2017/03/05 22:13, Yasuyuki Tanaka wrote:

Nice comments!

I also want to see the definition of "effectively used cell" and
how to calculate PDR.

In addition, I don't think that we would count the number of
cells used for 6P in terms of SF0. Is it correct? In any case,
some text on how SF0 should handle traffic or cell usage by 6P
would be helpful.

Best,
Yatch

On 2017/03/05 11:20, Randy Turner wrote:

Hi All,

After reading the current SF0 document, I had a few nits that I thought I would 
pass along - hope they’re helpful.


Section 2: Introduction

(The Scheduling Algorithm)

“…under effective use…”   the choice of wording seems unorthodox.

Suggest the following  “A portion of these allocated cells will be effectively 
utilized by neighbors, while the remaining cells can be over-provisioned to 
handle unanticipated increases in cell requirements”

(The Relocation Algorithm)

“Allocated cells may experiment packet loss” should be “Allocated cells may 
experience packet loss…”



Section 4: SF0 Triggering Events

1. “…change in the current number of used cells”  - could this be paraphrased 
to say “…a change in the number of required cells”  ?



Section 5: SF0 Estimation Algorithm

The Cell Estimation Algorithm steps, # 2 - What is an “effectively” used cell?  
Could this just say “Collect the current number of used cells” ?

There is actually quite a bit of emphasis in this document on the idea of an 
“effectively used cell” - perhaps we should explain the concept of an 
effectively used cell (or a reference if it’s already defined) - I was curious 
why the term “effective” is used so often?  In the “Cell Estimation Algorithm” 
Step #2, the text reads:
“Collect the current number of effectively used cells” — which would seem to 
imply that ineffectively used cells wouldn’t be included in this step.  This 
may seem a too literal interpretation, I’m just looking for clarity as to 
whether or not the term “effective” or “effectively” is really needed in the 
doc.


Section 11: Relocating Cells

Just for completeness, I would emphasize how PDR is calculated, or include a 
reference to some other document if defined elsewhere




Thanks for this work!
Randy
___
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

Re: [6tisch] Comments/questions about 6P draft

[Yasuyuki Tanaka]

Hi Qin,

>> In Figure 11, is there is mix-up between line 2 & 3 ...
>> and the line 6 & 7?
>
> Oh, I didn't notice that!!
Oops, you're right... Thank you! :-)

draft> Figure 10: Format of the CellOptions field
draft>
draft>Note: assuming node A issues the 6P command to node B.
draft>  ^^
draft>+-+---+
draft>| CellOptions | B's action when receiving a 6P message from A |
draft>| Value   | ^^|
draft>+-+---+
draft>|TX=0,RX=0,S=0| select all cells scheduled with A |
draft>+-+---+
draft>|TX=1,RX=0,S=0| select the cells scheduled with A |
draft>| | and marked as RX  |
draft>+-+-------+

Best,
Yatch

On 2017/02/02 16:38, Yasuyuki Tanaka wrote:

Hi Rémy,

From my understanding, CMD_CLEAR won't have any impact on hard cells since hard
cells are read-only for 6top.

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.1
draft> 3.1.  Hard/Soft Cells
draft>
draft>6top qualifies each cell in the schedule as either "hard" or "soft":
draft>
draft>o  a soft cell can be read, added, deleted or updated by 6top.
draft>o  a hard cell is read-only for 6top.
draft>In the context of this specification, all the cells used by 6top are
draft>soft cells.


In Figure 11, is there is mix-up between line 2 & 3 ...
and the line 6 & 7?


Oh, I didn't notice that!!

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-4.2.6
(row-2 in Figure 11)
draft>+-+---+
draft>|TX=1,RX=0,S=0| select the cells scheduled with A |
draft>|^^   | and marked as RX  |
draft>| |   ^^  |
draft>+-+---+


Also, I think it would be useful to define what SHARED means, I fail to find
the definition in this draft.


I agree; we'd need some text explaining the meaning of each bit listed in
Figure 10. Actually, the idea come from Link Options defined in Section 7.4.4.3
in IEEE Std 802.15.4(-2015).

Best,
Yatch

On 2017/02/02 14:09, Remy Leone wrote:

Hello,

I got a bunch of remarks about the 6P draft
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03

_4.1.1. 2-step 6top Transaction_
_4.1.2. 3-step 6top Transaction_

Maybe it would be nice to add at the end of the workflow that if the 
transaction was successful, the schedule generation is incremented to allow 
inconsistencies detection.

_4.2.4. 6P Command Identifiers_

CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or 
both cells that are concerned.

_4.2.6. 6P CellOptions_

In Figure 11, is there is mix-up between line 2 & 3
TX=1, *RX=0*, S=0 | select the cells scheduled with A and marked as *RX*
*TX=0*, RX=1, S=0 | select the cells scheduled with A and marked as *TX*

and the line 6 & 7?

*TX=1*, RX=0, S=1 | select the cells scheduled with A and marked as *RX* and 
SHARED
TX=0, *RX=1*, S=1 | select the cells scheduled with A and marked as *TX* and 
SHARED

TX and RX don't seem to match.

Also, I think it would be useful to define what SHARED means, I fail to find 
the definition in this draft.

_4.3.6. Clearing the Schedule_

I think it would be a good idea to specify whether it's hard cells or soft 
cells (or both) that are concerned by this.

_6. Implementation Status_

Support for 6P in Wireshark was merged upstream
https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58
Therefore there is a need to update the text concerning the Wireshark dissector.


Best regards

Rémy


___
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

Re: [6tisch] Comments/questions about 6P draft

[Yasuyuki Tanaka]

Hi Rémy,

From my understanding, CMD_CLEAR won't have any impact on hard cells since hard
cells are read-only for 6top.

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.1
draft> 3.1.  Hard/Soft Cells
draft>
draft>6top qualifies each cell in the schedule as either "hard" or "soft":
draft>
draft>o  a soft cell can be read, added, deleted or updated by 6top.
draft>o  a hard cell is read-only for 6top.
draft>In the context of this specification, all the cells used by 6top are
draft>soft cells.


In Figure 11, is there is mix-up between line 2 & 3 ...
and the line 6 & 7?


Oh, I didn't notice that!!

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-4.2.6
(row-2 in Figure 11)
draft>+-+---+
draft>|TX=1,RX=0,S=0| select the cells scheduled with A |
draft>|^^   | and marked as RX  |
draft>| |   ^^  |
draft>+-+---+


Also, I think it would be useful to define what SHARED means, I fail to find
the definition in this draft.


I agree; we'd need some text explaining the meaning of each bit listed in
Figure 10. Actually, the idea come from Link Options defined in Section 7.4.4.3
in IEEE Std 802.15.4(-2015).

Best,
Yatch

On 2017/02/02 14:09, Remy Leone wrote:

Hello,

I got a bunch of remarks about the 6P draft
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03

_4.1.1. 2-step 6top Transaction_
_4.1.2. 3-step 6top Transaction_

Maybe it would be nice to add at the end of the workflow that if the 
transaction was successful, the schedule generation is incremented to allow 
inconsistencies detection.

_4.2.4. 6P Command Identifiers_

CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or 
both cells that are concerned.

_4.2.6. 6P CellOptions_

In Figure 11, is there is mix-up between line 2 & 3
TX=1, *RX=0*, S=0 | select the cells scheduled with A and marked as *RX*
*TX=0*, RX=1, S=0 | select the cells scheduled with A and marked as *TX*

and the line 6 & 7?

*TX=1*, RX=0, S=1 | select the cells scheduled with A and marked as *RX* and 
SHARED
TX=0, *RX=1*, S=1 | select the cells scheduled with A and marked as *TX* and 
SHARED

TX and RX don't seem to match.

Also, I think it would be useful to define what SHARED means, I fail to find 
the definition in this draft.

_4.3.6. Clearing the Schedule_

I think it would be a good idea to specify whether it's hard cells or soft 
cells (or both) that are concerned by this.

_6. Implementation Status_

Support for 6P in Wireshark was merged upstream
https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58
Therefore there is a need to update the text concerning the Wireshark dissector.


Best regards

Rémy


___
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

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

[Yasuyuki Tanaka]

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 

Re: [6tisch] [6TiSCH] sixtop relocation command format/sixtop general message format?

[Yasuyuki Tanaka]

Hi Tengfei,

My first impression of your ideas is that it's a bit complicated,
especially the idea of generalizing Add, Delete, and Relocate
commands. I'd suggest discussing the Relocation command format alone
first.

I have another comment, which is more technical.


it will ends up something with two list of cell in the packet and
having (a) fields to indicate where the cell list to be added and
list to be removed are. (snip)

  * if there are both two list of cell, and they have the same
number, then RELOCATE command..


To my understanding, the Relocate command is something like an alias
command of the Add and Delete combination. In that sense, the cell
list to add and the cell list to delete could have different lengths.

The number cells in the cell list to add could be more than the number
of cells a requester wants to relocate. This is the same thing as the
Add command has a smaller value for NumCells than the length of
CellList. If a requester hesitates to specify which cells are
candidates to relocate to, it may put an empty cell list to add in a
Relocation request as the 3-step transaction of the add operation. The
same thing might happen with the cell list to delete in relocation,
although it's less likely than the case of the cell list to add.

We might define that the two cell lists MUST have the same length. In
this case, we would lose flexibility in choosing which cells to
relocate to...

That's my two cents. Thanks!

Best,
Yatch

On 2016/12/09 16:53, Tengfei Chang wrote:

Dear all,

As we are going to have RELOCATE command in sixtop draft, then we will need add 
a specific format for RELOCATE. Though the format is not discussed yet, but I 
think finally it will ends up something with two list of cell in the packet and 
having (a) fields to indicate where the cell list to be added and list to be 
removed are. Of course , with RELOCATE command byte in the frame. I think this 
format can be a general format for ADD , DELETE  and RELOCATE.

With such format,

  * if there is only list of cell to be added, then the frame can be 
represented as ADD command
  * if there is only list of cell to be removed, then DELETE  command
  * if there are both two list of cell, and they have the same number, then 
RELOCATE command..

The benefit of using this two cell list format is that:

If the node wants to relocate one cell and at the same time add some cells OR 
delete some cells, with single sixtop transaction, which is

  * there are two list of cell, one for adding, one for deleting, but length of 
adding list is longer than deleting list (Add command+Relocation command)
  * there are two list of cell, one for adding, one for deleting, but length of 
adding list is shorter than deleting list (Delete command+Relocation command)

Let me know your thought.

Tengfei

--
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

Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka]

Hi Qin,


I think nodeA=>nodeB request process includes two parts, one is Tx
from nodeA to nodeB, another part is for nodeB's MAC to process the
Request message. As you mentioned, failure of the first part can be
identified by mac-ack from nodeB, but not the second part. Right?


Yes, that's right! I believe we are now on the same page about the
approach using timeout.

In this sense, ability to identify failure without inconsistency
occurred in the second part is the only advantage of the generation
counter, which is achieved by consuming four bits in every 6P packet
and keeping inter-transaction state for every neighbor. In my opinion,
this advantage is a little thing for the price to pay...

Best,
Yatch


On 2016/12/01 21:45, Qin Wang wrote:

Hi Yasuyuki,

I think nodeA=>nodeB request process includes two parts, one is Tx from nodeA 
to nodeB, another part is for nodeB's MAC to process the Request message. As you 
mentioned, failure of the first part can be identified by mac-ack from nodeB, but 
not the second part. Right?

Thanks
Qin


On Wednesday, November 30, 2016 1:49 PM, Yasuyuki Tanaka 
<yasuyuki9.tan...@toshiba.co.jp> wrote:


Thanks, Qin.


(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a inconsistency between its schedule and
nodeB's schedule just based on Timeout. Right?


That is right; failure in the nodeA=>nodeB case is what I called
"false positive." But, nodeA could lower the possibility of false
positive by using MAC-layer ACK, implementation efforts. If nodeA
doesn't receive a MAC-layer ACK to its request frame, nodeA can
consider the transaction as having failed without inconsistency.


(2) sending CLEAR, or STATUS, or LIST usually happens after a
inconsistency is found, and the function of generation counter is
exactly to find out the inconsistency. Make sense?


I'd say the generation counter is not the only way to detect
inconsistency. STATUS/LIST could detect it as well, although
STATUS/LIST always fails with RC_ERR_GEN in a case of inconsistency
according to the latest draft.

The generation counter can find inconsistency as you mentioned, but it
has disadvantages:

- It needs 6P to keep per-neighbor states (ignore SeqNum for now) even
  when there is no ongoing transaction.

- It cannot detect inconsistency until a subsequent transaction; it
  may take a long time.

The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.

I still cannot see why the generation management at 6P is really needed...

Best,
Yatch


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka]

Thanks, Qin.


(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a inconsistency between its schedule and
nodeB's schedule just based on Timeout. Right?


That is right; failure in the nodeA=>nodeB case is what I called
"false positive." But, nodeA could lower the possibility of false
positive by using MAC-layer ACK, implementation efforts. If nodeA
doesn't receive a MAC-layer ACK to its request frame, nodeA can
consider the transaction as having failed without inconsistency.


(2) sending CLEAR, or STATUS, or LIST usually happens after a
inconsistency is found, and the function of generation counter is
exactly to find out the inconsistency. Make sense?


I'd say the generation counter is not the only way to detect
inconsistency. STATUS/LIST could detect it as well, although
STATUS/LIST always fails with RC_ERR_GEN in a case of inconsistency
according to the latest draft.

The generation counter can find inconsistency as you mentioned, but it
has disadvantages:

- It needs 6P to keep per-neighbor states (ignore SeqNum for now) even
  when there is no ongoing transaction.

- It cannot detect inconsistency until a subsequent transaction; it
  may take a long time.

The reactive approach using timeout doesn't have such disadvantages;
furthermore, it's simpler than the the schedule generation management,
in my opinion.

I still cannot see why the generation management at 6P is really needed...

Best,
Yatch

On 2016/11/30 17:39, Qin Wang wrote:

Hi Yasuyuki,

(1) Timeout in nodeA can be triggered either by failure in nodeA=>nodeB request 
process and by failure in nodeB=>nodeA response process (i.e the process in above 
example). nodeA cannot tell exact reason for a event of Timeout by itself. In another 
word, nodeA cannot tell there is a inconsistency between its schedule and nodeB's 
schedule just based on Timeout. Right?

(2) sending CLEAR, or STATUS, or LIST usually happens after a inconsistency is 
found, and the function of generation counter is exactly to find out the 
inconsistency. Make sense?

Thanks
Qin


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka]

Hi Qin,

Hmm, in your example, node A can resolve the inconsistency without
using the generation counter by sending CLEAR to node B after the
timeout occurs. Node A could use STATUS or STATUS+LIST before sending
CLEAR in order to confirm inconsistency if the schedule generation
inconsistency detection was disabled...

Best,
Yatch


On 2016/11/29 22:40, Qin Wang wrote:

Hi Yasuyuki,

I'm not sure I fully understand you.

Let's assume node A wants to ADD cells with nodeB in 2-step
transaction. After nodeA sends ADD Request to nodeB, the Timeout of
nodeA is set. nodeB receives the ADD Request, adds the cells to its
schedule and sends Response back to nodeA at same
time. Unfortunately, nodeA does not get the Response before Timeout,
then the schedules on two sides become inconsistent. In this case,
only generation counter in the following message exchange can tell
the difference. right?

Thanks
Qin


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] SF in the terminology draft (draft-ietf-6tisch-terminology-07)

[Yasuyuki Tanaka]

Hi all,

I'd suggest updating the explanation of SF in order to reflect what
SF really does. Here is the current test for SF:

   SF: The "6top Scheduling Function" (SF) is the policy inside
   the "6TiSCH Operation Sublayer" (6top) which decides when
   to add/remove cells.  General guidelines for designing a
   SF are provided in [I-D.wang-6tisch-6top-protocol].

SF does more than just deciding when to add/remove cells. How does the
following text sound? I got some hints from Section 4.2.2 of the
architecture draft:

   The "6top Scheduling Function" (SF) the cell management entity that
   allocates or deallocates cells dynamically based on its allocation
   policy in order to fulfill cell requirements. Its cell negotiation
   with a neighbor is done with use of 6P. General guidelines for
   designing a SF are provided in [draft-ietf-6tisch-6top-protocol].

That's just my two cents...

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka]

Hi Qin,

Thank you for replying to my long email!!

I put the two cases you provided below, in which schedule generation
inconsistency could occur:

(1) failure in communication because of PHY problems like bed channel
condition, collision

(2) failure in processing because of MAC problems such as buffer
overflow.

These failures cause timeout at the 6P layer, don't they?

Why don't we consider a transaction ending with timeout as conceivably
inconsistent? If we would do that, we would not need to maintain the
generation counter; we would use wider bit space for SeqNum in a 6P
message. 6P could be simpler. It's up to a corresponding SF how to
deal with such a transaction.

Relying on timeout alone, we cannot tell if a concerned operation is
committed by a correspondent when the transaction ends with timeout. An
example is the case where a request is lost because of (1) or (2) in
2-step transaction. If the operation is not committed, the requester
takes wrongly the transaction as inconsistent. This case is what I
call false positive. It's not a big deal, I guess...

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] 6P unclarities

[Yasuyuki Tanaka]

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 

Re: [6tisch] Wireshark Dissector for draft-ietf-6tisch-6top-protocol-03

[Yasuyuki Tanaka]

Hi Thomas,


We are going to work on 6P again, so I'm afraid a couple of more
edits might be needed :-\


A new patch will come out if necessary ;-)

Best,
Yatch

On 2016/11/22 19:48, Thomas Watteyne wrote:

Awesome, thanks Yatch!

We are going to work on 6P again, so I'm afraid a couple of more edits might be 
needed :-\

On Tue, Nov 22, 2016 at 7:11 PM, Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp 
<mailto:yasuyuki9.tan...@toshiba.co.jp>> wrote:

Hi all,

A patch to support 6P of draft-03 has been merged into the master
branch of Wireshark with the short commit hash of 0f36cf6. This patch
updates the code based on draft-02 that was already there.

The latest packages available at the following site, "automated build
section", should include the changes:

  https://www.wireshark.org/download/automated/ 
<https://www.wireshark.org/download/automated/>

One thing to be noted is values of commands and return codes. Since I
had no idea what values should be used for them, I decided to keep the
values defined there, even though we can use separate code spaces for
command and return code now. Here is the list of the definitions:

  /* SIXTOP CMD and RC identifiers */
  #define IETF_6TOP_CMD_ADD  0x01
  #define IETF_6TOP_CMD_DELETE   0x02
  #define IETF_6TOP_CMD_STATUS   0x03
  #define IETF_6TOP_CMD_LIST 0x04
  #define IETF_6TOP_CMD_CLEAR0x05
  #define IETF_6TOP_RC_SUCCESS   0x06
  #define IETF_6TOP_RC_ERR_VER   0x07
  #define IETF_6TOP_RC_ERR_SFID  0x08
  #define IETF_6TOP_RC_ERR_GEN   0x09
  #define IETF_6TOP_RC_ERR_BUSY  0x0A
  #define IETF_6TOP_RC_ERR_NORES 0x0B
  #define IETF_6TOP_RC_ERR_RESET 0x0C
  #define IETF_6TOP_RC_ERR   0x0D

In addition to support draft-03, I made some enhancements on UI. For
example, a string of "6top" is shown in the protocol column for a 6P
frame instead of "IEEE 802.15.4" so that you can find 6P frames
easily. Please take a look at the attached screen image if you're
interested in how they look.

I hope you would like them, and I hope I interpreted the draft
correctly, especially bit-fields...

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch 
<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 <http://www.thomaswatteyne.com>
___


___
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

Re: [6tisch] [6P+SF0] CALL FOR CONSENSUS: sending a CLEAR request to old parents

[Yasuyuki Tanaka]

Hi all,

Here is my opinion:

step 1: one suggestion to keep the original sentence explaining what
to do in SF0 after the system booting-up or restart. That is,
no change on draft-ietf-6tisch-6top-sf0-02#section-10.

step 2: +1

Thanks!
Yatch

On 2016/11/22 8:16, Thomas Watteyne wrote:

In thread "Node Behavior at Boot in SF0" 
(https://www.ietf.org/mail-archive/web/6tisch/current/msg04883.html), we ended up 
discussing the following paragraph

https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10:

   In order to define a known state after the node is restarted, a CLEAR
   command is issued to each of the neighbor nodes to enable a new
   allocation process.  The 6P Initial Timeout Value provided by SF0
   should allow for the maximum number of TSCH link-layer retries, as
   defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
   REMARK: The initial timeout is currently under discussion.

The suggestion on the table is to:

step 1. Change 
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-10 to:

   The 6P Initial Timeout Value provided by SF0
   should allow for the maximum number of TSCH link-layer retries, as
   defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol].  TODO/
   REMARK: The initial timeout is currently under discussion.

step 2. Add the following text to draft-ietf-6tisch-6top-protocol, by possibly 
adding a 4.3.X section:

4.3.X. Disconnecting from a neighbor

   If the SF realizes connection to a particular neighbor is no longer
   needed (for example a change in parent by the routing protocol),
   the SF MAY send a CLEAR request to that neighbor to speed up the
   cleanup process of the cells allocated with that neighbor.

I'm hereby opening a call for WG consensus. Please +1 or comment/suggest. The 
chairs will summarize on Fridat 25 Nov.

Thomas

--
___

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 
___


___
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] Wireshark Dissector for draft-ietf-6tisch-6top-protocol-03

[Yasuyuki Tanaka]

Hi all,

A patch to support 6P of draft-03 has been merged into the master
branch of Wireshark with the short commit hash of 0f36cf6. This patch
updates the code based on draft-02 that was already there.

The latest packages available at the following site, "automated build
section", should include the changes:

  https://www.wireshark.org/download/automated/

One thing to be noted is values of commands and return codes. Since I
had no idea what values should be used for them, I decided to keep the
values defined there, even though we can use separate code spaces for
command and return code now. Here is the list of the definitions:

  /* SIXTOP CMD and RC identifiers */
  #define IETF_6TOP_CMD_ADD  0x01
  #define IETF_6TOP_CMD_DELETE   0x02
  #define IETF_6TOP_CMD_STATUS   0x03
  #define IETF_6TOP_CMD_LIST 0x04
  #define IETF_6TOP_CMD_CLEAR0x05
  #define IETF_6TOP_RC_SUCCESS   0x06
  #define IETF_6TOP_RC_ERR_VER   0x07
  #define IETF_6TOP_RC_ERR_SFID  0x08
  #define IETF_6TOP_RC_ERR_GEN   0x09
  #define IETF_6TOP_RC_ERR_BUSY  0x0A
  #define IETF_6TOP_RC_ERR_NORES 0x0B
  #define IETF_6TOP_RC_ERR_RESET 0x0C
  #define IETF_6TOP_RC_ERR   0x0D

In addition to support draft-03, I made some enhancements on UI. For
example, a string of "6top" is shown in the protocol column for a 6P
frame instead of "IEEE 802.15.4" so that you can find 6P frames
easily. Please take a look at the attached screen image if you're
interested in how they look.

I hope you would like them, and I hope I interpreted the draft
correctly, especially bit-fields...

Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Handling Inconsistent Allocation in 6P

[Yasuyuki Tanaka]

Xavi, Thomas, thank you for the responses!

I'm replying both of you in a single email to save bandwidth ;-)

Sorry for making this email so long... I put a shorter response first.

thomas> From an implementation point of view, cells that are in the
thomas> process of being reserved (i.e. 6P add request sent but no
thomas> response received yet) should be marked as "reserved" and only
thomas> committed to the schedule once the 6P transaction if over. I
thomas> believe this captures Nicola's idea, but turning it into a
thomas> recommendation for implementers, rather than a protocol
thomas> feature.

This idea covers the requester side in a 2-step transaction. From the
point of view of the respondent, it has no idea if its response
reaches the requester in time. Therefore, there is no chance for the
responder to decide whether to commit the operation or not after
success in sending the response. Of course, the generation counter
detects a inconsistency case where a response is out of time without
Nicola's idea (the generation counter of the respondent is ahead of
one of the requester).

xavi> it adds complexity and more messages over the air, which are
xavi> costly and can also fail (e.g external interference). What
xavi> happens if we loose the 6P NACK? How the NACK sender know that
xavi> the NACK has been received?

Thanks, they are good questions. I guess timeout would cause an error
like "unrecoverable inconsistency", then CLEAR could be sent.

xavi> What causes less overhead, 2 bits per each 6P command or 1 or 2
xavi> extra packets per transaction (assuming only write/state
xavi> modification transactions). For me the former is way simpler.

I agree with you, Xavi. The former is less overhead. Basically, less
message is better.

Let me explain my little concerns on the generation management at 6P:

  (1) it makes 6P aware of a series of transactions, at least the
  result of a previous transaction, which is already taken care of
  by a SF

  (2) it limits options to deal with inconsistency

The first item, (1), is what I felt something a bit strange with when
I was writing code for the GTX/GRX stuff. Until then, I thought the
role of 6P was abstracting a set of the 6top operations and getting
every single transaction done well; it didn't care about past
transactions (let's set aside SeqNum for now). And, in my thoughts, a
SF on 6P was in charge of a whole scheduling process to each neighbor
involving a series of transactions. This was a simple architectural
concept for me. Now, this is not the case because of the generation
counter at the 6P layer. I'm in favor of the simple concept, although
there may have been no such a concept in 6top as I thought...

The second one is more practical. While the draft says a post-action
after detecting inconsistency is up to a SF, the SF has no choice but
sending CLEAR because other command is not accepted, responded with
RC_ERR_GEN, under a generation inconsistency situation. This means,
one inconsistent transaction will ruin all the rest of scheduled cells
which are still valid. I feel that this is rooted in the first item I
mentioned; there are two entities managing consistency.

By the way, I may not understand fully how an inconsistency
occurs... Are there any inconsistency cases which timeout of either
side cannot detect, requester side or respondent side? In other words,
are there any inconsistency cases which 6P can detect but SFs cannot?
Answers to this question would help me understand why the generation
management at 6P is really necessary...

If the generation management was not necessary, I'd propose to remove
it and to add a rollback command to 6P in order to cancel the previous
operation in a separate transaction, operation to cancel which is
specified by SeqNum of the concerned operation in the rollback command
payload. A transaction with the rollback command is supposed to be
initiated when the previous transaction ends with timeout. This
proposal would make no changes on the current transaction patterns. It
would simplify 6P, which would not need to do for consistency
management nor generation management. There could be false positives
caused by inconsistency detection with timeout, but I assume they are
not big deal.

# In this sense, I prefer calling the value Transaction ID rather than
# SeqNum.

Thank you all for reading up to here...

Best,
Yatch

On 2016/11/22 8:23, Thomas Watteyne wrote:

I'd like to keep 6P simple, and just have a mechanism to detect inconsistencies. I 
believe roll-back to a previous schedule generation adds too much complexity. From an 
implementation point of view, cells that are in the process of being reserved (i.e. 6P 
add request sent but no response received yet) should be marked as "reserved" 
and only committed to the schedule once the 6P transaction if over. I believe this 
captures Nicola's idea, but turning it into a recommendation for implementers, rather 
than a protocol feature.

On Mon, Nov 21, 2016 

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Yasuyuki Tanaka]

Hi Thomas,


Could we say something to the effect that, if SF0 realizes
connection to a particular neighbor is no longer needed (for example
a change in parent by the routing protocol) SF0 MAY send CLEAR
requests to neighbor to speed up the cleanup process of the cells
with that neighbors?


I guess so. I would say it's a use-case description for CLEAR. To me,
it seems the 6P draft is a right place to add something as you
suggested. In that sense, "SF0" in the text above could be replaced
with "SF", anonymous one:

   If a SF realizes connection to a particular neighbor is no longer
   needed (for example a change in parent by the routing protocol),
   the SF MAY send CLEAR requests to the neighbor to speed up the
   cleanup process of the cells with that neighbors.

# Honestly, I'm not sure what "with that neighbors" suggested...

By the way, the API thing I mentioned is a hypothetical scenario; I
respect the "minimal" nature of SF0. :-)

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Yasuyuki Tanaka]

Hi Thomas,


Sending an explicit CLEAR will speed things up, and avoid for the
previous preferred parent to waste energy listening to those. A
CLEAR wouldn't hurt, right?


This is right. But, I don't think it's a SF0 job. The thing is that
SF0 knows nothing about RPL.

If SF0 provided an API to send CLEAR to a particular neighbor, RPL
could trigger the CLEAR request to a previous preferred parent on its
parent switch, I guess.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] macLinkType for the minimal configuration (draft-ietf-6tisch-minimal-16)

[Yasuyuki Tanaka]

Thank you for your comment, Pat!

I noticed your message wasn't on the ML; I paste it here.

On 2016/11/17 16:40, pat.kin...@kinneyconsultingllc.com wrote:


Yasuyuki brings up a very good point.  A major effort in creating
802.15.4-2015 was to eliminate (at least try to) ambiguities.  As
per the IEEE style guide: "The word may is used to indicate a course
of action permissible within the limits of the standard (may equals
is permitted to ).”  The LinkType wording was modified to clarify
when to use normal and when to use advertisement.  As per Yasuyuki
Table 8-46 does state that "Set to ADVERTISING if the link is to be
used to advertise the network, otherwise set to NORMAL.”  I should
note that the text in that sub-clause adds " If LinkType is set to
ADVERTISE, the links may be used to send Enhanced Beacon frames as
the result of the MAC receiving a MLME-BEACON.request.”  The intent
of 802.15.4-2015 was not meant to change the meaning of LinkType,
rather it was meant to clarify.

So, Yasuyuki’s question is indeed valid, should the minimal
configuration set the LinkType set to Advertising?

Pat

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
ISA100 co-chair, ISA100.20 chair
O: +1.847.960.3715
pat.kin...@kinneyconsultingllc.com


___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

[6tisch] macLinkType for the minimal configuration (draft-ietf-6tisch-minimal-16)

[Yasuyuki Tanaka]

Hi all,

I'm wondering if the cell scheduled for the minimal configuration
should be ADVERTISING in terms of macLinkType rather than NORMAL.

The definition of LinkType can be found in Table 8-46 of IEEE
802.15.4-2015. This is a table about MLME-SET-LINK.request
parameters. It says:

  Set to ADVERTISING if the link is to be used to advertise the
  network, otherwise set to NORMAL.

As we all know, the cell scheduled for the minimal configuration is
used for network advertisement; EBs are sent over the cell.

I did some research why NORNAL has been chosen for the cell, and found
the definition by IEEE 802.15.4e-2012 is a bit different to IEEE
802.15.4-2015. See Table 44f of IEEE 802.15.4e-2012, which is also a
table about MLME-SET-LINK.request parameters:

  Type of link. NORMAL = 0. ADVERTISING = 1, and indicates the link
  may be used to send an Enhanced beacon.

macLinkType has been introduced to the minimal configuration table
since draft-ietf-6tisch-minimal-01. Here is a relevant email found in
the ML archive, which was posted on June 8, 2014:

  https://mailarchive.ietf.org/arch/msg/6tisch/eF_eNIPw51UNwdv3P90qn1JMWqc


after friday discussion it seems that having:

1) variable size slotframes and the size being announced in the EBs
2) 1 active cell (slotted aloha) having linkOption set at RX,TX,SHARED
3) The linkType for that cell can be NORMAL and it is not required to be
ADVERTISMENT despite EBs will also be sent on that cell.

I would like to ask if everybody agrees on that approach and whether not
having a dedicated ADV cell but sending EBs in a NORMAL link is possible.


At that time, before IEEE 802.15.4-2015, it was fine to make the cell
NORMAL. I agree. But, is it still fine? Should we change the value of
macLinkType in Table 1 to ADVERTISING, or not?

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

[Yasuyuki Tanaka]

Hi Diego and Tengfei,

diego> I suggest to keep the CLEAR command after reboot/failure.

It's fine for me, too.

tengfei> I am thinking another case that a node needs send a CLEAR
tengfei> command to previous parent if it changed. I guess this is not
tengfei> mentioned in the draft?

No, it's not mentioned. Yet, I think, it's out of scope of SF0.

tengfei> [from the original mail]
tengfei> A little suggestion is DO NOT issue a clear command to
tengfei> previous parent until the nodes has reserved new cells to its
tengfei> new parent. This is to avoid the swing if the reservation
tengfei> failed to its new parent and changed back to previous parent.

A solution here "to avoid the swing" is to have enough
over-provisioned cells to prevent undesirable packet losses for
RPL. This can be done by setting SF0THRESH reasonably high.

And, I don't think a node switching its preferred parent needs to send
CLEAR to the previous one at any point. Unnecessary cells are supposed
to be deallocated automatically by SF0.

After changing its preferred parent at the RPL layer, the amount of
traffic or "the current number of used cell" to the previous one is
expected to decrease. Once Cell Estimation Algorithm notices the
decrement, unnecessary cells scheduled for the previous preferred
parent are deleted eventually.

In fact, SF0 cannot tell which neighbor is the previous preferred
parent, anyway.

Best,
Yatch


On 2016/11/16 16:16, Thomas Watteyne wrote:

That would be perfect, thanks!

On Thu, 17 Nov 2016 at 00:11 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl 
<mailto:diego.dujo...@mail.udp.cl>> wrote:

Thomas,
 It is not on my slides, since the default
behavior (issue a CLEAR command) did not
change from -01 to -02. I can raise the issue
during the presentation.
Regards,

Diego

2016-11-16 12:06 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr 
<mailto:thomas.watte...@inria.fr>>:

Diego,
Fine for me. Could you bring it up during the WG meeting tomorrow?
Thomas

On Thu, 17 Nov 2016 at 00:02 Prof. Diego Dujovne <diego.dujo...@mail.udp.cl 
<mailto:diego.dujo...@mail.udp.cl>> wrote:

Yasuyuki, Thomas,
 I suggest to keep the CLEAR command
after reboot/failure.
Regards,

   Diego

2016-11-16 11:05 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr 
<mailto:thomas.watte...@inria.fr>>:

@Tengfei,
Does that suggestion work for you or should we create an issue 
on SF0?
Thomas

On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka 
<yasuyuki9.tan...@toshiba.co.jp <mailto:yasuyuki9.tan...@toshiba.co.jp>> wrote:

Hi Tengfei,

I think an assumption there is that a node has no state 
with its
neighbors just after booting up or restarting. On the other 
hand, a
neighbor of them may have cells allocated for the node. To 
resolve
such a possible inconsistency, the node issues CLEAR to 
each of its
neighbors.

Best,
Yatch

On 2016/11/02 15:29, Tengfei Chang wrote:

All,

For the decision when a node is restarted, the SF0 says:

   In order to define a known state after the node is 
restarted, a CLEAR
   command is issued to each of the neighbor nodes to 
enable a new
   allocation process.  The 6P Initial Timeout Value 
provided by SF0
   should allow for the maximum number of TSCH 
link-layer retries, as
   defined by Section 4.3.4 of [I-D.ietf-6tisch-6top-protocol 
<https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#ref-I-D.ietf-6tisch-6top-protocol>].
  TODO/
   REMARK: The initial timeout is currently under 
discussion.


A little suggestion is DO NOT issue a clear command to 
previous parent until the nodes has reserved new cells to its new parent. This 
is to avoid the swing if the reservation failed to its new parent and changed 
back to previous parent.

What do you think?

Tengfei

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


___
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listin

Re: [6tisch] Node Address of Cell

[Yasuyuki Tanaka]

Hi Tero,
Thank you for the clear explanation!!

I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is
no distinction on a sending frame between unicast or broadcast.

Now I've got synchronized. :-)

Best,
Yatch

On 2016/11/16 4:05, Tero Kivinen wrote:

Yasuyuki Tanaka writes:

In this sense, the purpose of macNodeAddress is only to make something
like a priority cell for outgoing frames to a certain MAC address
other than the broadcast address. And, we cannot allocate a cell
exclusively used for sending broadcast frames. I wish IEEE
802.15.4-2015 could elaborate what is expected to do with
macNodeAddress... Everybody may have no confusion about these things
except me...


We had long discussion about that when 802.15.4-2015 revision was
being made, and we tried to clear things as much as possible, but as
people also had bit different things what 4e meant it was bit hard...


With regard to Link Options or Cell Options, I believe I have the same
understanding as Tero's. I'm relieved here. :-) But, I have one thing
I want to confirm about this.

If a cell is "shared", this means that there is a possibility of
contention or collision as you mentioned. This attribute, shared or
not, is orthogonal to which type of communication, unicast and/or
broadcast, to be done, isn't it?


Yes. The 802.15.4-2015 [1] CSMA-CA algorithms (section 6.2.5.1) state
machines Figure 6-5 and TSCH CSMA-CA retransmission algorithm (section
6.2.5.3) Figure 6-6 do not make difference whether the slot is
broadcast or not. It just have steps "Wait for next TX link to
destination" and that can be either broadcast link or link only for
it. The shared bit affects the next step which is "Dedicated Link?" /
"Shared slot?" questions.

[1] http://standards.ieee.org/getieee802/download/802.15.4-2015.pdf


Therefore, in theory, we may have a dedicated (non-shared) TX cell
whose macNodeAddress is the broadcast address.


Yes. I.e. you are the only one allowed to send to that link, but there
are multiple listeneres in there. So, as it does not have shared bit
on, there will not be other transmitters, but there can be multiple
listeners on it.


In this case, a node having such a TX cell is supposed to be the
unique sender in its neighborhood. We may also have a shared TX cell
whose macNodeAddress is a unicast address. In this case, more than
one pairs of devices could share such a cell for their
communication.


Yes.



___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Re: [6tisch] Node Address of Cell

[Yasuyuki Tanaka]

Hi Thomas and Tero,

Thank you for your responses! Yes, Tero's answered my question!!

To summarize:

[For TX]

- Any destination address is accepted in a cell if and only if its
  macNodeAddress is the broadcast address (or the short broadcast
  address).

- A unicast frame is sent over a cell whose macNodeAddress matches its
  destination address or is the broadcast address.

[For RX]

- macNodeAddress has nothing to do with RX.

- Any frame, regardless of the combination of its source and
  destination address, can be received through a cell.

In this sense, the purpose of macNodeAddress is only to make something
like a priority cell for outgoing frames to a certain MAC address
other than the broadcast address. And, we cannot allocate a cell
exclusively used for sending broadcast frames. I wish IEEE
802.15.4-2015 could elaborate what is expected to do with
macNodeAddress... Everybody may have no confusion about these things
except me...

With regard to Link Options or Cell Options, I believe I have the same
understanding as Tero's. I'm relieved here. :-) But, I have one thing
I want to confirm about this.

If a cell is "shared", this means that there is a possibility of
contention or collision as you mentioned. This attribute, shared or
not, is orthogonal to which type of communication, unicast and/or
broadcast, to be done, isn't it?

Therefore, in theory, we may have a dedicated (non-shared) TX cell
whose macNodeAddress is the broadcast address. In this case, a node
having such a TX cell is supposed to be the unique sender in its
neighborhood. We may also have a shared TX cell whose macNodeAddress
is a unicast address. In this case, more than one pairs of devices
could share such a cell for their communication.

How does that sound...?

Best,
Yatch

On 2016/11/15 5:06, Thomas Watteyne wrote:

Yatch,
Can you confirm Tero has answered your question?
Thomas

On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen <kivi...@iki.fi 
<mailto:kivi...@iki.fi>> wrote:

Yasuyuki Tanaka writes:
> To my understanding, the scheduled cell in 6tisch-minimal can be used
> for both of unicast and broadcast. The destination address of a frame
> to be sent with the cell may have the MAC address of a particular
> neighbor or the broadcast address.
>
> But I'm not sure how we can handle that use case with the MAC Layer
> defined by IEEE 802.15.4-2015.
>
> According to IEEE 802.15.4-2015, each scheduled cell has a node
> address associated with it, which is called "macNodeAddress" and
> listed as a TSCH MAC PIB attribute in Table 8-85. By definition, this
> is "(an) address of neighbor device connected to this link or the
> broadcast address."  It sounds like we cannot use a single cell for
> unicast and broadcast at the same time; more generally, a cell cannot
> be associated with more than one distinct MAC address. This also
> implies that a node has to know the address of a correspondent
> beforehand to receive frames from it.

In 802.15.4-2015 there is 3 bits that affect this. TxLink, RxLink and
SharedLink. SharedLink means that the link is used by multiple senders
at the same time, and senders need to use different retransmission
mechanims on the link, as there might be collisions. If the link is
not SharedLink, it is dedicated link, thus node can send to it without
caring about collsions. SharedLink only has real mening on the
TxLinks.

In addition to that the TxLink might either have one mac address
assigned to it, or it might be breadcast address. This affects whether
this node can be used to send to that node. I.e. if node is trying to
send node xxx, it can either wait for TxLink having macNodeAddress of
xxx, or it can wait TxLink having macNodeAddress of broadcast.

macNodeAddress does not really have any meaning for the RxLinks
(unless they also have TxLinks). There is nothing in the 802.15.4-2015
which says how macNodeAddress is for RxLinks (i.e., the section 6.7.2
does not have any filter rules based on that.

> I thought there might be a special MAC address for internal use which
> matches any address, like 0.0.0.0 or ::/0, and we could set the
> address to "macNodeAddress." However, I cannot find such an address...
>
> In practice, is the broadcast address used for "any" as well as for
> "broadcast"? Do you have any thoughts?

Yes, I think you can use broadcast for NodeAddress for RxLinks.
--
kivi...@iki.fi <mailto:kivi...@iki.fi>

___
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch 
<https://www.ietf.org/mailman/listinfo/6tisch>




--
___

Re: [6tisch] SF0 Cell Estimation Algorithm (draft-ietf-6tisch-6top-sf0-02)

[Yasuyuki Tanaka]

ic from the other nodes to the neighbours.
 I think the symmetry interpretation comes from
the idea that we are measuring the incoming cell requests from
a specific neighbour and then adding the outgoing number of cells
to the same neighbour and calculate the total amount of required cells.
But we still have to differentiate between TX and RX cells.
Hope this helps.
Let me know your thoughts about it.
Regards,

Diego Dujovne






2016-11-11 14:20 GMT-03:00 Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp 
<mailto:yasuyuki9.tan...@toshiba.co.jp>>:

Hi all,

I'd appreciate it if someone could help me understand SF0 Cell
Estimation Algorithm mentioned in draft-ietf-6tisch-6top-sf0-02...

https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5 
<https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5>

What I've read from the draft is that the Cell Estimation Algorithm
tries to have at least as many TX cells to a neighbor as RX cells
which has been allocated for the neighbor as requested. It seems the
algorithm assumes the communication triggering SF0 is symmetric.

This idea explains why REQUIREDCELLS is given "by adding the current
number of effectively used cells and the new incoming cells
requirement." In the draft, cells requested to the allocation policy
by the cell estimation algorithm are always TX. The numbers of
SCHEDULEDCELLS and REQUIREDCELLS are only about TX cells.

Is it correct? If this is the case, I wonder where the assumption,
communication with a neighbor is symmetric, comes from.

Supposing communication is asymmetric, where a node which has
allocated RX cells for a neighbor rarely sends data to it, TX cell
allocation triggered by an incoming cell requirement could not only be
in vain but also cause unnecessary 6P transactions. With this
scenario, it seems better that the estimation algorithm does not to
take into account "incoming cell requirements."  I may overlook
something...

I have another thing to ask, but I'd like to clarify the above first.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch 
<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 <http://www.ingenieria.udp.cl>
(56 2) 676 8125




--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
(56 2) 676 8125


___
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] SF0 Cell Estimation Algorithm (draft-ietf-6tisch-6top-sf0-02)

[Yasuyuki Tanaka]

Hi all,

I'd appreciate it if someone could help me understand SF0 Cell
Estimation Algorithm mentioned in draft-ietf-6tisch-6top-sf0-02...

https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5

What I've read from the draft is that the Cell Estimation Algorithm
tries to have at least as many TX cells to a neighbor as RX cells
which has been allocated for the neighbor as requested. It seems the
algorithm assumes the communication triggering SF0 is symmetric.

This idea explains why REQUIREDCELLS is given "by adding the current
number of effectively used cells and the new incoming cells
requirement." In the draft, cells requested to the allocation policy
by the cell estimation algorithm are always TX. The numbers of
SCHEDULEDCELLS and REQUIREDCELLS are only about TX cells.

Is it correct? If this is the case, I wonder where the assumption,
communication with a neighbor is symmetric, comes from.

Supposing communication is asymmetric, where a node which has
allocated RX cells for a neighbor rarely sends data to it, TX cell
allocation triggered by an incoming cell requirement could not only be
in vain but also cause unnecessary 6P transactions. With this
scenario, it seems better that the estimation algorithm does not to
take into account "incoming cell requirements."  I may overlook
something...

I have another thing to ask, but I'd like to clarify the above first.

Best,
Yatch

___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch