Enabling the Transition to the Mobile Web with WebSieve

Motivation:

Web access on mobile platforms has taken a big part (more than 20%) of web traffic, however, the performance of the mobile web is quite poor. While some high-end website providers have improved their websites on the mobile platforms, most of the small web providers still make no change of their websites due to the expensive cost and complexity of mobile-specific customization.

The motivation of WebSieve is to generate mobile friendly websites focusing on reducing the high load times on mobile devices for general websites. And the way they proposed is either block or de-prioritize the loads of low utility objects to reduce user-perceived page load times.

Main Points:

• Three high-level requirements: 1) Structure-awareness: be aware of the complex inter-dependencies between objects in web pages; 2) Utility-awareness: mechanisms is needed to predict the expected utility; 3) Practical optimization: object selection needs to maximize the utility subject.

• Three key design challenges: 1) Dependencies: we cannot select to load an object without choosing to load its parent as well; 2) Utility inference: different users and providers have different understanding of utility; 3) Object selection: predicting the load time when a subset of objects is fetched is difficult, also the web browsers' parallelization techniques need to be considered, and the load time of specific device and operating conditions depends.

• Proposed approach:

• Dependency Extraction: distinguish between the objects that are genuinely missing vs. objects that have been replaced.

• Utility Inference: run user study to infer utilities, personalize the WebSieve, account for functional dependencies, account for provider utilities.

• Optimal Object Selection: use compact integer linear programming formulations, address the load time approximation.

Trade-offs:

• Some utilities, such as advertisement, which may not be important to users but important to the profits of providers. These independent utility may be filtered by WebSieve.

• Time cost of estimating dependencies as well as the optimization of object selection vs. Traditional load time need to be considered.

Cloud is not a silver bullet: A Case Study of Cloud-based Mobile Browsing

Motivation:

A cloud-based browser combines an application on the device with powerful cloud servers to make the browsing experience faster, simpler and more data-efficient. The cloud does much of the work of rendering and optimizing the web page and as a result reduces the amount of data transmitted to your device and the processing power needed on the device. This is the general claim of the cloud based browsers but the author shows in his case study that though the cloud browser is a popular browser it is not significantly better than a device based browser.

Main Points:

• The evaluation of the case study is primarily focused on two metrics
  (a) Page download time
  (b) Device energy consumption.
• The Cloud Browser uses a Cloud Browser Markup Language (CBML) .The CBML employs data compaction techniques on the web page re-sizing images and compression of data.
• Page download time is the time from the first SYN and the last ACK for all objects in a page. This information can be obtained by tracing packets on a device.
• The total energy metric consists of two components the CPU energy consumed by a browser to download a web page and render it and the network energy consumed by the radio interface for a web page download.
• Pages that are heavy on Java Script(JS) code run more efficiently on Cloud browser with respect to Direct browser in terms of energy consumption.
• When the user interactivity is high offloading the JS may not be the best decision as it will consume more energy.
• Data compaction will not be always beneficial in the Cloud Browser as sometimes the energy required to compress the data will be more than downloading the actual JS.

Trade offs:

• The paper is evaluated mainly on just two areas viz 'Page download time' and 'Device energy consumption'.There are other areas which could have been considered like start time,privacy,security etc.
• The results are based on download of the first single web-page which may not give the best results.
• The paper mentions that all the experiments are done in a single location. The results may wary if the experiments are performed on several other geographic locations.
• The paper focuses on proving that direct browser is better than cloud browser but in many of the results the cloud browser performs significantly better than the direct browser.

Cloud is not a silver bullet: A Case Study of Cloud-based Mobile Browsing

Motivation:
Because the methods used before do not give systematic understanding of cloud-based browsing in design level. For cloud-based browser, moving functionality to the cloud is not always saving energy and download time. So the author makes a evaluation to show when to move functionality to the cloud.

Main points:

The author compares two extreme points and then argues that Cloud Browser  can not provide clear benefits in energy and download time.

Setup and Methodology:

1. Testing first download  page, which means that both direct browser and cloud-based browser can not use local cache. 

2. Just testing first download page is not enough, because it is not real.  So the author add user interactivity into the test. 

3. The conclusion of first method shows that compaction ratio  affects the performance of Cloud Browser. So the third method is to test the impact of compaction. 

4. The fourth test is to download the non-JS version of the pages by CB and Direct.

The reason why CB is worse is :

1. There exist redundant data since CB streams multiple CBML for the page. 

2. Even though adding user interactivity, CB's performance is still worse than Direct method. The reason is also CBML.
3. Downloading the page from the server and performing data compaction is the bottle neck.
4. It may be that CB consumes more CPU cycles to decompress the CBML thereby consuming more CPU energy than Direct.

Based on the measurement,  the author conclude that :

1. Offloading JS to the cloud is not necessarily beneficial

2. Considering user interactivity when offloading JS is important

3. Data compaction is not always beneficial

Critiques:

I  do not agree with the conclusion "Data compaction is not always beneficial". Because in order to get this conclusion, we need to compare CB and CB without compaction instead of Direct.

Based on the analysis of the paper, the bottleneck of CB is CBML.  How to improve that part? How to avoid the redundant data? If we modified this part, the outcome maybe different.

Enabling the Transition to the Mobile Web with WebSieve

Motivation:

In this paper it presents the WebSieve architecture to democratize the ability to generate mobile-friendly websites. It focuses on reducing the high load times on mobile devices for generic web pages.

Main points:

-- To reduce the high load time, three high-level requirements are needed before achieving this goal in practice:

• Structure-awareness: blocking one object may cause other objects to be filtered.
• Utility-awareness: predicting the expected utility that an user gets from different objects, so that critical content of website won’t be clipped out because of filtering.
• Practical optimization: taking into account the practical issues, like budget/dependency constraints, complexity of parallel loading for browsers.
  

-- Using WebSieve to reduce page load times, it primarily focuses on achieving the balance between page load time, user experience and interests of website providers.

-- There are two practical challenges: 

dependencies between objects and difficulty of modeling loading time.

To address the first challenge, it proposes compact integer linear programming formulations. 
For the loading time, it’s addressed by leveraging the load time waterfall for the original web page.

Trade-offs:

-- For the dependency, a specific object can be downloaded only after its logical parents have been processed. It relies on identifying the parents. It does not illustrate how to find logical parents, or the cost of it.

-- In order to increase user experience, it delays the load of some objects on the website. But it’s hard to decide which parts are blocked or delayed based on the objects utility, and importantly, the variety of users’ interest and website types.

Accelerating the Mobile web with Selective Offloading

Motivation:

Loading a webpage on a mobile phone would require a lot of computation power, which is very limited for a mobile device. Web pages have high page latencies on mobile devices and consume about 35% of energy for computation, which is therefore a bottleneck for power sensitive mobile devices. Frameworks like Opera Mini, Amazon Silk and Android Chrome Beta have been developed to address this issue, by offloading fixed parts of web pages. The paper presents a different framework, which allows to offload any portion of the page load process.  Selective offloading of portions of pages reduces the computation as well as data usage.

Main Points:

- Methods adopted for offloading native applications differ from web pages in two ways: network activities and computation are inter-dependent in web pages, also different kinds of objects have different computation patterns. Therefore offloading in mobile would have the following advantages:
1) Reduced round trips: If parts of the page load process is offloaded to the cloud, cloud interacts with the web server on behalf of the mobile device. The latency can be reduced by placing the web server close to the cloud. Also, the cloud can connect to the mobile device using a single TCP connection, unlike the case when the mobile makes multiple TCP connections to the server in order to load a web page directly.
2) Reduced time in computation: Opera mini and Android Chrome beta compress the webpages in the cloud while leaving the full logics of page loading process to the mobile device. The new framework sends the webpage in its intermediate form, which is easier to analyze.
3) Consistency with other mobile constraints: Performance, power consumption and data usage are the key constraints on mobile phones. Performance is improved due to reduction in the round trip times and computation. Power consumption is also reduced because of a single TCP connection instead of multiple connections to the web page. Data usage is reduced as the cloud transfers the intermediate representations of the webpage to the mobile device instead of raw pages.
- There are few challenges involved with the computation offloading, few of which are:
1) No standardized page load process, which therefore requires different implementations.
2) When and what to offload
3) Determining the location of cloud servers is difficult. They can be placed near the web servers to reduce latency, but which web server is still a question.
4) Security issues: The cloud breaks the security between the mobile and the server.
- The framework discussed in the paper addresses these challenges by providing a solution to each of them. In order to determine the portions of computation to be offloaded, the data flow is represented as a Directed Acylic Graph(DAG). Therefore, the problem of dividing the page load process is now equal to finding the cut of the DAG. The location of the cloud servers should be near or at a CDN service. The question of when to make offloading decisions would be made by the cloud as it is the first of all active components that collect useful information.
- Processes like object loading, HTML parsing, Rendering might be inter-dependent, which is therefore a bottleneck. These bottlenecks can be identified by applying critical path analysis to the DAG constructed earlier. Offloading decisions should consider reducing the time spent on the bottleneck.

Drawbacks:

- As the cloud sends intermediate representation to the mobile, converting the intermediate representation back to the original form would involve computation and is therefore an overhead.
- Criteria to choose a location for a cloud server is not well defined. I multiple CDNs have information required to load a page on a single cloud, then the position of the cloud server could be close to any of the CDN.
- No experiments have been shown in order to support the correctness of their work.   

Accelerating the Mobile Web with Selective Offloading

Motivation

    Nowadays, mobile devices become more and more popular as a convenient access to Internet. However, it's still very slow to load a web page on these devices. The reason is that there are a lot of limitations with mobile devices. Thus, offloading is now adopted in some browsers to solve the problem, such as Opera Mini, Android Chrome Beta and Amazon Silk. But only compressing and fixed part offloading are applied in them. The authors come up with a more flexible way, offloading portions of the page load process, and describe the opportunities, challenges and a measurement-based framework in this paper.

Main Points

• Web application is different, its network activities and computation are inter-dependent, and computation of different kinds of objects incurs different patterns.
• If close to a CDN provider, a cloud can efficiently reduce the page load time. And a computer is obviously faster than a smartphone, while a computer does not have power and 3G/4G data limitation. 
• Lack of standardization and documentation makes the page load process hard to understand. Decreasing computation may cause increasing network time, and it's hard to measure. Position of cloud server can be guaranteed to be close to CDN providers, and security issues & cache issues may change due to the cloud between CDN providers and mobile devices.
• The size of intermediate representations generated by HTML Parser, Object Loader, Evaluator and Rendering Engine can vary even larger than the raw. And blocking due to dependencies among these controllers leads to the bottlenecks of a page load, so identifying the bottlenecks and spending less time on it are necessary for a good decision.
• Divisions are subject to constraints, and two portions division will not increase the interactions.
• Cloud servers should be close to CDNs, and decision depend on different situations and web pages.
• A single TCP connection between cloud and device can provide more bandwidth and better control with specified priority policies.
• The model only depend on measurements, so it can accommodate with future technologies.

Trade-off

• Since the Web servers is dynamic due to CDNs, to choose a cloud server may cause overhead, or it will cause a bad decision.
• Some issues are described without good solutions, such as security and cache.
• This framework need more concrete examples and experiments to be convincing.

Amazon Silk

Motivation:
When a traditional browser requests a web page, the browser has to complete a series of resource-intensive, client-side processes before it can display the page. All the client-server interactions can add up to slow page loads, especially given the limited resources of a mobile device and the increasing size and complexity of modern websites.

Amazon Silk is a web browser developed by Amazon for Kindle Fire line of tablets and Fire Phone. The architecture is designed for both rapid page loading and extended engagement with the page. With Amazon Silk, much of the processing behind page rendering can be performed in the Amazon cloud. Amazon Silk is designed to create a faster, more responsive mobile browsing experience.

Main Points:

• Amazon Silk has the vast capacity of Amazon Web Services (AWS) behind it. Using AWS, Amazon Silk analyzes aggregate web traffic patterns, preprocesses pages, and applies predictive algorithms to determine the fastest way to deliver content to the device.

• To minimize latency and page load times, Amazon Silk routes requests through remote proxy servers powered by Amazon EC2. These cloud servers provide high-performance connection speeds and computing power not normally available to a mobile form factor.

• Amazon Silk can learn from web traffic patterns and use this learning to improve the individual user experience.

• Caching on the Amazon Silk back end is one of the primary mechanisms Silk uses to accelerate page loading.

• Amazon Silk supports SSL communication between the device client on the Kindle Fire and origin servers. 

• Amazon Silk supports the Do Not Track (DNT) header request field, an HTTP header field that specifies a user preference about data collection. Many web sites collect information about user browsing behavior, and with the DNT field users can opt out of such data collection.

• Amazon Silk provides broad support for the emerging HTML5 standard and for related media features.

Trade-offs/Comments:

• Because every site, everything the users do online through Silk will go through Amazon. The most concerns should be related to privacy problem. Silk can log URLs for the pages it serves, as well as record the originating IP addresses to troubleshoot and diagnose technical issues, which would identify the network used by the browser.

• Amazon Silk supports SSL communication between the device client on the Kindle Fire and origin servers. For enhanced privacy and security, SSL traffic is not routed through Silk remote proxies in the Amazon Cloud, and they don't collect any metrics regarding web page resources downloaded using SSL connections. That means users' SSL browsing is not accelerated by the proxy servers.

Clone2Clone (C2C): Peer-to-Peer Networking of Smartphones on the Cloud

Motivation:

    Offloading computation to the cloud server has been prevailing in the field of mobile computing to solve battery limitation on mobile devices, however in some circumstances, offloading among mobile devices can also be desirable. The paper takes advantage of P2P protocol and architecture to build wireless P2P network and perform computation offloading among mobile devices.

Main Points:

           

            Existing offloading techniques do not provide P2P connection among smartphones, nor do they provide communication-offloading support.

            CloneDS running on public cloud decouples the users to clones and clones to IPs. In addition to directory service that connects peers together, it provides security infrastructure and verify authenticity of each component.

            CloneDS can be implemented as a whole external entity or as a distributed service. In the latter case, replicas are kept in each cloud and their consistence is maintained by broadcasting signed updates among clouds.

            Clones in the cloud will handle intensive computation and makes sure mobile devices are up to date; it also offloads communication across mobile devices.

            ClondDoc, a real-time P2P application shows that clones in the cloud can handle as many computation tasks as possible and keep devices (users) synchronized while maintain secured communications.

                                                                                        

Tradeoffs:

            Security is the major tradeoff of the scheme. Distributed implementation of CloneDS is not well handled. Furthermore, man-in-the-middle attack, TCP hijacking, can also be serious threats to the system.

            The paper assumes users are always trusted by the cloud, which in reality could also lead to security issues.

            A collaborative document editing application might not be a good example of computation-intense task, which is the motivation of offloading.

            Error handling, fault tolerance, offline scenario are not discussed in the paper.

Clone2Clone (C2C): Peer-to-Peer Networking of Smartphones on the Cloud

Motivation

    Nowadays, people are still suffering from battery limits, while offloading computation to cloud is a good solution. However, in this paper the author provides us with a novel way --- C2C --- to explore mobile cloud computing. It makes it possible to build P2P-based protocols for smartphones. Also, CloneDoc, a secure real-time collaboration system is introduced, which can be implemented on C2C to reduce computation and save energy.

Main Points

• Several offloading mechanisms, e.g. MAUI and CloneCloud, are reviewed to demonstrate that P2P inter-connection is a novel way.

• Clones can run in private or public clouds, public cloud clones outperform private cloud ones.

• CloneDS is always up as a directory server, which can map users to clones and clones to IPs. All the ID, IP address and public keys of devices and clones are stored in CloneDS for future connections.
• CloneDS can be replicated on each cloud providers, in which users can choose the cloud they trust, and updating can be consistent by broadcasting.
• Clones in clouds can get operations from user while deal with operations of the other users for synchronization and coherence. Also it can reduce the redundant operations, take care of all crypto operations and keep updates on devices.
• CloneDoc, a secure real-time collaboration system,shows that C2C enables offloading of both computation and communication, which can efficiently reduce the bandwidth usage, decrease the burden of mobile devices, and save energy.

Trade-off

• Although communication offloading are provided, users may still lose connection with CloneDS, which means that sometimes the clones can't be located even created.
• More use cases should be provided to show that it's desirable for users.
• Offloading of cryptography to cloud reduces computation on devices, but is a little worse security. Users can't always be guaranteed to be correct, also leading to security problem in the clouds.

Clone2Clone(C2C) : Peer-to-Peer Networking of Smartphones on the Cloud

Motivation:

A Wireless Peer to Peer network between smart phones is notably hard due to limited battery power and unreliable low bandwidth network connections. This is solved using Clone2Clone platform where the clones of the smartphones are always on in the cloud and are connected using high bandwidth reliable network. By this approach, not only the computation is offloaded but also the communication across mobiles is offloaded to the cloud.

Key Points

• Smartphones has a clone running in the private or public cloud. This lets installation of applications which are in mobile to the clone.
• To enable peer to peer networking among the smartphone clones, CloneDS directory service is maintained in a separate cloud. It contains the mapping of all the mobile deviceIDs of the smart phones and its clone’s locations.
• When a clone wants to connect to other device’s clone, it queries the CloneDS passing the device ID and gets the address of the clone. This will be used for further communication to send any updates.
• Clones in the cloud performs computation intensive tasks and keeps the data synchronized and pushes the updates to device.
• CloneDoc, P2P collaborative document editing application is developed showing the clones in the cloud receiving updates from mobile devices and handle as many tasks(like authentication, encryption) as possible on the device’s behalf and keep the device up-to-date.

Positive Points:

• This is a different and novel approach to enable peer to peer networking by saving battery and network bandwidth.
• It seems to be a good architecture design for collaborative editing application as the clone can work on behalf of mobile and when the user connects back, the entire copy in the clone could be pushed to the device.

Trade Offs/Comments:

• There will be additional complexity in keeping the clone and mobile device synchronized. It does not explained how the updates will be merged between clone and smart phone if there is a conflict.
• This paper does not explain much use cases or scenarios where this kind of architecture where clones communicating among each other would be required.
• Most of the mobile application is user event driven where the clone cannot perform any task when the user is disconnected.

Towards Synchronization of Live Virtual Machines among Mobile Devices

Motivation:

• People increasingly rely on mobile devices in their everyday lives, often multiple devices such as a smartphone and a tablet. The utility of these devices would improve if users could switch seamlessly from one device to another, in particular if they could continue using applications on the second device exactly where they left off on the first device, with both data and computation state preserved across the switch without apparent delay. For example, a user who starts watching a video on a smartphone may want to continue watching the video on the larger display provided by a tablet. But there are some limitations including per-application data synchronization, intermittent connectivity and so on.

Main points:

• Introduction of VMsync, a system for synchronizing the state of live virtual machines (VMs) among mobile devices. In the context of device switching, VMs encapsulate both data and computation state for a complete operating system and all its applications. Therefore, synchronizing VM state between mobile devices automatically synchronizes all application state. And there are several established techniques for migrating VM state between hardware hosts: live migration(transfers a VM image while the VM continues to run in the originating host, only suspending the VM for an imperceptible period while control is finally switched to the receiving host) and opportunistic replay(decreasing the amount of data transferred during VM migration in low-bandwidth environments).
• Preliminary design: shows a initial architecture of VMsync, made up of multiple host devices with virtualization support and a resource-rich server in the cloud, used a synchronization point between devices. It seeks to incrementally transfer changes in an active VM on one device to standby VMs on other devices, so as to maintain a consistent VM image and minimize switching latency. The VMsync architecture involves a daemon running outside the guest VM on the active device. This daemon inspects the memory and file-system state of the VM and sends recent changes to a server in the cloud. The server then forwards the changes to standby devices.
• The progress of initial design of VMsync, only one active VM will be running at any given point in time to ensure that VMs do not diverge. This active device will propagate changes of both memory and file system state to the synchronization server over the period of time in which the device is active. We consider this process a checkpoint. Every other VM, considered standby VMs, will be paused and periodically updated via the synchronization server if the device is online. Devices which are not connected to the network or have not been synchronized will be considered to be in a stale state and must be synchronized before a user can switch to that device. 
• Feasibility study: set up the experiment environment on the Android platform. And author choice devices which are specific standards. Measuring checkpoint sizes: the author uses four curves, each corresponding to a different checkpointing policy to evaluate different policy’s performance. They are Dirty Orig, Diff Orig, Dirty Prev and Diff Prev. Measuring the total bytes required for Sync: the author used four elements which are Final Diff, Final Dirty, Incr Diff and Incr Dirty to help give some indication of which policies would have higher or lower switch penalties. In all cases, the Final Diff and Final Dirty results remain constant (within a standard deviation of the work- load) across varying time intervals. And author performed a combined workload which added background music. In general, the system background application has minimal effect on the system state.

Trade-offs:

• The author just used virtual data transfers as a rough proxy of various costs incurred during VM synchronization: bandwidth, latency and energy. Actually, if we would the policy is more convincing that author needs to design real experiment with different conditions to get the real data.
• The experiment is on Android platform. But as we all know, the Android and the IOS system have different architecture and backend scheme. The VMsync maybe suitable for the Android platform, but it maybe would have reverse effect on IOS platform. The author needs to consider this situation.
• In the measuring the total bytes required for Sync part, the author should consider that in different policies, final and incremental, may incur significant time and space overhead. The measure of overheads is important because it would influence the result of performance.
• The paper presents preliminary design for VMsync and a feasibility study aimed at determining how much data would need to be transferred under different mobile workloads and synchronization policies. Transfer the difference of previous checkpoint will be feasible. Measure total bytes required for Sync shows the policy would be feasible. To sum up, the VMsync is a feasible approach.

Amazon Silk

Motivation:

Silk was developed to divide processing between the client (Kindle Fire) and Amazon’s cloud system.  The goal was to create a browser that allowed for faster website loading through preprocessing, traffic patterns, and predictive algorithms to improve the users browsing experience while using Kindle Fire.

Main Points:

• Users are able to choose which acceleration techniques are used: 

• Accelerate Page Loading – by default Silk accelerates loading by routing some connections through the cloud.

• Instant Page Loads – predictive loading to speed up page load times

• Experimental Streaming Viewer (ESV) – lets users watch Flash content on supported websites.

• The main purpose of this development guide is more of a “best practices” in modern website design to make sites accessible on touch-screen devices while utilizing HTML5 and CSS3, than it is an informational document about Amazon Silk.

Trade-offs/Influence/Comments:

• In focusing the document on developers, the guide does not go into technical detail on the ways in which Amazon Silk is accelerating website loading and instead keeps the descriptions brief and at a high level before moving quickly into their guide for developers.

• Amazon has created this development guide with the goal that developers will make websites compatible with Silk.

•  This guide then claims their suggestions to be methods of correct web site development that should be followed regardless of a designer’s expectation of a client using Silk and more because it is in a designer’s best interest to make a website that can be viewed and accessed correctly regardless of the browser and device.

• Some issues that are brought up specifically with Silk is how to obtain a client IP address when browsing is routed through a remote proxy and that it can be found in the X-Forwarded-For request header. 

This is a very high level document and covers what could be considered general knowledge of the best practices for creating dynamic websites with proper usage of HTML5 and CSS3 with some small comments on functionality checks to perform to determine fall backs when working with different browsers, and Silk specifically.  With this in mind, it is hard to critique as it isn't an in depth article on the cloud offloading decision process, predictive loading, or ESV mentioned at the beginning of the guide.