Subject: [6tisch] comments/questions regarding 6TiSCH architecture-03 draft

From: "Turner, Randy" <[email-masked]>
Date: Mon, 20 Oct 2014 20:12:09 +0000

Hi Guys,

Just some basic questions/comments regarding architecture-03:

Section 6.2 "To broadcast ICMPv6 control messages used by RPL such as DIO and DAO.."  - I thought DAOs were always unicast towards the root ?

Section 6.3  "A node that has joined the TSGI advertises a MAC level join priority set to its DAGRank() in that instance"  I think join priority is an 8-bit quantity,  DAGRank() I think is a 16-bit quantity - do we just mask with 0x00FF ?

Section 6.4 "In order to ensure that the medium  "if" free of contending packets when time..." s/if/is

Section 6.4 "..so as to optimize the chances of interferences from slotted-aloha operations" - should "optimize the chances" be "minimize the chance" ?

Section 6.4  "There is typically one slotFrame for scheduled traffic that has the highest precedence and one or more slotFrames for RPL traffic" -- Does this imply two levels of packet precedence? High and "Best Effort" ?  I'm assuming expedited forwarding (EF) marked packets would be assigned to the high-precedence slotFrame? Any suggestions here about how to map DSCP codepoints to SlotFrames ?

Section 6.5  s/fulfil/fulfill

Section 6.5 "The 6TiSCH architecture allows RPL parents to adjust dynamically, and independently from the PCE, the amount of bandwidth that is used to communicate between themselves and their children, in both directions"  ? So this means a PCE-schedule be overidden or modified as it is disseminated across the network ?

Section 6.5  "The chunks is the basic unit  of ownership..."  should probably start with "The chunk..."

Section 6.5 "The 6TiSCH architecture introduces the concept of chunks to operate such spectrum distribution for a whole group of cells at a time"  is a chunk a set of "contiguous" cells in the SlotFrame ?

Thanks!
Randy

P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 21 Oct 2014 12:26:51 +0000

Hello Randy:

Thanks for this review : )

Please see below.
Section 6.2 "To broadcast ICMPv6 control messages used by RPL such as DIO and DAO.."  - I thought DAOs were always unicast towards the root ?
[PT] That would be for RPL section 9.10. Multicast Destination Advertisement Messages

Section 6.3  "A node that has joined the TSGI advertises a MAC level join priority set to its DAGRank() in that instance"  I think join priority is an 8-bit quantity,  DAGRank() I think is a 16-bit quantity - do we just mask with 0x00FF ?
[PT] RPL defines
              DAGRank(rank) = floor(rank/MinHopRankIncrease)
  With a MinHopRankIncrease that is a multiple of 256, DagRank() fits in one octet. There was a catch about the size of the priority but it seems that we are fine using effectively all the 8 bits.

[PT] fixed :)

[PT] Maybe reduce?

Section 6.4  "There is typically one slotFrame for scheduled traffic that has the highest precedence and one or more slotFrames for RPL traffic" -- Does this imply two levels of packet precedence? High and "Best Effort" ?  I'm assuming expedited forwarding (EF) marked packets would be assigned to the high-precedence slotFrame? Any suggestions here about how to map DSCP codepoints to SlotFrames ?
[PT] That's http://tools.ietf.org/id/draft-svshah-tsvwg-deterministic-forwarding-00.txt see section 9.1. Packet Marking and Handling

[PT] fixed

[PT] The PCE would have precedence and the nodes could use the rest of the CDU matrix. What about adding

            Note that a PCE is expected to have precedence in the allocation,
            so that a RPL parent would only be able to obtain portions that are
            not in-use by the PCE.

[PT] fixed

[PT] No, it is an arbitrary bunch of cells, but if nodes have a single radio, then it makes little sense to have more than one cell at a given slotoffset....

Cheers,

Pascal
Thanks!
Randy

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 21 Oct 2014 06:29:35 -0700

+1 on Randy's comments and Pascal's proposed rewording

On Tuesday, October 21, 2014, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Section 6.2 "To broadcast ICMPv6 control messages used by RPL such as DIO
> and DAO.."  - I thought DAOs were always unicast towards the root ?
>
> *[PT] That would be for RPL section 9.10. Multicast Destination
> Advertisement Messages*
>
>
>
>
>
> Section 6.3  "A node that has joined the TSGI advertises a MAC level join
> priority set to its DAGRank() in that instance"  I think join priority is
> an 8-bit quantity,  DAGRank() I think is a 16-bit quantity - do we just
> mask with 0x00FF ?
>
> *[PT] RPL defines *
>
> *              DAGRank(rank) = floor(rank/MinHopRankIncrease)*
>
> *  With a MinHopRankIncrease that is a multiple of 256, DagRank() fits in
> one octet. There was a catch about the size of the priority but it seems
> that we are fine using effectively all the 8 bits.*
>
>
>
>
>
> *[PT] fixed **J*
> Section 6.4 "..so as to optimize the chances of interferences from
> slotted-aloha operations" - should "optimize the chances" be "minimize the
> chance" ?
>
> *[PT] Maybe reduce?*
>
>
>
> Section 6.4  "There is typically one slotFrame for scheduled traffic that
> has the highest precedence and one or more slotFrames for RPL traffic" --
> Does this imply two levels of packet precedence? High and "Best Effort" ?
> I'm assuming expedited forwarding (EF) marked packets would be assigned to
> the high-precedence slotFrame? Any suggestions here about how to map DSCP
> codepoints to SlotFrames ?
>
> *[PT] That’s
> http://tools.ietf.org/id/draft-svshah-tsvwg-deterministic-forwarding-00.txt
> <http://tools.ietf.org/id/draft-svshah-tsvwg-deterministic-forwarding-00.txt>
> see section 9.1. Packet Marking and Handling*
>
>
>
> *[PT] fixed*
> Section 6.5 "The 6TiSCH architecture allows RPL parents to adjust
> dynamically, and independently from the PCE, the amount of bandwidth that
> is used to communicate between themselves and their children, in both
> directions"  ? So this means a PCE-schedule be overidden or modified as it
> is disseminated across the network ?
>
>
>
> *[PT] The PCE would have precedence and the nodes could use the rest of
> the CDU matrix. What about adding*
>
>
>
> *            Note that a PCE is expected to have precedence in the
> allocation, *
>
> *            so that a RPL parent would only be able to obtain portions
> that are *
>
> *            not in-use by the PCE.*
>
>
>
> *[PT] fixed*
> Section 6.5 "The 6TiSCH architecture introduces the concept of chunks to
> operate such spectrum distribution for a whole group of cells at a time"
> is a chunk a set of "contiguous" cells in the SlotFrame ?
>
>
>
> *[PT] No, it is an arbitrary bunch of cells, but if nodes have a single
> radio, then it makes little sense to have more than one cell at a given
> slotoffset....*
>
>
>
> Cheers,
>
>
>
> Pascal
>
> Thanks!
> Randy
>
>
>
> *P*
>
> * PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL. **This
> e-mail (including any attachments) is confidential and may be legally
> privileged. If you are not an intended recipient or an authorized
> representative of an intended recipient, you are prohibited from using,
> copying or distributing the information in this e-mail or its attachments.
> If you have received this e-mail in error, please notify the sender
> immediately by return e-mail and delete all copies of this message and any
> attachments. Thank you. *
>

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 22 Oct 2014 19:09:41 +0000

Never mind...just saw -03 was published -

Apologies for the noise :)
R.

From: Turner, Randy
Sent: Wednesday, October 22, 2014 3:08 PM
To: 'Pascal Thubert (pthubert)'; [email-masked]
Subject: RE: comments/questions regarding 6TiSCH architecture-03 draft

Hi Pascal,

The draft you mentioned below (deterministic-forwarding-00) is expired - can you tell me the disposition of this work ?

Thanks!
Randy

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, October 21, 2014 8:27 AM
To: Turner, Randy; [email-masked]<mailto:[email-masked]>
Subject: RE: comments/questions regarding 6TiSCH architecture-03 draft

Hello Randy:

Please see below.

[PT] fixed

Cheers,

Pascal
Thanks!
Randy

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 22 Oct 2014 19:07:56 +0000

Hi Pascal,

Thanks!
Randy

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Tuesday, October 21, 2014 8:27 AM
To: Turner, Randy; [email-masked]
Subject: RE: comments/questions regarding 6TiSCH architecture-03 draft

Hello Randy:

Please see below.

[PT] fixed

Cheers,

Pascal
Thanks!
Randy

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 22 Oct 2014 19:39:44 +0000

We will continue, Randy.

The work progresses at TSVWG and will be presented at the DetNet BoF in Hawaii (on Monday 3PM).

Cheers,

Pascal

Le 22 oct. 2014 à 21:08, Turner, Randy <[email-masked]<mailto:[email-masked]>> a écrit :

Hi Pascal,

The draft you mentioned below (deterministic-forwarding-00) is expired – can you tell me the disposition of this work ?

Thanks!
Randy

Hello Randy:

Please see below.

Section 6.4  "There is typically one slotFrame for scheduled traffic that has the highest precedence and one or more slotFrames for RPL traffic" -- Does this imply two levels of packet precedence? High and "Best Effort" ?  I'm assuming expedited forwarding (EF) marked packets would be assigned to the high-precedence slotFrame? Any suggestions here about how to map DSCP codepoints to SlotFrames ?
[PT] That’s http://tools.ietf.org/id/draft-svshah-tsvwg-deterministic-forwarding-00.txt see section 9.1. Packet Marking and Handling

[PT] fixed

Cheers,

Pascal
Thanks!
Randy