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

From: Atis Elsts <[email-masked]>
Date: Tue, 11 Sep 2018 10:15:52 +0000

Dear all,

First, let me thank you for the hard work of standardizing 6TiSCH scheduling!

I tried partially implementing and evaluating the 6TiSCH MSF (https://tools.ietf.org/html/draft-chang-6tisch-msf-02) in Contiki-NG, on top of its existing 6top implementation. Some comments and questions follow.

1) I evaluated the suitability for data collection in residential environments. The topology was a simple star network, with 5 nodes generating packets, and the central node receiving. In the experiment, the generator nodes simultaneously transitioned from generating 0 pps to multiple packet per second. In this experiment, 6top was slow to build the schedule and the transactions frequently timed out. This happened because the packet queues were full of data packets, which had to be sent before the 6top packets got through. So, I suggest adding a requirement/recommendation for the implementer to prioritize 6top packets over data packets.

2) Section 5.1 says "In order to handle transient traffic bursts, MSF uses the [IEEE802154-2015] frame pending bit". In the experiment, disabling the burst bit significantly improved performance. Otherwise the packet bursts from one node interfered with the Autonomous Unicast Cells from other nodes. Once again, this is mostly due to the packet prioritization issue. However, it would be nice to avoid the "MUST" here, as well as to consider other options besides the burst bit. For example, allow to schedule contention-based cells.

3) It was difficult to come up with a good value for the adaptation period, which depends on MAX_NUMCELLS. Do you have some suggestions for the value of MAX_NUMCELLS?

4) A minor comment on Section 3: "the coordinates are computed to distribute the cells across all 16 channel offsets" - why restrict the number of channel offsets to 16? In IEEE 802.15.4, there can be more than 16 PHY-layer channels.  Also, the hopping sequence can be longer than the number of PHY-layer channels. Finally, many networks use less than 16 channels.

Best Wishes

Atis

Dr Atis Elsts
Research Associate
SPHERE (an EPSRC IRC)
University of Bristol
Department of Electrical and Electronic Engineering
Merchant Venturers Building / SPHERE Office
Woodland Road, Bristol, BS8 1UB, UK

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 11 Sep 2018 12:40:01 +0200

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

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 11 Sep 2018 12:45:19 +0200

Atis,
While I need to answer quickly (i.e. no real answer at this point), I want
stress that the feedback you're giving is hugely important and appreciated.
Yes, as in all standards, getting input from implementors on how to tune
parameters in the logical step as the standards themselves are being
finalized.
Don't hesitate to point the WG to the recommendations/tools/studies you
come up with.
Thomas

On Tue, Sep 11, 2018 at 12:40 PM Yasuyuki Tanaka <[email-masked]>
wrote:

> Hello Atis,
>
> > So, I suggest adding a requirement/recommendation for the implementer to
> prioritize 6top packets over data packets.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
________________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Analog Devices
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
________________________________________