[minutes] Feb 13 teleconf: EDGE Applications: Supporting an Ambient Computing Ecosystem

Hi,

The minutes of our call today are available at:
  https://www.w3.org/2020/02/13-web-networks-minutes.html
linked from
  https://www.w3.org/wiki/Networks#Meetings
and copied as text below.

Dom

 Web & Networks IG: EDGE Applications: Supporting an Ambient Computing
                               Ecosystem

13 February 2020

   [2]Agenda. [3]IRC log.

      [2]
https://lists.w3.org/Archives/Public/public-networks-ig/2020Feb/0001.html
      [3] https://www.w3.org/2020/02/13-web-networks-irc

Attendees

   Present
          ChrisNeedham, DanDruta, DarioSabella, Dom, Huaqi,
          JonasSvennebring, JonDevlin, Kaz, Kenton_Varda,
          Larry_Zhao, MichaelMcCool, Peipei_Guo, Song, Sudeep,
          Taki_Kamiya, Theoharid_Charitidis, Zoltan_Kis

   Regrets
          -

   Chair
          Dan, Song, Sudeep

   Scribe
          dom

Contents

     * [4]Meeting minutes

Meeting minutes

   [5]Slides

      [5]
https://lists.w3.org/Archives/Public/public-networks-ig/2020Feb/att-0002/EdgeApps_Feb13_W3C_V2.pdf

   Song: Michael McCool from Intel will be presenting on the Edge
   Computing workstream
   … co-chair of the Web of Things Working Group

   MMC: I've been co-chairing WoT for the past two years - Web of
   Things relates to Edge Computing as I will be discussing
   … What I will be presenting has emerged in the context of edge
   computing but in other contexts as well
   … I'll present an overall strategy to approach edge computing,
   some use cases and motivations, and finally the technical
   approaches to accomplish
   … I'm targeted 2 broad categories of use cases: IoT
   orchtestration and computing offload
   … When you look at Edge computing in general, there are 2 broad
   approaches: bring cloud computing closer to the device to the
   edge
   … or take things running from the end device and push it up to
   the edge
   … the first approach is based on devops / container deployment
   … the 2nd approach takes a client environment and pushes it to
   the edge
   … this would be typically done as a function as a service -
   this requires specifying more of the execution environment
   … Another difference is that the cloud approach the computing
   is specified by the provider
   … whereas in the 2nd approach, this is being driven by the
   client
   … the two approaches are complementary
   … the cloud environment among other things is necessary for the
   function-as-a-service approach needed for clients
   … I will be focusing on the latter approach, driven by client
   execution which is more in line with overall w3c efforts
   … In a user-driven approach, I'm looking at an open ecosystem
   similar to the current open web platform where a user can run
   an app by simply following a link
   … esp in the context of PWA, these Web apps feel very much like
   a real app
   … To illustrate whta I have in mind, you could imagine a small
   retail owner wanting to install a security service on their
   local hardware - they could do that without IT support by
   installing a Web app
   … this could also apply in a more structured context in the
   case of BYOD
   … We have been working with Connexys on this approach
   … Another angle is with smart cities: smart cities have plenty
   of vendors, and may apps and services require exploiting
   solutions from multiple vendors
   … 3d party developers for smart city need standards for an open
   ecosystem to emerge
   … These are the use cases I'm thinking of for user driven
   applications
   … I have two set of goals: primary goals are client-managed
   services which I call "edge workers" for compute as utility
   … it's a standardized service provided by multiple vendors, and
   clients can instantiate work in that service
   … this could be for offloading compute (e.g. to get
   acceleration speedup - at least 10X I think for it to be worth
   it)

   MMC: Another application is IoT orchestration
   … Second goals include security, privacy, 3rd party ecosystem
   … We would like to extend the app development model - this
   requires to minimize the amount of work needed to make use of
   that feature
   … an optional but very useful aspect would be to integrate
   discoverability of "near-by" computing utility services
   … discovery might include local LAN search, DNS, etc
   … discovery is technical orthogonal but quite useful to have
   … A bit more details on the definition of these goals - compute
   offload and IoT orchestration
   … for compute offload typically is useful for devices with
   limited computing or power (e.g. mobile devices, small IoT) or
   with significant less power than available on the edge
   … the offloading would typically go to a node with lots more
   capacity
   … ideally, this would work transparently onboard / off-board
   … e.g. a laptop moving compute to an on-board high-perf GPU
   … IoT orchestration is about orchestrating several devices
   available on the network
   … this requires managing privacy, possibly protocol translation
   (which WoT has been looking at closely)
   … when you're providing an IoT orchestration service, it has to
   be persistent, to live in the network
   … independently of the availability of the end-user device / UI
   … that service would reasonably be event driven
   … General requirements include privacy, security, discovery
   … we also need a number of management functions (install / pay,
   etc)
   … There are various proposals that just do computing offload,
   some that just do IoT orchestration
   … taking the 2 together is much better

   MMC: so assuming we want to achieve these goals, how can we go
   from existing Web standards and increment them to handle our
   use cases?
   … Web Workers is already a model to offload computing and has
   already been experimented to use as off-device offloading
   … but we're interested in persistent and event-driven
   computing, for which Service Worker is a better model
   … we could re-use the idea of "installing a PWA" to handle some
   of the management functions
   … how would you package computation in this context? WASM would
   be a good candidate
   … scripts are OK when they don't come in the way of the
   computing performance
   … The Web of Things Group is working on relevant technologies:
   we have existing work to describe devices, "Things"

   <kaz> [6]new WoT WG Charter

      [6] https://www.w3.org/2020/01/wot-wg-charter.html

   MMC: discovery (part of our new charter) will enable to find
   these descriptions and devices
   … If the offload worker is based on script, we also have a
   (non-normative so far) scripting API to abstract the interface
   to IoT devices
   … an "Edge Worker" would be a combination of capaibilites from
   Web Workers and Service Workers
   … but we would need a management API on how to install and
   manage workers on computing utility
   … it wouldn't be a huge API, but there would need to be an
   exposed Web service for the utility
   … this would be a container with an exposed service to install
   such a worker
   … Looking at discovery, one challenge is maintaining privacy;
   another is local vs global
   … the basic mechanism is to have a directory where devices and
   services get registered
   … we don't want to broadcast metadata as that would invade
   privacy
   … only authenticated requests should get access to rich
   metadata
   … the first contact protocol can use a number of existing
   mechanisms (DNS, bluetooth beacons, QR codes, ...)
   … Focusing back on Edge Worker, let's first review what a Web
   Worker is
   … A Web Worker is typically used to move computing-intense work
   in a separate thread
   … A Web Worker is offloading, but inside a Web browser
   … although there have been implementations that offload to
   somewhere else on the network transparently
   … So to offload to an edge worker, you would discover the
   availability of computing utilities, find the appropriate one,
   and offload the work to the edge worker
   … These workers need to have access to accelerated computing
   … IoT Orchestration looks very similar; an orchestration API
   access other devices on the network
   … The Edge Worker would access devices with proper permissions
   obtained during the installation process
   … you would install this as a persistent service à la PWA -
   deleting the PWA would remove the worker
   … Doing the two together (offload and orchestration) would work
   fine; it might benefit from additional APIs (e.g. storage
   management)
   … other services could be running and provided similarly as
   Things in the directory
   … there could be multiple Edge Workers running
   … What standards would be needed to get there?
   … A management API to instantiate workers
   … something to package a worker - we already have the worker
   concept, but may need to look at container
   … APIs for compute acceleration that would need to be available
   in edge workers
   … optionally, support for discovery of services which would
   open a much more open ecosystem

   Song: Thank you Michael for the presentation

   Dom: re top/down vs bottom/up computing offloading - what's the
   market situation for bottom/up?

   MMC: function-as-a-services from AWS, cloudflare's workers are
   related
   … re pushing for this, this is a matter of opening up
   applications
   … we will have to build this based on demand; one question is
   how this would be monetized
   … there are various ways this could be charged for - e.g. via
   your ISP
   … Bell in Canada has a similar subscription service for home
   security

   Song: when you're talking about discovery - does it exist yet?

   MMC: there are already lots of discovery protocols outthere
   … but they're not necessarily very privacy sensitive, e.g.
   ZeroConf
   … because they're based on serviceworker
   … also with a search-based approach, you open up risks for DoS
   … the directory service is here to help with these issues
   … there are probably dozens of different ways for the initial
   contact, intro with the directory service
   … the directory service doesn't say anything about what devices
   they store
   … you would authenticate to the directory service before you
   can do content-based searches on the metadata

   Song: is discovery optional for standardization? for
   implementation?

   MMC: you can have compute utility without discovery strictly
   speaking - e.g. it could be hardcoded one way or another

   Dario: this is complementary to what is already defined in ETSI
   MEC
   … an API that enables to instantiate an app on the edge cloud

   MMC: my point was that discovery is orthogonal to compute
   utilities, but they work better together
   … there are also existing standards for directories
   … another question is what data needs to be standardized in
   these directories and the search protocol

   dom: before you would decide to offload, you need to understand
   what kind of computing capabilities you'll get, as well as
   understand the impact for the network (time, power)

   MMC: this would be part of the discovery / search
   … we've looked at template-based search in WoT that should help
   … you would need some kind of accountability mechanism
   … in terms of "is it worth it" - is it worth for the end user
   (enough speed up)? is it worth for the developer?

   Zoltan: can you explain what you mean by edge? "current" edge,
   or next generation?
   … what info would be needed to pick an edge (QoS, computing
   capabilities)

   MMC: what I have in mind can work with current hardware /
   capabilities
   … the edge could extend to the cloud depending on the
   circumstances
   … basically, we need a container that can be managed via an API

   Zoltan: how would it take advantage of network information
   (e.g. low-latency, cost, ...)?

   MMC: I know there has been other discussions on QoS
   … the discovery service knows about capabilities - but the
   network is special, it depends on the various links between the
   components
   … the edge worker itself might need to know the quality of
   connection
   … this raises a question of enabling an edge worker to migrate
   from one node to another one (e.g. to get better connectivity)
   … if higher quality is for pay, the search process might
   include some level of quality definition

   Dom: how would you think the work on this would happen?
   discovery is part of WoT charter, but how would the work happen
   on Edge Worker?

   MMC: I think we're ok wrt discovery, accelerated computing
   … I would like to experiment with a management API to
   instantiate a Web worker and then experiment with the browser
   side of things
   … I'm targeting to develop a proof of concepts in the course of
   the year, but would like more discussion on requirements
   … this is a longer term plan

   Dom: a Proof of concepts would help get momentum, maybe before
   starting a CG

   Kaz: the Web & Networks IG could provide input on use cases for
   edge computing discovery

   Sudeep: next call will be in March talking about 5GAA and
   network prediction
   … the date hasn't been finalized yet

Received on Thursday, 13 February 2020 15:56:54 UTC