WoT Architecture

agenda bashing

Lagally: proposes the agenda to continue discussion on the reference constrained device

Lagally: propose agenda item to discuss VF2F

review minutes from February 4th call

<kaz> Feb-4

Koster: 256K RAM seems good for the reference, 512K is available but 256 may be more of a sweet spot

Lagally: any other comments?

Lagally: minutes approved

PR 579

<kaz> PR 579 - Define TD Fragment

Lagally: are there any architecture topics for this call?

McCool: there is a suggestion for the current PR for the term "element"

McCool: we need to differentiate from "fragment" which has a special meaning in JSON usage

McCool: we can close and create a new issue for "element"

McCool: PR is #579

wot-profile issue #68

<kaz> wot-profile issue 68 - Reference Device Definition for the smallest possible platform for HTTP / TCP / JSON

McCool: we should think about the workload to determine the sizing

McCool: for example, development may have different needs from production deployment

McCool: we mostly experience the developer workflow

Lagally: we need practical experience

McCool: we could experimentally profile some application

McCool: to determine the bounds of memory use

Lagally: we need to determine lower bounds

McCool: minimum plus application needed memory

Koster: +1 on profiling, we could capture the minimum and an application delta

<McCool> jerryscript

McCool: we could profile node-wot assuming jerryscript

<McCool> https://news.ycombinator.com/item?id=17995625

<McCool> this is low.js

<McCool> https://jerryscript.net/

<McCool> there's also micropython

McCool: ROM is cheap in terms of power consumption

McCool: micropython might work

<McCool> https://blog.arduino.cc/2020/07/02/arduino-security-primer/

McCool: C++ could use arduino as an IDE

<McCool> https://www.wolfssl.com/?gclid=Cj0KCQiAyJOBBhDCARIsAJG2h5dTB7iAm0YRM3G25Sf4Xf53tzHj9NKCSbYvQ-dIftJ2OOmlHCURnUAaAmbjEALw_wcB

Koster: Arm TLS is the common implementation for embedded devices

<McCool> anyway, it seems BearSSL targets devides with 32KB

<McCool> so... 64K is probably "safe" for HTTPS

Kaz: in addition to memory footprint issue, there is a question about security certificates

McCool: we should look at CoAP and DTLS

Lagally: but we also need HTTP

<McCool> I think that HTTPS is an upper bound on CoAPS anyhow

<McCool> so if we can do HTTPS, the same device should be able to do CoAPS

McCool: the Arduino blog describes TLS in 32K

Lagally: does it need the Secure Element to reduce RAM usage?

McCool: unknown

<McCool> mm: but if we say 64K we should be fine even without hte secure element

Lagally: ESP8266 has 40K available for applications
… including communication buffers

McCool: length of URLs is probably the biggest factor in TD size

McCool: simple devices can use base URI to reduce size

McCool: After that, it's number of interactions

McCool: 256 maximum URL length seems big

McCool: maybe we should constrain the size of all URLs
… total URL storage size

McCool: maybe we need to store the entire TD in RAM

Lagally: a client will need to read a TD and extract what is needed

McCool: a device would need to store a set of forms to interact with the controlled device

McCool: sometimes a client will need to do bulk reads, which results in large buffers

Koster: largest response may be the full TD

McCool: pagination would limit the required buffer size

Lagally: let's assume two simple devices interacting with each other

Lagally: would a TD be bigger than 1-2KB?

McCool: we could fix the problem at the architecture level by enabling incremental consumption of TDs

Lagally: there will still be a minimum for transmitting and parsing

McCool: we need a standard way to paginate or incrementally evaluate TDs

<McCool> https://github.com/w3c/wot-discovery/issues/117

Koster: is it related to the signing and canonical TD work?

McCool: there are requirements like signature block size
… maybe small devices need to store TDs in canonical form

Lagally: what if we assume we don't have pagination for now
… with respect to design complexity and the time it would take
… maybe we can get 90% of the use cases through simpler mechanisms

Lagally: programming language may not be much of a factor in light of these data size limitation

McCool: proposing we could allow 32K for TD size in a 128K device
… based on HTTP server and other stack estimates

McCool: let's look at some TD sizes from the plugfest

McCool: looking at the TD repository from the last PF, 4K, 7K, 5K is common, with one 37K TD for a complex camera
… all using full URLs
… 32K may be tight in some cases

McCool: documentation could be moved to TMs that are references in the TD

Lagally: is there a base form for TDs?

Lagally: could we consider 16KB?

Lagally: we have a use case with multiple network addresses, for example proxies
… all consuming devices would be required to have this much buffer space
… could we achieve a 95% coverage

McCool: the memory size required may go up to 128K if we require 32K TD size

McCool: if we consider a constrained device category, 16K is OK

Kaz: maybe we need to consider compression like EXI for constrained TD

McCool: 16K as an upper bound may be OK and we could introduce compression later

McCool: maybe a light switch doesn't need to consume the camera TD

Lagally: let's summarize the notes

Lagally: let's consider this as a proposal
… maximum TD size is 16K

McCool: we should include the raw numbers and math to help explain our choice

Lagally: need to close now
… we have enough to go forward with a PR for a first draft on reference device sizes

Lagally: AOB?

<kaz> fyi, EXI for JSON and CBOR

[adjourn]