Meeting minutes
Presnt+ YakunHuang, DanDruta, EricSiow, MattWilson, TomoakiMizushima
Song: I'm song from China Mobile; Sudeep, Dan and myself are co-chairs of the Web & Networks IG
… this is the breakout session on edge computing for the Web
… we'll have presentations from Max from Alibaba and Michael from Intel
Introduction
Song: the goal for this sessions is to identify opportunities for Web APIs needed for edge computing
… capitalize on latest network capabilities
… we'll get first a presentation from Max on use cases and requirements
… and Michael will focus on usnig WASM on the edge
Edge Computing Use cases and requirements
Max: I'm Max Liu from Alibaba Group
<McCool> correction, michael not focusing on WASM, focusing on extension of Worker mechanism
Max: glad to join this TPAC meeting virtually to discuss edge and cloud requirements and solutions
… the Web & Networks IG has had discussions on this
… I joined the IG bringing use cases and possible solutions
… which I want to share today
… I've submitted a draft
Client-Edge-Cloud coordination Use Cases and Requirements
Use cases
Max: first use cases is a cloud application - based on a product in Alibaba Tmall Genie
… normally, the computing gets run on the end device
… but in our architecture, we offload most of the computing to edge and central clouds
… central cloud is focused on resource management & dispatch
… while the edge focuses on device management and the actual computing
… the end device is connected to both edge and central clouds
… it's only used to display the results from the edge
… Last week, we launched a very similar system in our cloud event last week, with a focus on an enterprise scenario
… other companies have similar solutions moving computing to edge and central cloud
… Different vendors have similar architectures; having a standardized architecture would help the interoperability for application and device vendors, and cloud computing platform service providers
… the whole ecosystem will benefit
… Another use case often discussed is around AR & VR
… with 5G, it's possible to offload intensive computing off the end devices
… 3rd use case is around machine learning
… ML can run on the cloud; there is also ongoing work to put ML on the device
… but still, in some very important use cases with very intensive tasks, it would be best to run it on the cloud
… with a flexible enough architecture, there can be offload between client and cloud, bringing new use cases and solving new problems
… 4th use case is for high available applications: if there is one app running on the client side
… but the client runs out of resources, the client could offload to a first cloud provider
… and if needed, switch to another provider
… or would use the second one as a backup
… and likewise with a 3rd
… the goal being to have the code run smoothly across the various nodes
… to bring very high availability
Requirements
Max: from these use cases, a few general and simple requirements emerge
… the client should be able to offload work to the edge
… the edge cloud can hand it back to the client
Architecture
Max: the architecture proposal at a high level considers the client, the edge and the central cloud
… in some conditions, the client can offload to the edge, which can hand it to the central cloud or hand it back over the client
… A concrete implementation of that architecture uses WebAssembly as a unified run time on both client and edge
… WebAssembly is already deployed bon on the client and on the server
… the proposal would be provide an API to say that a give WASM module can be offloaded to the edge under certain conditions
… this would need to identify the address of the cloud - there is likely a need for a discovery mechanism, incl the network conditions
… if the code is to be offloaded, there needs to be a standardized communication mechanism across client/edge runtimes
… to enable interop across different vendors
… In terms of standardization needs:
… 1- a standardized API that enables different WASM runtimes to have the same developer experience
… 2- a communication mechanism & protocol between client & edge
… 3- a way to discover available edge cloud nodes and its associated network conditions - a developer can't assume there will always be an edge node available or that the network conditions are sufficient to make it usable; developers need to be able to declare the conditions under which the offload needs to happen. Not clear yet if and how much of it needs to be standardized - this needs further study
… 4- offloading policy - my current perspective isn't it should not be standardized and be left to vendors
Work plan
Max: I've published a draft of the use cases and requirements
… it's only a base line
Client-Edge-Cloud coordination Use Cases and Requirements
Max: I very much welcome proposals for additional use cases, solutions
… once we get momentum, we could look into incubating a charter for an actual presentation to W3C
Jeff: thanks for the presentation
… you talk about incubating a potential charter
… given the scope of the work, do you envision this as additional items to the Web Assembly WG, or a new group, or both?
Max: good question
… I personally think this kind of work proposal will be in the future will have more solutions
… this proposal is based on Web Assembly, but there will be proposals to offload JS code too
… so a group would need to coordinate Web Assembly WG and other organizations outside of W3C
… to enable the coordination between different solutions
Zoltan: is it possible to group use cases from a user point of view?
… vs from the provider viewpoint
… I think right now they're based on the provider perspective
Max: that's correct
… I welcome contributions to the document to improve it
@@@
Michael: why do we want to use edge resources? who use them? and then look at the how
… In terms of the Why - there are 3 reasons
… one is privacy - if you own the edge node, you control the data
… another is performance - you would expect the edge node to have better capabilities (e.g. power, memory, ...)
… finally, latency - the speed up you get from the offload is affected by the latency between the end device and the cloud
… the cloud, going over LTE is 50x slower than over Wifi
… In terms of public use cases
… the consumer is not the owner of the edge node
… e.g. a customer in a store, or a visitor in a city
… For private use cases: e.g. a person in their home who don't want to have their data leaving their house
… or a business not wanting their data to leave premises
… while still wanting to allow offloads
… the management of location has an impact on latency and privacy
… With that, how would we program the edge?
… there are 2 basic choices:
… extend the cloud computing mode
… in that case, the developer decides where the code runs - it's a deployment question
… the other model is more client-centric
… conceptually, the *user* is deciding where to run the code
… the developer still designs how the code runs, but the user has more control about the where
… incl allowing to run on privately run hardware
… If we want to extend the client:
… right now, the browser runs on the client device, and provides a sandbox within which the app runs
… this sandbox includes providing privacy to the user - a big design point for the Web platform
… How do we extend this to the edge?
… One area we should look at is extending current capabilities to help with lower friction
… Web Workers already provide a mechanism to offload work to a different thread
… right now, they're designed to run in the same computer
… what if we take this concept and its API shape (which includes support for WASM)
… and we can extend that API to include network connection
… which is aligned with the worker API communication mechanism
… The design would be that the Edge Worker would run possibly on the edge, with fallback on the client or the cloud
… This requires extending the sandbox to the edge worker
… since the edge node may have different code running, that sandbox is important
… so we need to provide an isolated execution context on the edge, similar to what the browser does on the client
… This raise new questions: how do find compute utility? how do we decide to use it?
… it could be hardcoded, but it's more interesting to enable discovery
… but we need to be careful with discovery since it can harm privacy
… so the discovery would have to be gated by the browser
… so assuming we have a discovery service, it needs to expose a number of metadata
… which helps decide whether or not to offload
… if offload is decided, we need to transfer the compute load
… the workload could be packaged as JS, WASM, or a container (although the latter is tied to a specific platform)
… we need to have a model to support parallelization and acceleration - if you don't get enough speed-up, the offload isn't worth it
… so we would need to standardize the service and the packaging
… (the packaging may not have to go through the client if it helps from a resource perspective)
… the idea that there is always a fallback to the client
… In terms of standards needed:
… metadata to discover services
… a way to do the actual discovery - close to what the WoT is doing
… a way to package workload (incl wasm)
… a way to offload
… offload rules to decide on where and when - may be implementation specific
… all of this while taking into account privacy considerations (e.g. when dealing with discovery)
… Summarizing: I think we need to think how to fit with an existing standard - here workers
… if we do this well, it may even be invisible to the developer, with maybe just the exception of allowing them to give hints on whether to offload or not
… Most of the standards work is actually going to be in the infrastructure
… I have a few discussion points
… There is an issue about migration: e.g. what if you get out of range, you need to migrate the workload
… in terms of persistence, we could look at extending Service Worker - this would be useful for IoT too
… this raises questions about lifecycles and may tie with PWA lifecycles
… We could also look at Fixed function workers, e.g. AI inference
… this will too tie to discovery
… A worker itself may be able to use discovery to recursively discover services, incl fixed functions
MichaelCollins: how would you offload to a service worker or a PWA?
MichaelM: I look at service workers as a convention to cache code & data
… a service worker is more persistent than a regular worker which stops when you leave the Web page
… if you want to set up a home security system, you want it to run even if your browser doesn't run
… PWA might support that
Zoltan: one use cases is an app wanting to compute data from plenty of sensors
… an edge service might be particularly useful e.g. to run an AI model where it can be provisioned
… but then this may require lots of bandwidth
MichaelM: there are 2 broad categories: computing acceleration and IoT orchestration
… in terms of bandwidth
… we've looked at latency
… but also big advantages in terms of bandwidth when staying locally, esp with WIFI6/7
… edge workers may also run storage service for caching data
Zoltan: the role of the Web client can be to be used for provisioning, beneath it there could be native apps
… or you could standardize different elements of the implementation
ScottGifford: do you imagine the edge being able to make network requests on the behalf of the user?
… or is it pure computing?
MichaelM: it depends on how we handle the boundary
… it should re-use the same permission mechanism provided browser
… but conceptually it should be considered as an extension of the browser
… if using for IoT orchtestration, it needs to grant specific access to the things you want to
… it's a similar problem to what the browser deals with
ScottG: I think the privacy challenge is probably the biggest challege - a generic computing utility to which you trust all your credentials…
MichaelM: the user may be given control on where/when offload might happen
… e.g. trust only your own hardware, or a specific ISP, or a specific service vendor
… Vendors can provide secured containers with encrypted execution environments
… One issue is around discovery: what if a service is lying about tis capabilities
EricSiow: important stakeholders are browser vendors, network providers and cloud providers
… so let's not just focus on technical aspects, but also look at the value propositions to these stakeholders
… to get the support needed for implementation
MichaelM: I do have more slides with business use cases with the benefits to the different vendors and conversations we've had with them
eric: great - we need to reach out and enroll them in that effor then
Jeff: +1 to eric
… next week is TPAC cross-group meetings week, an excellent opportunity for the Networks IG to schedule cross-group meetings with WASM, Service Worker and other groups and build that broader consensus that Eric was talking about
Open Topics
Song: we've heard of the advantage of PWA & WASM
… we would like to get more research on the potential of the Web in Telco Edge Platform
… also, network quality monitoring and prediction
… this is important for the offload policy
… this is being discussed in the network info & prediction work stream of the Networks IG
Sudeep: I would encourage that we attend the Web perf WG meeting, and the Device & Sensors WG
… there are ongoing discussion about new APIs around network information