Meeting minutes
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> new WoT WG Charter
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