W3C home > Mailing lists > Public > public-networks-ig@w3.org > July 2020

[minutes] July 8 teleconference

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>
Message-ID: <7d6ec3a8-a217-72ea-09e2-754978c4b0bb@w3.org>

Here are the minutes of our discussion today:

also copied as text below.


              Web & Networks Interest Group teleconference

08 July 2020

   [2]IRC log.

      [2] https://www.w3.org/2020/07/08-web-networks-irc


          Chris_Needham, Dan_Druta, Dom, Eric_Siow, Huaqi,
          Hyuk_Jin_Jeong, Jon_Devlin, Michael_McCool, Peipei_Guo,
          PiersOHanlon, Shachar, Song, Sudeep, Yajun_Chen


          DanDruta, SongXu, Sudeep



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

   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

   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

   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

   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

    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

This archive was generated by hypermail 2.4.0 : Wednesday, 8 July 2020 14:12:01 UTC