Distributed workers
By Michael McCool and Sudeep Divakaran
Transcript
I'm gonna be talking about distributed workers which is proposal to extend the web client program model to support distributed computing.
And this is work we've been discussing in the context of the Web and Networks IG inside W3C.
So problem statement is that all browser hosts are limited and they're more limited on portable devices.
But generally speaking, performance is always gonna be insufficient for some applications.
And on portable devices, you're further constrained by batteries.
So web apps are limited by the browser host.
There's often more computation available elsewhere on the network.
And a lot of web apps use the cloud but the cloud has long latencies, relatively speaking and also has, you know, location and privacy, and confidentiality constraints.
So if you're in a business, for example, you may wanna offload your own private cloud and not to the main cloud.
And just an idea of the latency impact, you know, going to the cloud, you know, can be on the order of, you know, 50 to 100 milliseconds.
Whereas for interactive rates, you want sort of, like 10 milliseconds and you also need time for compute.
So the communication time is a serial overhead which can impact the high-performance applications.
And a good example is be a game where you want to get around 50 hertz at least.
And it's hard to do that when your communication alone took 50 hertz.
Now the issue with accessing distributed resources is limited by the programming model.
It's relatively complicated to set up and this impacts the scope of applications that can use it.
So we wanna find a way to simplify access to distributed resources.
So I'm gonna talk about distributed compute resources.
So generally the web program model is a client server model.
We mostly just think about compute on the server or on the client, but you know, distributed compute resources is everything else, right?
And there's two large categories.
There's edge computers, which are sort of cloud-like but don't live in the centralized cloud.
And this can include content distribution networks, ISPs computers, including the one that you might get in your house, private clouds and businesses and computers integrated into say 5G or 6G services, MEC.
But there's also can be other computers that you have, say on your LAN, so maybe a homeowner has a laptop, a phone and a desktop, and they wanna offload work from their phone to their desktop. (clears throat) So in general though, the kinds of applications we're interested in are ones that are location sensitive.
So they are sensitive to latency and privacy.
But we also need to take into account that these distributed resources are gonna be less elastic and less reliable, and more diverse in the cloud.
And so we have to deal with things like, you know, a resource going offline suddenly or negotiating among different options, and picking the best one and so. (clears throat) Now, there's different models.
Edge computing, one very common model is to extend computation on the server and moving computation on the server down into the edge resource.
This proposal takes a different approach of extending the client program model including the sandboxing of the competition on the client.
And we wanna find a way to do this that's compatible with existing web program models.
And we also would like to give the client the power to decide when and where to run the code.
So the application developer, you know, deploys the code but the client gets the power of where to run the code and what data to give it.
So you want to give the client control of their own data and also enable the use of the client's own hardware or the hardware of their choice.
So in general, the application model we're looking at is to push work up from the bottom and migrate work from the client into the distributed compute resource.
So the crux of the proposal is we already have an API in the Web3 model that's close to what we need, it's called Web Workers.
And Web Workers currently lets you run compute in another thread.
But what if that thread could be on a different computer?
It turns out that the communication model with Web Workers, it's pretty close to what we need to communicate across the network.
And since Web Workers are well known and understood by web developers, they can immediately begin using them.
We just gotta figure out the plumbing for how to get workers to run somewhere else.
And so that plumbing is, we need an environment to run the worker in, that environment needs to preserve the sandboxing properties of the client, and also perhaps provide isolation, you know, and some assurances about safety of that client.
We need to be able to find a service to run this.
We'd be able to compare multiple options and we need to manage the execution. (clears throat) And the other thing to say here is that, well, the packaging of the workload needs to support good efficiency.
If the purpose is to get more performance, we wanna find a way to package workloads that give us that performance.
Fortunately, there are things like Wasm that give us this performance and we can also look at other options.
The other thing I would say is the workload gets pulled down from the server.
It doesn't get sent from the client.
This is to avoid having two trips instead of one.
And in general, the edge computer or the target computer will have better connectivity.
So the target computer (coughs) and the compute utility running on it, which is a service would complement the browser.
And discovery and execution are supported by essentially restful APIs that the browser can talk to. (clears throat) So we want essentially a discoverable web service for the compute utility.
We want to have a way to package a workload for a worker and we want to extend the worker standard. (clears throat) And we also wanna support, you know, run these services anywhere.
So the discovery mechanism shouldn't be tied to running in MEC or something.
It should be something that is extensible.
We also need to standardize the interface.
So this web service would have an API that is standardized.
We would not be standardizing the implementation.
There's many choices for how to implement this.
And we would provide, you know, the ability for many different people to provide these kinds of implementations.
So for more information, please contact me, Michael McCool.
You can also join in the Web and Networks Interest Group.
I have two URLs there for that including meetings at TPAC, if you're here at TPAC.
And then you can also look at this document we've written talking about Client-Edge-Cloud Coordination Use Cases.
And I wanna close by saying there's more than one way to satisfy this objective.
And the distributor workers is just one option.
Thanks very much.
