12:56:34 <RRSAgent> RRSAgent has joined #web-networks
12:56:34 <RRSAgent> logging to https://www.w3.org/2020/06/11-web-networks-irc
13:00:05 <cpn> cpn has joined #web-networks
13:01:00 <dom> Present: Seikwon_Kim, Sudeep, Suyambu, uzair, venu.musham, Peipei_Guo, Michael_McCool, Eric_Siow, Dan_Druta, Dom_HazaelMassieux, Ravi_Nanjundappa; Chris_Needham
13:03:33 <dom> Present+ Chandan, Kodam_Nagaraju, Theo, Venugopal
13:04:42 <dom> Present+ Piers_O_Hanlon
13:04:53 <dom> Topic: Intro
13:05:12 <dom> Sudeep: welcome to the Web & Networks IG call, after a few months of hiatus - hope everyone is doing OK
13:05:42 <dom> ... Today we'll have an interesting talk - before going there, some useful information
13:05:57 <dom> ... we have an IRC channel we using during the meeting
13:06:05 <McCool> McCool has joined #web-networks
13:06:33 <dom> ... please pass the message to companies that might be interested in joining the group
13:06:37 <piers> piers has joined #web-networks
13:06:41 <dom> Present+ Louay_Bassbouss
13:07:08 <dom> ... a few updates from the chairs on what's coming before going the guest speaker from Samsung on distributed Web engine
13:07:18 <dom> ... particularly relevant to the edge computing workstream
13:07:22 <dom> ... A few general updates:
13:07:36 <dom> ... the wiki has updates on our planned upcoming talks
13:07:48 <dom> ... one on Web worker in July
13:08:04 <dom> ... another one from Peer5, an eCDN company
13:08:26 <dom> ... We're looking into talks from CloudFlare, and for a talk on WebTransport
13:09:11 <dom> ... We're also building a Q&A wiki on edge computing and network quality to cover what we've had presented so far
13:09:29 <dom> ... we're encouraging the IG members to contribute
13:09:47 <dom> ... we've also started documenting our findings on P2P CDN and Video cloud services
13:09:55 <dom> ... some of these pages have been translated in Chinese
13:10:10 <dom> ... We'll be sharing more details on this in a dedicated meeting
13:10:25 <dom> ... A final update: the WebRTC WG is calling for wide review on Scalable Video Coding
13:10:48 <dom> ... this is relevant to our IG given its impact on video in varying network conditions
13:11:03 <dom> ... please take a look and feel free to bring your input to the spec
13:11:06 <dom> Present+ Huaqi
13:11:29 <dom> Topic: Resources Efficient Distributed Web Browser by Offloading Processes to Remote Edge Devices
13:12:03 <dom> Sudeep: we're welcoming Seikwon Kim and his Samsung colleagues to hear their work on a distributed browser engine architecture
13:14:01 <dom> Kim: good to meet you all - I'm from Samsung Electronics, and I'll be talking about Castanets, a resource efficient distributed Web browser
13:14:12 <dom> ... we're open to start collaboration on this work
13:14:32 <dom> ... Web standards are evolving - Web apps are composed of multiple layers combined dynamically
13:15:11 <dom> ... that means more and more resource consumption from Web browsers
13:15:42 <Peipei_Guo> Peipei_Guo has joined #web-networks
13:16:06 <dom> ... yet, devices on which browsers are deployed can be very resource constrained - e.g. fridges, watches
13:16:32 <dom> ... these two trends are in conflict, which require a new solution to solve this
13:16:48 <dom> ... Slide 2 describes the architecture of a modern Chromium browser
13:17:40 <dom> ... the browser process is graphics bound, but it orchestrates various rendering process which are CPU and memory bound
13:17:58 <dom> ... our solution allows to support browsers on low-end devices using edge computing
13:18:15 <dom> ... it helps reduce up to 40% memory consumption and up to 60% CPU consumption
13:18:41 <dom> ... slide 4 shows the evolution of browser architecture from single device/single process, to single device/multiple process today
13:19:35 <dom> ... the multiple processes approach helps deal with the risks associated with running rich web applications, both in terms of crash and in terms of security with separate sandboxes
13:19:54 <dom> ... We believe a next step in this evolution is for an engine to span multiple devices with multiple processes
13:20:36 <dom> ... this matters to cater for lower-resources devices, and taking advantages of improved network conditions with 5G
13:21:25 <dom> ... slide 5 shows the memory usage of displaying web pages from top Web sites, split between renderer process and browser process
13:21:45 <dom> Present+ Song_Xu
13:22:03 <dom> ... e.g. YouTube consumes 100MB in browser process, 130MB in renderer
13:22:27 <dom> ... lots of variation across Web sites on renderer process, whereas the browser process is fairly predictable
13:22:28 <McCool> GM is Gmail?
13:22:44 <McCool> ... or average?
13:23:25 <dom> ... when rendering multiple tabs, the browser process memory consumption doesn't increase much, whereas the renderer tabs increase with each new tab
13:23:27 <McCool> (question on slide 5/29... will ask later)
13:23:54 <McCool> (... ah, geomean)
13:24:01 <dom> ... slide 6 shows the CPU breakdown across several web sites as a percentage split between renderer/browser
13:24:37 <dom> ... slide 7
13:24:57 <dom> ... we showed the value in offloading processes to the edge, slide 7 shows how we do it
13:25:22 <dom> ... the idea is to push the renderer process to the edge, and only runs the browser process on the client
13:25:50 <dom> ... castanet is composed of 3 major components: a browser process, a render process and an orchestration component
13:26:07 <dom> ... the browser component runs on low-end device and show the UI of the browser
13:26:19 <dom> ... the renderer device runs on high-end device or on the edge
13:26:41 <dom> ... orchestration runs on both low-end and high-end devices and the edge
13:26:49 <dom> ... slide 8: major changes in castanets
13:27:08 <dom> ... to enable this offload requires some major changes in the browser architecture
13:27:22 <dom> ... we'll focus only on a subset - we can discuss separate for more in depth discussions
13:27:29 <dom> ... slide 9
13:27:49 <dom> ... the remote process runs on the edge cloud, waiting to be requested via a network IPC
13:28:24 <dom> ... the browser process searches a edge node via a discovery protocol and contacts a service agent which creates a socket that gets connected to the browser process
13:28:51 <dom> ... we don't run the renderer process in the background all the time to avoid wasting resources
13:29:05 <dom> ... slide 10: Chromium resource loader
13:29:29 <dom> ... compating with how other browser (e.g. Chromium) load resources
13:29:47 <dom> ... with shared memory
13:29:56 <dom> ... slide 11 shows how castanet does it
13:30:42 <dom> ... to reduce network overhead and improve performance, the network process is migrated to the edge cloud
13:31:04 <dom> ... and uses shared memory on the edge node
13:31:06 <dom> s/cloud/node
13:31:22 <dom> ... slide 12 shows multimedia support in Chromium
13:31:42 <dom> ... a very important feature in Web browsers given the popularity of video web sites
13:31:59 <dom> ... the media pipeline happens in the renderer process
13:32:08 <dom> ... slide 13 - multimedia in Castanets
13:32:48 <dom> ... we can't decode the frames on the edge (otherwise we would have to send decoded frames over the network, which is not practical)
13:33:27 <dom> ... so the browser process (on the client) deals with the decoding, and that's where the media pipeline happens, and is overlayed to the rendered layout from the renderer process
13:33:34 <dom> ... slide 14: limitations and issues
13:34:07 <dom> ... Getting IPC messages among heterogeneous devices is a challenge
13:34:40 <dom> ... we also have policy issues in case of network problems: what to do in case of a disconnection? how to manage if the renderer is turned off?
13:34:54 <dom> ... slide 15: service discovery agent
13:35:15 <dom> ... when we started, we used hardcoded IP addresses to establish the link between the browser and renderer process
13:35:35 <dom> ... this evolved over time as we worked on supporting more devices and OSes
13:36:13 <dom> ... there also needs to be load balancing across devices
13:36:22 <dom> ... which led us to the set up of a service discovery agent
13:36:26 <dom> ... slide 16
13:36:49 <dom> ... the service discovery agent is responsible for resource monitoring, network tunneling, version management
13:36:54 <dom> ... slide 17
13:37:02 <dom> ... the architecture of the discovery agent
13:37:29 <dom> ... the server (on the left side), the client (on the right side)
13:38:22 <dom> ... the process is that the browser process broadcasts messages to find a node
13:38:34 <dom> ... response is sent via MDNS
13:39:08 <dom> ... the resources monitoring module is responsible for tracking CPU/network characteristics, etc
13:39:28 <dom> ... as that data is obtained, the module "service provider chooser" picks the best node
13:39:38 <dom> ... which then launches the renderer process
13:39:44 <dom> ... we plan on using SDP/ICE in the future
13:39:59 <dom> ... slide 18 shows the coverage of the service discovery agent
13:40:36 <dom> ... we're considering several situations: multi-cast for single NAT discovery, STUN for NAT traversal
13:41:06 <dom> ... we could use TUN server for situations where STUN doesn't work, but that doesn't seem likely to give good or affordable results
13:41:11 <dom> ... slide 19
13:41:27 <dom> ... To choose the best performign device, we first need to define what best means
13:41:44 <dom> ... is it loading speed? service stability? network latency? could be many variations
13:42:01 <dom> ... in our case, we've focused on best loading speed
13:42:26 <dom> ... we compute a score based on network bandwith, network latency, CPU usage
13:42:43 <dom> ... slide 20
13:44:00 <dom> ... shows the impact of evaluating the performance based on network bandwidth
13:44:12 <dom> ... slide 21 shows with CPU Frequency, and core utilization
13:44:55 <dom> ... the resources monitoring module in the discovery agent - it uses network scope and CPU score as the main factors
13:45:17 <dom> ... This score is dynamic - the monitoring module periodically measures it
13:45:39 <dom> ... we use a moving average to evaluate the stability
13:46:01 <dom> ... the formula (on slide 22) is not fixed and can be made to evolve
13:46:24 <dom> ... slide 23 shows how we found the best-fit formula from our measurements
13:46:42 <dom> Present+ Zoltan_Kis
13:47:49 <dom> ... slide 25 shows an exact of device integration in home with their score
13:48:29 <dom> ... the watch picks to pair with the TV which has the highest score, which the actual loading time confirms is the best pick
13:49:15 <dom> ... slide 26 compares castanets results with Chrome, Firefox and Opera Mini, running on an Android with 4GB memory
13:49:44 <dom> ... slide 27 shows the impact of memory usage, an important consideration for consumer eletronics devices
13:50:03 <dom> ... the impact is shown across several popular Web sites
13:50:36 <dom> ... Castanets reduces 26% memory compared to Chrome
13:51:14 <dom> ... slightly higher than Opera Mini, but Opera Mini doesn't support full-browsing capabilities and requires a separate server component
13:51:18 <dom> ... slide 28 on CPU usage
13:51:56 <zkis> zkis has joined #web-networks
13:52:09 <dom> ... Where both Firefox (+27%) and Opera Mini (+5%) uses more CPU, Castanets requires much less CPU
13:52:14 <dom> ... Slide 29: Conclusion
13:52:37 <dom> ... Castanets is an edge distributed browser composed of a browser process, a renderer process and an orchestration module
13:52:58 <dom> ... There are issues still to be solved on manage heteregenous web engines and different version of a given engine
13:53:25 <dom> ... The short-term approach to solve this is via the orchestration engine
13:53:39 <dom> ... the long-term would be to align IPC messages across browser engines and versions
13:54:57 <dom> MichaelMcCoo: what in general should be W3C-standardized in this? I think discovery should be part of it
13:56:01 <dom> Kim: to achieve the pairing between the browser and renderer process, @@@
13:56:36 <dom> ... the scoring methods don't need to be standardized, but there should be a way to open up scoring methods
13:56:47 <cpn> q+
13:57:04 <dom> cpn: thank you for an excellent presentation
13:57:25 <dom> ... I wanted to ask about Web APIs that are device specific
13:57:35 <dom> ... e.g. geolocation, or bluetooth, NFC
13:57:42 <dom> ... how would these work in this split environment?
13:58:16 <dom> kim: for now, we don't have any support for this (?)
13:58:52 <dom> Chris: regarding Michael's question, the state protocol to manage different renderer / browser process would be another candidate
13:59:02 <zkis> q?
13:59:38 <dom> Dom: how do you measure the network characteristics?
13:59:50 <dom> Kim: it has been hard - we use ICMP for latency
14:00:00 <dom> ... for bandwidth, we're limited with @@@
14:00:31 <dom> ... the only approach, which is not practical, is sending bulk data
14:00:34 <dom> s/@@@/iframe/
14:01:08 <dom> Sudeep: thank you Mr Kim for this great presentation - there are many more questions we'll have to discuss
14:01:25 <dom> ... we will want to continue discussions on future standardization opportunities off-line
14:01:33 <anssik> anssik has joined #web-networks
14:01:55 <cpn> Some related previous work from the Web + TV IG: https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF https://w3c.github.io/me-cloud-browser/
14:02:00 <dom> ... looking forward to engaging with you all
14:02:22 <dom> RRSAgent, draft minutes
14:02:22 <RRSAgent> I have made the request to generate https://www.w3.org/2020/06/11-web-networks-minutes.html dom
14:04:05 <dom> RRSAgent, draft minutes v2
14:04:05 <RRSAgent> I have made the request to generate https://www.w3.org/2020/06/11-web-networks-minutes.html dom