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
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