Reference Device Definition for the smallest possible platform for HTTP / TCP / JSON

[mlagally]

Use Case: Process a full TD without additional external components:

• Producer: Enable telemetry / control to other devices.
• Consumer: Extracting pieces of information from a single TD to control or read telemetry data from some other device.

These devices are simple consumers/producers that just are required to consume a SINGLE TD.
Define a minimum device which can run a TCP / HTTP stack + JSON and consume / expose TDs.

Working assumption: 256K/[512] KB RAM / 512 KB Flash
We can consider even 64K / 128K

This has been proven to be enough to produce TDs. (Implementation in C with various libs, MicroPython would be an alternative)

@mryuichi : What is the typical size of an ECHONET device?

---

Other categories / classes are defined elsewhere, but they appear to be too restricted for a WOT stack:

IETF constrained device classes from: https://datatracker.ietf.org/doc/rfc7228/

| Name | data size (e.g., RAM) | code size (e.g., Flash) |
+-------------+-----------------------+-------------------------+
| Class 0, C0 | << 10 KiB | << 100 KiB |
| | | |
| Class 1, C1 | ~ 10 KiB | ~ 100 KiB |
| | | |
| Class 2, C2 | ~ 50 KiB | ~ 250 KiB |

---

node.js requires >64MB up to 256MB

@danielpeintner What is the min size of a node-WoT device?

There are other device classes (gateways, directories) which are not in scope here.

[danielpeintner]

node.js requires >64MB up to 256MB

I don't think limited devices will use node.js ...

@danielpeintner What is the min size of a node-WoT device?

Mhh, very difficult question. I do not have a good frame for it.

What I would like to say is that I assume if plain JSON files cannot be processed people will use more efficient encoding formats which will make quite a difference...

[mlagally]

@danielpeintner
we make a baseline assumption of a TCP/IP stack, HTTP(S), processing of JSON to be available on the consuming (and exposing) device, so other encoding formats are out of scope of this reference device.

[mlagally]

Arch call on 11.2.

There are some low profile Javascript runtimes that are more compact.
e.g.:
https://jerryscript.net/ which claims to run in 64k RAM / 256 K Flash
A Python implementation would also be an option.

A C implementation of TLS for HTTPS fits into 32-64k
On an ESP 8266 there's 12k of RAM available for Javascript programs and variables.

https://www.esp8266.com/viewtopic.php?f=44&t=6574

Number of interactions:

Length of a URL: 256 bytes -> 4 URLs in 1 k
128?

Guesstimate: (max 2k for URLs):
Base URL: 128 bytes
Rel parts: 64 bytes
Strong recommendation: use relative URLs

TCP buffers:

1k / 1k send / receive

Payload size:

HTTP Request:

• Headers 256b
• JSON: 1-2k

HTTP Response:

• Header 256b
• JSON (Full TD)

Pagination of a TD can help to mitigate size constraints -> Discovery TF

Working model: Store entire TD in a buffer.

32 k fixed cost for these buffers.

32k limit of TD is reasonable for a 128k RAM device

What is the max size of TDs we used in the plugfests?
max was 37k, but that was only one TD. Almost all others were between 4-8k.
Taking 16k as the max enables to use devices with 64k RAM.

Proposal: 16k max TD , justification should be added into the Profile spec.

[sebastiankb]

So, the Smart Coffee Machine Thing with its 6xproperties, 2xactions, and 1xevent will not able support a TD following the profile since it needs 17k.

[danielpeintner]

Note1: In the smart-coffee-machine TD mentioned from Sebastian most of the text strings belong to hrefs:

• "http://plugfest.thingweb.io:8083/smart-coffee-machine/..."
• "coap://plugfest.thingweb.io:5683/smart-coffee-machine/..."
  A clever implementation might provide a base to at least reduce the size of one protocol.

Another big part are descriptions that might be stripped.

Note2: I still doubt that very limited devices use plain JSON, see some out-of-the box achievements one can achieve with more optimized encodings (see http://exificient.github.io/javascript/demo/processJSON.html). Taking into account that some terms are known ahead of time like all know n terms the improvements can be much higher!

[sebastiankb]

Sure, the TD can be optimized, but let's assume there will be only 2 more actions, most likely we will again break the limit. The point is that we have introduce cool features such as titles and descriptions to share detail information for, e.g., mutli language UIs. Such an use cases will be out of scope with such a limitation.

[sebastiankb]

Here is another example of a device description (from Vorto) that would never meet this constraint.

[sebastiankb]

So, the Smart Coffee Machine Thing with its 6xproperties, 2xactions, and 1xevent will not able support a TD following the profile since it needs 17k.

sorry, the 17k is wrong. Its 9k

[mlagally]

I have created an initial strawman proposal in:
#69
Please comment and create PRs against it.

[sebastiankb]

Regarding Vorto: I have received the information from @kolotu that there is no limit specified for Vorto models.

[sebastiankb]

Just for information, Eclipse Edit{TD}or provides some statistics of the TD such as number of properties, actions, and events, as well as the size in kB. Here is an example (check the footer).

[benfrancis]

I don't think defining a "Reference Device Definition for the smallest possible platform for HTTP / TCP / JSON" is possible. There are far too many variables. I propose closing.

[egekorkan]

I agree with the comment above. One thing we can do is document smallest profile conforming devices that someone has implemented. These wouldn't be references but would document this profile being possible in that kind of devices