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