13:45:11 <RRSAgent> RRSAgent has joined #web-networks
13:45:11 <RRSAgent> logging to https://www.w3.org/2020/02/13-web-networks-irc
13:45:15 <Zakim> Zakim has joined #web-networks
13:45:37 <dom> Meeting: Web & Networks IG: EDGE Applications: Supporting an Ambient Computing Ecosystem
13:45:55 <dom> Agenda: https://lists.w3.org/Archives/Public/public-networks-ig/2020Feb/0001.html
13:46:24 <dom> -> https://lists.w3.org/Archives/Public/public-networks-ig/2020Feb/att-0002/EdgeApps_Feb13_W3C_V2.pdf Slides
13:58:12 <cpn> cpn has joined #web-networks
13:59:16 <dom> Present+ Dom, MichaelMcCool, ChrisNeedham, DanDruta, Sudeep
14:00:46 <kaz> kaz has joined #web-networks
14:00:58 <dom> Present+ Huaqi
14:01:00 <dom> Present+ Kaz
14:01:04 <sudeep> sudeep has joined #web-networks
14:01:05 <McCool> McCool has joined #web-networks
14:01:18 <dom> Present+ Theoharid_Charitidis
14:01:30 <dom> Present+ Kenton_Varda
14:01:37 <dom> Present+ Song
14:02:15 <dom> Present+ JonDevlin
14:02:27 <dom> Present+ DarioSabella
14:04:06 <dom> Chair: Song, Sudeep, Dan
14:04:12 <dom> ScribeNick: dom
14:04:29 <dom> Song: Michael McCool from Intel will be presenting on the Edge Computing workstream
14:04:36 <dom> ... co-chair of the Web of Things Working Group
14:05:19 <dom> MMC: I've been co-chairing WoT for the past two years - Web of Things relates to Edge Computing as I will be discussing
14:05:30 <sudeep> sudeep has left #web-networks
14:05:34 <dom> ... What I will be presenting has emerged in the context of edge computing but in other contexts as well
14:06:11 <dom> ... I'll present an overall strategy to approach edge computing, some use cases and motivations, and finally the technical approaches to accomplish
14:06:27 <dom> ... I'm targeted 2 broad categories of use cases: IoT orchtestration and computing offload
14:06:49 <dom> ... When you look at Edge computing in general, there are 2 broad approaches: bring cloud computing closer to the device to the edge
14:07:04 <dom> ... or take things running from the end device and push it up to the edge
14:07:17 <dom> ... the first approach is based on devops / container deployment
14:07:23 <sudeep> sudeep has joined #web-networks
14:07:29 <dom> ... the 2nd approach takes a client environment and pushes it to the edge
14:07:51 <dom> ... this would be typically done as a function as a service - this requires specifying more of the execution environment
14:08:08 <dom> ... Another difference is that the cloud approach the computing is specified by the provider
14:08:19 <dom> ... whereas in the 2nd approach, this is being driven by the client
14:08:25 <dom> ... the two approaches are complementary
14:08:45 <dom> ... the cloud environment among other things is necessary for the function-as-a-service approach needed for clients
14:09:06 <dom> ... I will be focusing on the latter approach, driven by client execution which is more in line with overall w3c efforts
14:09:43 <dom> ... 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
14:09:55 <dom> ... esp in the context of PWA, these Web apps feel very much like a real app
14:10:30 <dom> ... 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
14:10:44 <dom> ... this could also apply in a more structured context in the case of BYOD
14:11:07 <dom> ... We have been working with Connexys on this approach
14:11:41 <dom> ... Another angle is with smart cities: smart cities have plenty of vendors, and may apps and services require exploiting solutions from multiple vendors
14:12:11 <dom> ... 3d party developers for smart city need standards for an open ecosystem to emerge
14:12:24 <dom> ... These are the use cases I'm thinking of for user driven applications
14:12:54 <dom> ... I have two set of goals: primary goals are client-managed services which I call "edge workers" for compute as utility
14:13:11 <dom> ... it's a standardized service provided by multiple vendors, and clients can instantiate work in that service
14:13:33 <dom> ... this could be for offloading compute (e.g. to get acceleration speedup - at least 10X I think for it to be worth it)
14:13:34 <Peipei_Guo> Peipei_Guo has joined #web-networks
14:13:50 <dom> Present+ Larry_Zhao
14:14:00 <dom> Present+ JonasSvennebring
14:14:08 <dom> Present+ Taki_Kamiya
14:14:22 <dom> MMC: Another application is IoT orchestration
14:14:40 <dom> ... Second goals include security, privacy, 3rd party ecosystem
14:15:12 <dom> ... We would like to extend the app development model - this requires to minimize the amount of work needed to make use of that feature
14:15:42 <dom> ... an optional but very useful aspect would be to integrate discoverability of "near-by" computing utility services
14:15:58 <dom> ... discovery might include local LAN search, DNS, etc
14:16:07 <dom> ... discovery is technical orthogonal but quite useful to have
14:16:36 <dom> ... A bit more details on the definition of these goals - compute offload and IoT orchestration
14:17:13 <dom> ... 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
14:17:42 <dom> ... the offloading would typically go to a node with lots more capacity
14:17:55 <dom> ... ideally, this would work transparently onboard / off-board
14:18:14 <dom> ... e.g. a laptop moving compute to an on-board high-perf GPU
14:18:33 <dom> ... IoT orchestration is about orchestrating several devices available on the network
14:18:52 <dom> ... this requires managing privacy, possibly protocol translation (which WoT has been looking at closely)
14:19:07 <dom> ... when you're providing an IoT orchestration service, it has to be persistent, to live in the network
14:19:18 <dom> ... independently of the availability of the end-user device / UI
14:19:28 <dom> ... that service would reasonably be event driven
14:19:57 <dom> ... General requirements include privacy, security, discovery
14:20:09 <dom> ... we also need a number of management functions (install / pay, etc)
14:20:30 <dom> ... There are various proposals that just do computing offload, some that just do IoT orchestration
14:20:43 <dom> ... taking the 2 together is much better
14:22:21 <dom> Present+ Peipei_Guo
14:23:20 <dom> 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?
14:23:28 <zkis_> present+ Zoltan_Kis
14:23:44 <dom> ... Web Workers is already a model to offload computing and has already been experimented to use as off-device offloading
14:24:06 <dom> ... but we're interested in persistent and event-driven computing, for which Service Worker is a better model
14:24:24 <dom> ... we could re-use the idea of "installing a PWA" to handle some of the management functions
14:24:47 <dom> ... how would you package computation in this context? WASM would be a good candidate
14:25:02 <dom> ... scripts are OK when they don't come in the way of the computing performance
14:25:33 <dom> ... The Web of Things Group is working on relevant technologies: we have existing work to describe devices, "Things"
14:25:43 <kaz> -> https://www.w3.org/2020/01/wot-wg-charter.html new WoT WG Charter
14:25:54 <dom> ... discovery (part of our new charter) will enable to find these descriptions and devices
14:26:30 <dom> ... 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
14:26:50 <dom> ... an "Edge Worker" would be a combination of capaibilites from Web Workers and Service Workers
14:27:07 <dom> ... but we would need a management API on how to install and manage workers on computing utility
14:27:26 <dom> ... it wouldn't be a huge API, but there would need to be an exposed Web service for the utility
14:27:40 <dom> ... this would be a container with an exposed service to install such a worker
14:28:00 <dom> ... Looking at discovery, one challenge is maintaining privacy; another is local vs global
14:28:27 <dom> ... the basic mechanism is to have a directory where devices and services get registered
14:28:45 <dom> ... we don't want to broadcast metadata as that would invade privacy
14:29:01 <dom> ... only authenticated requests should get access to rich metadata
14:29:23 <dom> ... the first contact protocol can use a number of existing mechanisms (DNS, bluetooth beacons, QR codes, ...)
14:29:37 <dom> ... Focusing back on Edge Worker, let's first review what a Web Worker is
14:29:59 <dom> ... A Web Worker is typically used to move computing-intense work in a separate thread
14:30:10 <dom> ... A Web Worker is offloading, but inside a Web browser
14:30:28 <dom> ... although there have been implementations that offload to somewhere else on the network transparently
14:31:22 <dom> ... 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
14:31:43 <dom> ... These workers need to have access to accelerated computing
14:32:13 <dom> ... IoT Orchestration looks very similar; an orchestration API access other devices on the network
14:32:38 <dom> ... The Edge Worker would access devices with proper permissions obtained during the installation process
14:33:04 <dom> ... you would install this as a persistent service à la PWA - deleting the PWA would remove the worker
14:33:31 <dom> ... Doing the two together (offload and orchestration) would work fine; it might benefit from additional APIs (e.g. storage management)
14:34:03 <dom> ... other services could be running and provided similarly as Things in the directory
14:34:28 <dom> ... there could be multiple Edge Workers running
14:34:41 <dom> ... What standards would be needed to get there?
14:34:55 <dom> ... A management API to instantiate workers
14:35:16 <dom> ... something to package a worker - we already have the worker concept, but may need to look at container
14:35:33 <dom> ... APIs for compute acceleration that would need to be available in edge workers
14:36:01 <dom> ... optionally, support for discovery of services which would open a much more open ecosystem
14:36:28 <dom> Present+ Zoltan_Kis
14:36:47 <dom> Song: Thank you Michael for the presentation
14:37:15 <zkis_> q?
14:38:25 <dom> Dom: re top/down vs bottom/up computing offloading - what's the market situation for bottom/up?
14:38:48 <dom> MMC: function-as-a-services from AWS, cloudflare's workers are related
14:39:03 <dom> ... re pushing for this, this is a matter of opening up applications
14:39:34 <dom> ... we will have to build this based on demand; one question is how this would be monetized
14:39:49 <dom> ... there are various ways this could be charged for - e.g. via your ISP
14:40:07 <dom> ... Bell in Canada has a similar subscription service for home security
14:40:26 <zkis_> q+
14:40:50 <dom> Song: when you're talking about discovery - does it exist yet?
14:40:59 <dom> MMC: there are already lots of discovery protocols outthere
14:41:11 <dom> ... but they're not necessarily very privacy sensitive, e.g. ZeroConf
14:41:17 <dom> ... because they're based on serviceworker
14:41:32 <dom> ... also with a search-based approach, you open up risks for DoS
14:41:47 <dom> ... the directory service is here to help with these issues
14:42:06 <dom> ... there are probably dozens of different ways for the initial contact, intro with the directory service
14:42:20 <dom> ... the directory service doesn't say anything about what devices they store
14:42:45 <dom> ... you would authenticate to the directory service before you can do content-based searches on the metadata
14:43:27 <dom> Song: is discovery optional for standardization? for implementation?
14:43:50 <dom> MMC: you can have compute utility without discovery strictly speaking - e.g. it could be hardcoded one way or another
14:44:20 <dom> Dario: this is complementary to what is already defined in ETSI MEC
14:44:39 <dom> ... an API that enables to instantiate an app on the edge cloud
14:45:07 <dom> MMC: my point was that discovery is orthogonal to compute utilities, but they work better together
14:45:14 <dom> q+
14:45:38 <dom> ... there are also existing standards for directories
14:46:00 <dom> ... another question is what data needs to be standardized in these directories and the search protocol
14:46:21 <dom> ack zkis
14:47:29 <taki> taki has joined #web-networks
14:48:11 <dom> 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)
14:48:23 <dom> MMC: this would be part of the discovery / search
14:48:48 <dom> ... we've looked at template-based search in WoT that should help
14:49:10 <dom> ... you would need some kind of accountability mechanism
14:50:30 <dom> ... in terms of "is it worth it" - is it worth for the end user (enough speed up)? is it worth for the developer?
14:50:51 <dom> Zoltan: can you explain what you mean by edge? "current" edge, or next generation?
14:51:19 <dom> ... what info would be needed to pick an edge (QoS, computing capabilities)
14:51:33 <dom> MMC: what I have in mind can work with current hardware / capabilities
14:51:52 <dom> ... the edge could extend to the cloud depending on the circumstances
14:52:05 <dom> ... basically, we need a container that can be managed via an API
14:52:43 <dom> Zoltan: how would it take advantage of network information (e.g. low-latency, cost, ...)?
14:52:54 <dom> MMC: I know there has been other discussions on QoS
14:53:15 <dom> ... the discovery service knows about capabilities - but the network is special, it depends on the various links between the components
14:53:32 <dom> ... the edge worker itself might need to know the quality of connection
14:53:54 <dom> ... this raises a question of enabling an edge worker to migrate from one node to another one (e.g. to get better connectivity)
14:54:39 <dom> ... if higher quality is for pay, the search process might include some level of quality definition
14:58:03 <dom> 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?
14:58:19 <dom> MMC: I think we're ok wrt discovery, accelerated computing
14:58:42 <dom> ... I would like to experiment with a management API to instantiate a Web worker and then experiment with the browser side of things
14:59:09 <dom> ... I'm targeting to develop a proof of concepts in the course of the year, but would like more discussion on requirements
14:59:27 <dom> ... this is a longer term plan
14:59:30 <kaz> q+
14:59:32 <dom> q-
15:00:18 <dom> ack kaz
15:00:37 <dom> Dom: a Proof of concepts would help get momentum, maybe before starting a CG
15:01:13 <dom> Kaz: the Web & Networks IG could provide input on use cases for edge computing discovery
15:02:20 <dom> Sudeep: next call will be in March talking about 5GAA and network prediction
15:02:27 <dom> ... the date hasn't been finalized yet
15:02:57 <McCool> McCool has left #web-networks
15:03:17 <dom> RRSAgent, draft minutes v2
15:03:17 <RRSAgent> I have made the request to generate https://www.w3.org/2020/02/13-web-networks-minutes.html dom
15:21:56 <zkis__> zkis__ has joined #web-networks
15:48:16 <dom> RRSAgent, make log public
17:16:40 <Zakim> Zakim has left #web-networks
17:56:10 <taki1> taki1 has joined #web-networks
19:00:44 <zkis__> zkis__ has joined #web-networks
19:41:17 <zkis__> zkis__ has joined #web-networks