- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Thu, 11 Jun 2020 16:19:17 +0200
- To: "'public-networks-ig@w3.org'" <public-networks-ig@w3.org>
Hi,
The minutes of our teleconference today are available at:
https://www.w3.org/2020/06/11-web-networks-minutes.html
and copied as text below.
Dom
Web & Networks Interest Group teleconference
Resource Efficient Distributed Web Browser by Offloading Processes
11 June 2020
[2]IRC log.
[2] https://www.w3.org/2020/06/11-web-networks-irc
Attendees
Present
Chandan, Dan_Druta, Dom_HazaelMassieux, Eric_Siow,
Huaqi, Kodam_Nagaraju, Louay_Bassbouss, Michael_McCool,
Peipei_Guo, Piers_O_Hanlon, Ravi_Nanjundappa;
Chris_Needham, Seikwon_Kim, Song_Xu, Sudeep, Suyambu,
Theo, uzair, venu.musham, Venugopal, Zoltan_Kis
Regrets
-
Chair
-
Scribe
dom
Contents
1. [3]Intro
2. [4]Resources Efficient Distributed Web Browser by
Offloading Processes to Remote Edge Devices
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
[5]Slides of CASTANETS: Resource Efficient Distributed Web
Browser by Offloading Processes to Remote Edge Devices
[5] http://www.w3.org/2020/06/11-web-networks-castanets.pdf
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 separate 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
… compating 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:
[6]https://www.w3.org/2011/webtv/wiki/Main_Page/
Cloud_Browser_TF [7]https://w3c.github.io/me-cloud-browser/
[6] https://www.w3.org/2011/webtv/wiki/Main_Page/Cloud_Browser_TF
[7] https://w3c.github.io/me-cloud-browser/
Sudeep: looking forward to engaging with you all
Minutes manually created (not a transcript), formatted by
[8]scribe.perl version 121 (Mon Jun 8 14:50:45 2020 UTC).
[8] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 11 June 2020 14:19:21 UTC