- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 8 Jul 2020 16:11:56 +0200
- To: "'public-networks-ig@w3.org'" <public-networks-ig@w3.org>
Hi,
Here are the minutes of our discussion today:
https://www.w3.org/2020/07/08-web-networks-minutes.html
also copied as text below.
Dom
Web & Networks Interest Group teleconference
08 July 2020
[2]IRC log.
[2] https://www.w3.org/2020/07/08-web-networks-irc
Attendees
Present
Chris_Needham, Dan_Druta, Dom, Eric_Siow, Huaqi,
Hyuk_Jin_Jeong, Jon_Devlin, Michael_McCool, Peipei_Guo,
PiersOHanlon, Shachar, Song, Sudeep, Yajun_Chen
Regrets
-
Chair
DanDruta, SongXu, Sudeep
Scribe
dom
Contents
1. [3]Seamless offloading of Web App computation form mobile
device to edge clouds via Web Worker Migration
Meeting minutes
Sudeep: Welcome to everyone
… this is our 10th Web & Networks IG meeting
… today we have a guest speaker, Mr Hyuk Jin Jeong from Seoul
University
… before we jump into the main agenda, a few reminders
… join us on the IRC channel
… see other links on the wiki and homepage of the group
… Today's agenda is a guest topic by Mr Hyuk Jin from Seoul
University, who has been working on a topic of a great interest
for this group
… we had a similar presentation from Michael McCool back in
February
… we're really glad to hear on the slightly different approach
Mr Hyuk Jin and his team have been working on
… seamless offloading to the edge via workers
… it touches on many of the challenges we've been talking about
… we're also looking for input on potential standardization
opportunities
… This particular project have looked in particular at the
mobility aspect
Seamless offloading of Web App computation form mobile device to edge
clouds via Web Worker Migration
[4]Slides
[4]
https://lists.w3.org/Archives/Public/public-networks-ig/2020Jul/att-0001/W3C_Mobile_Worker_Preview.pdf
HJJ: I'm from Seoul University in South Korea
… my presentation is about seamless offloading in the context
of edge computing
… mobile client have limited hardware resources and need
computation offloading to servers
… offloading to cloud servers brings high latency, which can't
satisfy e.g. needs for cloud gaming
… one solution for that is the edge [slide 3]
… they provide ultra-low latency
… to make use of that, user mobility needs to be addressed
… [slide 4]
… if the client move from an edge server to another, there
needs to be continuity in execution: the execution state needs
to be migrated
… there have been various solutions explored, e.g. VM handoff,
container migration, serverless edge computing
… we propose a new approach, based on worker migration
… [slide 5] outline
… [slide 7] Background Web Apps
… Web Apps are widely used due to their portability ; they use
JavaScript and WebAssembly aka WASM
… the latter is is used for performance critical code
… Web app provide threading via Web Workers
… [slide 8] example of Web app simulating cubes fall from the
air
… [slide 9] the main thread shows the animation, the worker
thread does the intensive computation
… [slide 10] we measure frame-per-seconds of the animation to
measure client performance
… it shows that WASM is faster than JS, but not fast enough
when the number of cubes reaches a certain threshold
… [slide 11] given that the worker does the computation
intensive part, we would like to move it to the edge
… but it has state that needs to be migrated when the user
moves from an edge server to the other
… [slide 13] this is a common issue in edge computing
… [slide 14] this has been approached with things like Live VM
migration
… [slide 15] but that's a very heavy process, e.g. take 8s to
migrate a node.js instance
… [slide 16] another approach is to use stateless code
(serverless computing)
… [slide 17] but it is only effective for short-lived stateless
jobs
… e.g. it doesn't apply to our example with cubes
… [slide 18] we propose an approach based on migrating the
worker offloaded to the edge
… the migration includes the state of the worker
… when the user moves, there is a cloud-based fallback server
that serves as a relay between edge servers
… this allows to provide continuity
… [slide 19] we implemented a mobile web worker manager to
control this migration
… [slide 20] how to migrate the state of the worker?
… we serialize the JS state in a snapshot which can be restored
seamlessly
… [slide 21]: two technical issues when collecting the
snapshort: webassemlby and built-in objects; i'll only touch on
the former today
… [slide 24]: WASM is a low level instruction format for high
perf code
… it is built from high level languages such as C++ and rust
… [slide 25] migrating a WASM function brings two challenges:
… the serialized code is architecture-dependent
… and WASM maintains a large memory, which would take lots of
network overhead to migrate
… [slide 26] we solve this by sharing the wasm file for
compilation on the server
… and then stream the memory asynchronously
… [slide 27-29] step-by-step process
… [slide 30] evaluation
MichaelMcCool: have you considered using a virtual caching
memory instead?
… transferring from the client based on page faults?
… [I'll follow up offline]
HJJ: [slide 31] Evaluation environment: we use the average
internet speed of US in April 2019
… we measure 3 situations: offload, handoff, fallback
… through 3 test applications: physic simulation, face
detection, blur filter
… [slide 33] shows the results in comparison with VM migration
… the migration of just the app state (rather than the full
server state) helps a lot in performance
… initial mobile to edge can be slow, but is expected to happen
less frequently than edge to edge
… [slide 34] shows improvements with offload compared to local
… the last app shows a smaller speedup given its
characteristics
… [slide 35] we proposed a lightweight state preserve edge
computing framework for apps, with promising results
… [thanks]
MCC: compared to my earlier presentation, this sounds
complementary
… my presentation was about finding places where to offload to
- this sounds like they would work together
… with regard to memory, I was thinking using a virtual memory
approach to lazily transfer the memory that you need
… maybe you could prioritize the transfer based on what memory
pages were active
… or maybe start with transmitting the current page cache
HJJ: it is possible - at the destination, when the worker tries
to access a missing memory page, the client can send the memory
in an on-demand way
MCC: optimizing the WASM memory case would be good
… 1s latency of memory is reasonable in general, but not in all
situations (e.g. in a game)
… can this be optimized?
… with a better sync when handing off
HJJ: agree that 1s is critical in some time-critical apps such
as games
… maybe the perceived latency can be removed by overlapping the
execution across multiple servers
MCC: a server for offload should probably say what latency is
acceptable (e.g. whether 1s is acceptable latency)
… a declarative approach here might be useful
HJJ: indeed, it would depend on applications - developers can
specify their needs in terms of migration time
Piers: in terms of the transfer of the WASM image - if the edge
node is involved in the download of the asset, it could just
take a copy instead of having it sent from the mobile device
… have you looked at that kind of approach?
HJJ: if the WASM code isn't changed in the client, it could be
downloaded from external sources
Dom: I assume this needed to change the Web browser - was there
any change in the Web apps themselves?
HJJ: there is research to migrate Web Apps state without
changes to the browser, but it requires instrumenting the Web
Apps code which makes it more slowly
… in my case, I focused only on changing the Web browser
… it relies on gathering JS scopes
… which requires access to the internals
… Web Workers code can be offloaded as long as it doesn't use
local resources
Dom: under what conditions does the worker get offloaded?
HJJ: I use a simple heuristic based on the running time of the
event handler of the web worker
… when that time is long, I offload
… the network environment can be profiled at run time - I
assume the client does this, and this can be taken into account
in calculating the total time to offload
Sudeep: offloading reminds me of distributed computing
… offloading to the edge, to the cloud requires keeping track
of network conditions to optimize the offload
… how do you figure out what kind of compute resources are
available on the edge, to combine this with network conditions?
HJJ: my approach starts from the client - this architecture
cannot know information about the server
… but the server information depends on what kind of edge
server we use e.g. WIFI AP, small cells
… the environment (open space vs closed building)
… the information about servers (e.g. the # of clients using
the edge server) is important when deciding when to offload or
not
… but in this work, I didn't consider the effect
Sudeep: is there any relevant in the WoT in this context?
MCC: there is several components needed here: discovery (on
which there is ongoing work which would fit here)
… you also need to describe capabilities of the edge server -
e.g. performance, accelerators, etc
… that's a separate topic and is not covered by WoT
… another question is which available APIs - some don't make
sense to migrate (e.g. location)
… we need to either emulate or get the info back from the
client
Dom: what would be needed to standardize to make this possible
across browsers / edge?
MCC: there would need to have a standard interface between
browser / edge
… I covered some of the needs in my presentation
HJJ: I agree with MCC - the metadata of the mobile device and
also the runtime information of the server side to make the
offloading decision
… in terms of standards, what I think is important is that the
API should not be complicated
… a leading principle in my research was not to change the app
code
MCC: I think we should have a standard to migrate the app state
… when it comes to APIs, there are JS APIs used by the
developer, and the network API exposed by the edge server which
would be handled by the browser
Dom: how does the browser communicate with the edge at the
moment?
HJJ: the edge address is sent to the client and then the client
and the edge exchange via WebSockets
MCC: discovery could help expand this to any other network
environment
HJJ: yes, my work focused on the simple case
PO: how do you obtain information about the network quality?
HJJ: measured via the Linux network tools (socket stats) by
sending large files and measuring the time it takes
PO: you don't use the netinfo API for example?
HJJ: I didn't use it
PO: there is noise added to the netinfo API
Dom: it would likely not being needed in the context of a
browser implemented API (vs end-developer exposed one)
PO: another approach is for the server to send the information
to the browser, as in Transport Info draft I'm driving in IETF
Sudeep: how does it work when you fallback on the cloud and
move to a different location?
HJJ: are you asking if the migration between the client and the
edge, and then edge & cloud are different?
Sudeep: when migrating back from cloud, you have to pick
between client or a new edge server - does it go back through
the client? how does it work?
HJJ: I've assumed that the client initiate the migration where
the web worker will go
Dom: the edge/cloud infrastructure is independent from the app
provider, correct?
HJJ: correct, incl the fallback server in the cloud - in which
case the client needs to know about it in advance
Sudeep: any final comment from my cochairs?
DanD: definitely it's very interesting and indeed complementary
to what Michael was doing
… we've also heard from Samsung on similar topics - we need to
digest these proposals and work with the presenters and figure
out what and where standardization is needed
… it feels like we're onto something here
Song: Thank you very much - great presentation
… lots of interest from my team on this
Sudeep: Mr. Hyuk Jin Jeong, we will come back to you - we might
be interested in a demo if you're available for this
… we'll also further investigate the standardization needs and
share that back with you
HJJ: Thank you
Sudeep: our next meeting will be in August, talking about P2P
CDN
Minutes manually created (not a transcript), formatted by
[5]scribe.perl version 121 (Mon Jun 8 14:50:45 2020 UTC).
[5] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 8 July 2020 14:12:00 UTC