[wot-architecture] minutes - 11 February 2021

available at:
  https://www.w3.org/2021/02/11-wot-arch-minutes.html

also as text below.

Thanks a lot for taking the minutes, Michael Koster!

Kazuyuki

---
   [1]W3C

      [1] https://www.w3.org/

                            WoT Architecture

11 February 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Feb._11th.2C_2021
      [3] https://www.w3.org/2021/02/11-wot-arch-irc

Attendees

   Present
          Christine_Perey, David_Ezell, Kaz_Ashimura,
          Michael_Koster, Michael_Lagally, Michael_McCool,
          Tomoaki_Mizushima

   Regrets
          -

   Chair
          Lagally

   Scribe
          mjk

Contents

    1. [4]agenda bashing
    2. [5]review minutes from February 4th call
    3. [6]PR 579
    4. [7]wot-profile issue #68

Meeting minutes

  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> [8]Feb-4

      [8] https://www.w3.org/2021/02/04-wot-arch-minutes.html

   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> [9]PR 579 - Define TD Fragment

      [9] https://github.com/w3c/wot-architecture/pull/579

   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> [10]wot-profile issue 68 - Reference Device Definition
   for the smallest possible platform for HTTP / TCP / JSON

     [10] https://github.com/w3c/wot-profile/issues/68

   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> [11]https://news.ycombinator.com/item?id=17995625

     [11] https://news.ycombinator.com/item?id=17995625

   <McCool> this is low.js

   <McCool> [12]https://jerryscript.net/

     [12] https://jerryscript.net/

   <McCool> there's also micropython

   McCool: ROM is cheap in terms of power consumption

   McCool: micropython might work

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

     [13] https://blog.arduino.cc/2020/07/02/arduino-security-primer/

   McCool: C++ could use arduino as an IDE

   <McCool> [14]https://
   www.wolfssl.com/?gclid=Cj0KCQiAyJOBBhDCARIsAJG2h5dTB7iAm0YRM3G2
   5Sf4Xf53tzHj9NKCSbYvQ-dIftJ2OOmlHCURnUAaAmbjEALw_wcB

     [14] 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> [15]https://github.com/w3c/wot-discovery/issues/117

     [15] 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, [16]EXI for JSON and [17]CBOR

     [16] https://www.w3.org/TR/exi-for-json/
     [17] https://tools.ietf.org/html/rfc7049

   [adjourn]


    Minutes manually created (not a transcript), formatted by
    [18]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [18] https://w3c.github.io/scribe2/scribedoc.html

Received on Monday, 8 March 2021 03:41:35 UTC