Edge Computing for the Web -- 18 Sep 2019

<sudeep> https://www.w3.org/2019/07/31-web-networks-PrinciplesForWebNetworks.pdf

<sudeep> https://www.w3.org/2019/07/31-web-networks-TheviewfromtheEdge.pdf

<scribe> scribenick: dontcallmeDOM

DanD: we wanted to briefly introduce the concept of edge computing and how it relates to things developed alaredy in the cloud & networking space and how it may impact the Web
... I gave this presentation a couple of months ago to the Web & Networks IG
... if you're interested on the topic, check it out - we're tackling issues related to how to expose network features to the Web layer
... [slide the view from the Edge]
... [basic idea of edge computing]
... historically, functionality has been split between client and server
... this has gone back and forth depending on evolution of computing power available on device and the capacity of the network
... this has evolved over the past 3 or 4 decades
... what we have now is the introduction of a 3rd piece in the architecture
... adding to client and server the edge, which can sit anywhere between the two (if at all)
... it's close to existing concepts, CDN, proxy browsers
... but compared to those, these are for static resources
... The edge is both an architectural and a deployment paradigm shift
... from a developer perspective, the edge piece can both be the client and the server
... the edge is defined by the administrative boundaries
... and it is associated with the network and data center topology
... a lot of the elements that (from a network operator perspective) consitute the network can be virtualized
... most of our network is moved to IP which frees real instate in geographic footprint
... if you're familiar with central offices where switches used to be, they are now facilities that are closer to the user and can serve as data centers
... [use cases - a 3 dimension approach]
... you have to look at use cases through different lenses
... from a functional perspective, from a control & management perspective, from a location placement
... latency is definitely a key aspect since bringing functionalities to the edge help with reducing latency

Michael: privacy would another requirement

DanD: this is not so much about requirements for edge apps as much as characteristics of apps that can benefit from edge computing
... Edge computing is also relevant now in the context of the deployment of 5G, with a disaggragation of functions in the network,
... network slicing can also create useful characteristics
... and a push to the edge among cloud providers
... An example on how this is relevant to the Web community
... assuming a Web app runs on the client that has a lot of workload on the client, you may want to find an edge node to shift your processing
... assuming a component has already been deployed in edge infrastructure - how would a client find it? how does it verify it satisfies the requirements for the app?
... how does it adapt to mobility circumstances?
... how does it adapt to congestion load on the node?
... this is mostly done as an agent to the OS at the moment
... WebApps could take advantage of these scenarios
... Assuming you've deployed your app on edge nodes e;g. in a cloud platform - how do you figure out the best one to find, how do you transition?
... this type of APIs might be worth exposing from the UA
... I don't know how this woudl be done, what security implications this would imply
... we want feedback and input on these questions
... ETSI Multi-Access Edge Computing provides APIs at the infrastructure level
... incl network conditions, location - but this is for the app running on the edge
... it doesn't involve the browser per se
... Another initiative is the Akarino project from the Linux Foundation
... it's an integration open source project that provides blueprint integrated hardware and software for specific use cases
... e.g. IoT, RAN deployment

Michael: there are many edge computing stacks under development
... In terms of use cases, there was browser offloading
... but there are also non-browser use cases, eg. orchestration
... some are compute-intensive, some not
... also questions around data movement is a consideration
... you gain in compute but raises the time to transfer data back and forth
... We have an existing thing in W3C that could be extended to support this
... for instance ServiceWorker
... or PWA
... Micro-services are also related

QQT: the CDN is classical in network architecture
... we're exploring distributed networks, e.g. P2P CDN
... if a browser want to support a P2P CDN, it needs a P2P API
... how does the browser support a P2P network distribution system?

DanD: to design P2P + edge, finding the peers is something you would want to do very quickly
... finding the closest peer to you shouldn't involved going out to a far away data center
... when you design a P2P artchitecture, instead of going peer to server to peer, you could query an edge piece to find that information
... that would be a way to leverage the edge in a P2P network

QQT: if we find a peer node, how do we connect to it?
... some nodes doesn't support HTTP, just UDP/TCP
... e.g. bittorrent

DanD: what you put on the edge is up to you
... you have your own application that runs on the edge node
... it hosts your piece of the app
... you make it work

Michael: another way to look at it is the edge as a set of available functions
... the question becomes what protocols can be made available
... the browser is mostly client-server model
... whereas things-based projects are more peer-to-peer
... Instead of looking at edge from a full-stack perspective, we can also look at it from a more functional perspective

DanD: for P2P, WebRTC could be used

QQT: WebRTC brings too much for this

Michael: WoT supports multiple protocols
... we have a scripting API but we don't have a deployment model for it
... I've been wondering if this would be a good place to put that

QQT: WoT is closer to the edge

Michael: we want to have an environment to run the code

Sudeep: is the question how do we discover the edge and we can use WoT protocols to do that
... and once we discover the edge, how do we offload?

Michael: discovery is one problem
... another is management: how do I install some code and control it at run time?
... another is a provisioning environment

DanD: Akaraino may actually solve this
... Blueprints go higher or lower in the stack

Michael: from a high level, what gaps can W3C help in this context?
... without looking at specific stacks, what is W3C strength? what is the gap? what is the problem we can solve?
... we have the Web developers community, a certain collection of APIs that we can evolve
... can they be expanded to account for the edge?
... we also need to under the business models

DanD: one thing I do want to point out - I keep mentioning that an app would need to be edge-aware, not edge-dependent
... you need a fallback in case an edge node cannot be found

Michael: there are various mechanisms that we could extend
... e.g. considering serviceworker: you could transparently pushing it to the edge if available; if not, fallback on client serviceworker
... another approach would be microservices: the server could push some of its microservices to the edge
... but that is no longer in W3C's scope

DanD: if you want to push this to serviceworker, it would need to be partly transparent to the developer

Michael: I think that's one option that should be considered and developed
... not clear if this would be fully transparent, or with an hint, or with more developer control

SOng: it's not just about discovering the edge node
... how can a Web developer invoke some interface to do discovery, connection?
... based on my experience from an operator perspective, the edge computing will support most services
... for Web/HTTP requests, we need to speak with the infrastructure provider
... if not, there is no direct communication yet
... we need to get operators and device makers to support that - as soon as possible

QQT: is there a way to access an edge node from HTTP?
... from the browser?

DanD: Once you know where it is, you can use the browser HTTP stack

QQT: but the edge node IP address can change all the time

DanD: if I understand the requirement, you would try to find an edge node to find a local peer
... the edge node is an IP address
... to which you ask the best peer
... and then you shift your communications to it

QQT: the results would provide some IP address then?

DanD: right

QQT: and we would use it to access to the edge node, with what protocol?
... HTTP? the problem is that we can't use HTTPS due to domain matching

DanD: this isn't different from a deployment to the cloud

Dom: but how do you map an IP address to a domain-based certificate for TLS?

Michael: there is COmmunity Group that has been looking at this
... this has been bugging us for a while in Web of Things
... it's difficult to get support for this in browsers
... a local CA would work but can't work in browsers

Dom: I don't think we have an answer to this at this time - it feels like a major challenge from a deployment perspective

DanD: coming back to our broader discussion
... it would be interesting to look at what W3C could do
... with Michael's serviceworker approach, would this be like an edge browser after previous cloud browser?
... would we need to define what a client would look like?
... and what APIs it would expose?

Michael: fwiw, I think this only solves a specific use case: browser offloading
... another issue is that serviceworker are very limited in terms of what APIs they can use
... for instance, having access to AI on the edge based on what is under development would be important
... ServiceWorker doesn't have filesystem support
... e.g. for persistent

dom: cloudflare has a product with a serviceworker-based deployment for its cloud infrastructure
... which sounds interestingly similar to what we've discussed
... combined with the advent of Web Assembly on client/servers, lots of interesting opportunities
... although lots of unknowns

DanD: one unknown would be to understand what features would be available to this "edge user agent"
... WebGL? WebML? others

Michael: not sure if serviceworkers would have access to them

Dom: maybe not now, but they could be adapted to new contexts

Michael: WebAssembly can be thought as containers
... so this may be an opportunity for W3C to get into that space
... The other question is discovery - if I find a node, how do I deploy code to it?

chunming: several years ago, W3C had generated a note about Cloud Browser architecture
... where a lot of the browser rendering was done in the cloud
... if we have edge in the middle, can we offload some of the browser tasks (e.g. time consuming calculation to the edge)
... e.g. to help battery, or better performance
... Another question - we heard of applications (e.g. AR or VR scenarios)
... currently all the rendering happens in the device
... but there are use cases where e.g. AI detection tasks would be running in the edge

DanD: the cloud browser was mostly focused for set top boxes for media
... it was to offload the settop box to the cloud e.g. for the fancy navigation
... in the end, the idea is the same
... between cloud browsers, split browsers with user interactions, proxies - this was done e.g. 20 years ago by Opera
... they did caching, transcoding, mapping between technologies to save bandwidth
... the concepts are very similar
... they had a browser running in the cloud
... if you think of what properties you want to offload to the edge, you can start identifying what an edge ua would look like
... and then you have to juggle between where to run these APIs
... if you tackle this problem by looking at how to run Web technologies to the cloud (closer or further), the question is what can be run with what security considerations?
... e.g. how to ask user permission?

Dom: I would start with simple e.g. offloading computing
... follow up could happen in the Web & Networks IG
... otherwise, or when we're ready to experiment/prototype, we could move to a dedicated CG to play with ServiceWorker
... the IG is probably the right place to explore the overall landscape

Michael: WoT would want a lot more and very different things from the edge

Dom: agree, but we probably want to start with low hanging fruits

Michael: for WoT, you would want to install persistent orchestration service - setting new functionalities, now moving things up or down

DanD: if people are interested, please join us in the Web & Networks IG
... we'll work on clarifying that particular topic and identify concrete next steps
... it seems there are ideas, probably not clear yet but worth exploring

- DRAFT -

Edge Computing for the Web

18 Sep 2019

Attendees

Contents

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output