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