HomeCloud: An Edge Cloud Framework and Testbed for New Application Delivery

This short paper is more of theoretical architectural proposal of the edge cloud framework. At the core remains the idea of integrating SDN and NFV to create and open source edge cloud infrastructure also to facilitate new application delivery.

Motivation

Future unavoidable challenges facing the centralized cloud computing.
a)Massive data volume generated because of explosion of Internet of Things(IoT), makes it hard for centralized data centers to handle this huge volume of data.
b)Latency requirements can be tremendous challenge for many applications which involves end to end communication between edge devices and centralized data centers
c) Difficult in portability across different cloud platforms leading to monopoly, which inhibits the innovation.

Important Ideas
1. The paper argues that improvement in Edge cloud orchestration and application delivery approaches and mechanisms are important necessities to enable edge cloud.
2. HomeCloud Framework- This novice idea is for the edge cloud to effectively deliver future new portable applications over a shared edge infrastructure.
3. To generate the shared edge infrastructure, the paper proposes to coherently integrate Software Defined Networking(SDN) and Network Function Virtualization(NFV),which are complimentary technologies.

Framework architecture

Contributions of the paper
1. Development of HomeCloud orchestration and application delivery framework in Edge Cloud, which integrates the SDN and NFV.
2. Discusses two use cases which can adapt the proposed HomeCloud framework.
3. Development of HomeCloud framework testbed to demonstrate s simple multiparty chatting applications.

Strengths 
1. With the ever increasing research in the area of SMART home applications, HomeCloud framework proposed promises to efficient open source infrastructure to further facilitate in this area.

2. The proposed idea is open source and tries to break the monopoly of the large corporations. This will further drives competition among the proprietary owners,bring down the costs and help the end users greatly upon implementation.

3. The framework  at its core has the idea to integrate the SDN and NFV. It argues how it can both benefit the stakeholder's involved and make further leaps technically by doing integrating these two ecosystems.

4. The framework considers different aspects of the both NFV and SDN and clearly addresses different components, their functionalities, interfaces in a intricate manner.

5. The detailed steps provided to ensure a successful delivery of edge cloud application on the HomeCloud and application of these on two use cases provides much more details.

Weakness

1. There is no details about the test results of the framework.
2. There is no much comparison made against any of the existing framework in Edge cloud paradigm. How HomeCloud is better when compared to them ?
3. This is just a high level conceptual paper with detailed implementation details of the framework non-existent in the paper.
4. The testbed considers simple chat application between two clients. This leads to question the scalability and whether the framework can handle complex applications.
5. Application portability is not addressed across different cloud platforms.

Discussion points
1. What are the challenges that we can foresee in the integration of SDN and NFV which is at the core of the HomeCloud idea ?
2.  The paper discusses about breaking the monopoly of the large corporations with this framework. Is it totally possible and what are its challenges ?
3. What are the different use cases we can implement using this approach ?
4. How can we handle hetergenous IoT devices effectively in this framework ?

NetBricks: Taking the V out of NFV

Summary
------------
Network Function Virtualization (NFV) proposed the use of software network functions running on VMs instead of hardware middleboxes to achieve simple deployment and management, faster development, and reduced costs as multiple network functions can be deployed on the same machine. Despite these advantages, there have been limited wide scale NF deployments. The reason for this can be attributed to the lack of available tools for building and running NFs which support easy development (through the use of high-level abstractions), and high performance (by making low-level optimizations) at the same time. Another problem with the current NFV deployments is that they try to achieve memory and performance isolation using VMs which leads to performance overheads. The authors try to solve these problems by proposing a new approach, NetBricks, to build and run NFs. The programming model used by NetBricks provides high-level abstractions for common packet processing tasks facilitating rapid development. The execution environment provided by NetBricks to run NFs relies on safe languages and runtimes for isolation, as opposed to the current systems which use VMs for this purpose, and thus, suffer from performance issues. Another problem with the current systems is that they achieve packet isolation by copying packets as they are passed between NFs leading to high performance overhead. NetBricks solves this issue by using using unique types which prohibit simultaneous multithreaded access to the same data by static checks during compile time, and cause no runtime overhead.

Strengths
------------

• It is a thoroughly thought out framework from the perspective of practicality.
• Uses type checking and bound checking to get back the network performance lost because of packet copying to provide packet isolation.
• Enables run-to-completion scheduling i.e., applying all NFs on a packet before proceeding to process another packet, and this is known to provide high throughput.
• The paper provides an extensive list of programming abstractions, making it easy for a new developer to use these and write any new NF without worrying about the low-level optimizations.

 
Weaknesses
---------------

• The framework does not support dynamic NF chaining, and requires a restart to perfom changes in the chain. I suppose this is because packet isolation requires type checking which is being performed at compile time.
• Although, the authors provide an extensive list of programming abstractions, but with new advancements, we can expect a need for new abstractions to arise. And, it looks like a NF developer is currently dependent upon NetBricks to provide an optimized version of the new abstraction.
• Currently, all the abstractions use same batching technique to maximize the common-case performance. Different batching techniques might be advantageous in different scenarios, and there can also be scenarios where batching might not be desirable.

Discussion Points
----------------------

• The paper shows that as number of memory accesses per packet (16 or higher) increases, the throughput achieved by NetBricks NF is comparable to NF written in C using DPDK.  Although, most of the NF might require very few memory accesses per packet, it would be interesting to identify cases where we actually need high memory accesses per packet. NetBricks can be implemented for such cases very easily, using it's programming abstractions, without any noticeable performance loss.
• The use of run-to-completion scheduling raises the question of the order in which the packets are processed, and how to schedule nodes that involve more than one packet. Currently, the authors use a round-robin scheduling policy to schedule such nodes. A discussion of a more complex scheduling policy, and its effects might be interesting.

For additional information related to NetBricks -
[1] http://netbricks.io/
[2] https://www.usenix.org/conference/osdi16/technical-sessions/presentation/panda

Low-cost Video Transcoding at the Wireless Edge

Overview:

This paper talks about providing video transcoding solution using the low-cost hardware device, Raspberry Pi (RPi). RPi is a low cost hardware device which includes a GPU and a hardware decoder and encoder which can accelerate the video transcoding process. This hardware based solution (TransPi) is in-lieu of many other software based solutions which use adaptive bitrate approach  and video transcoding techniques. The video transcoding solution runs at the wireless Edge (attached to the wireless Access Point(AP) / home WiFi Access Points), which provides more agile adaptation to sudden changes in the network and is able to quickly incorporate client feedback. This solution offers real-time video streaming service, and therefore enhances the user experience while watching any live-streaming videos without any interruption or re-buffering.  

Key Points:

1. Video transcoding converts the input video stream to pre-configured format to overcome any issues presented by multiple formats of the video streams.
2. Preprocessing approaches like “adaptive bitrate” where media server maintains multiple versions of a video, encoded in different bitrates and qualities, have limitations such as accurate prediction of the network changes so that the corresponding version could be loaded for streaming. TransPi, a cost-effective, real-time video transcoding solution solves this problem by processing the incoming video on the fly with minimal delay.
3. TransPi supports two streaming formats HLS ( HTTP Live Streaming) and DASH (Dynamic Adaptive Streaming over HTTP), where it just follows their specifications and not the rate adaptation algorithms, since TransPi uses a hardware encoder and decoder to transcode input video data to a single-rate output Stream based on user’s network connectivity.
4. HLS is HTTP based media streaming protocol which breaks the video stream into small fixed length chunks. DASH, provides high quality streaming of media content delivered over web-servers. Both use adaptive bitrate streaming technique to adapt any network changes. A client may select from a number of different alternate streams containing the same material encoded at variety of bitrates based on network bandwidth.
5. Digital Academic Television Network  (DATN) has been used as media source. Paradrop AP is used to have programmable AP and tweak network bandwidth for experiments.
6. Results from their initial experiments brings out the following limitations and hence motivates to have a low latency edge powered solution which could incorporate high fluctuations in the network.
1. HLS and DASH are either too conservative or too aggressive in choosing the optimal bitrate.
2. The number of bitrates selected are too less to handle network dynamics
3. Bitrate adaptation technique doesn’t work well in the wireless environment, especially when the last hop to the client is wireless
7. Video Streaming service near the access point improves the quality of video by maximizing bandwidth utilization as well as by selecting the video bitrates accordingly.
8. TransPi uses channel-aware bitrate decision approach, which is as follows:
1. Bandwidth monitor periodically(100 ms) sends client’s information to the encoder on RPi, which helps in determining transcoding parameters instantaneously.
2. Video transcoder fetches the requested stream, decodes and encodes with the adapted bitrate (once per second) based on client’s information.
9. Client plays the transcoded output segments in real time with a delay of 400ms ( ~75 KB, also chosen as the output queue size in the transcoder).  

Strengths:

1. Authors have done extensive research in the related domain to find the limitations of the current solutions, and hence try to get a unique solution ( hardware based) which opens new possibilities for future improvements as well pertaining to hardware based solutions.
2. Authors discuss about the design pretty well and have evaluated their proposed algorithms by testing them extensively.
3. Authors have accounted for any scalability changes (number of users in the network), and proposed solutions to address problems arising with that ( clustering multiple RPIs along with transcoding manager).

Weaknesses:

1. The implementation of the transcoding algorithm is not discussed much in detail, as to how RaspberryPi utilizes the hardware encoder/decoder as well the use of GPU.
2. Scalability of RPIs can be a limitation (discussed in paper as well), since TransPi works best when number of streams is more than number of users in the network.
3. 400 ms as the size of output queue has been empirically set. This value has not been played around with, in the experiments.

Discussion Points:

1. How valid is it to assume that the last wireless hop is the bottleneck in the network? There might be other parameters that might be affecting network bandwidth.
2. Can there transcoding algorithm be parallelized on a single device (they talked about parallelizing multiple processes in a rack of RPIs), since we know transcoding is computationally intensive and Raspberry has a GPU?
3. How would the size of output queue (taken as 400 ms) impact their transcoding results, had the authors experimented with that attribute?
4. It would be insightful to have the results of using this transcoding technique in a multiple APs environment (like our University where we have multiple Wifi APs) where the tasks can be offloaded to other wifi APs (nearest APs) if the number of users accessing a particular wireless AP are high.

Greening the Internet with Nano Data Centers

The paper provides the idea of Nano Data Centers against the traditional data center paradigm to address and improve the energy efficiency.

Data Center Limitations

1.      Overprovisioning to match the peak load demand even though average load remains much lower. Datacenters are overprovisioned because of the redundancy requirements (robustness)

2.     High cost incurred because of Heat dissipation- Heat dissipation accounts for at least 20% to 50% of total power consumption.

3.     Because of need to locate the data centers in different geographical locations, it results increased distance to end-users, which increases bandwidth mileage requirements. And, also adds to the energy consumption of networking equipment.

What is Nano Data Center or NaDa?

NaDa is a distributed service platform based on the tiny managed servers located at the edges of the network. NaDa is based on P2P protocol, with one main difference. NaDa is coordinated and managed by a single entity ISP.

Main contributions of the paper

1.      Develop model to evaluate energy consumption of Data Centers vs NaDa.

2.     Apply model in the context of video-on-demand services.

3.     Use trace-driven simulation to quantify energy savings.

Nano Data Center philosophy

1.      Take advantage of the always on gateways to achieve energy efficiency.

2.     Add memory and stronger CPU to home gateways.

3.     Push content to the gateways when bandwidth requirement is low

4.     Millions of gateways are managed as a ‘single logical unit’ using P2P infrastructure. 

Advantages of NaDa

1.      Improved Power Usage efficiency when compared to centralized data centers.

Power Usage efficiency is ratio between total power consumed by a data center and the power actually delivered to its IT equipment.

2.     Service proximity, because of which information travels shorter distances and reduction in energy consumption of the networking equipment that carries traffic.

3.     Self-scalability, because of the inherent nature of the network.

4.     Increased energy efficiency since No baseline power is used. That is, if we use gateways only when they are active, power consumption is proportional to the load leading to more efficiency than centralized servers.

5.     Residential GW PUE is 1.07 when compared to data center PUE of 1.2. Energy savings as high as 58%.

6.     Localized and personalized services can be provided to the end users.

Three key components used in VoD & simulation.

·       Gateways: provide storage, bandwidth resources.

·       The tracker: coordinates all VoD activities in NaDa.

·       Content servers: provide content to gateways and clients (if needed)

Content Placement Strategy

1.      Split the content into smaller chunks.

2.     Replicate the content across random gateways.

3.     Number of replicas determined by solving optimization problem based on the constraints on available upload and storage, number of clients, request rates etc.

4.     Popularity aware placement based hot/warm/cold strategies.

Hot: replicate on all gateways.

Warm: replication is done minimally

Cold: No proactive placement (Stays on servers)

Strengths

1.      The paper presents detailed analysis on the Nano data center philosophy. The experimental results tendered shows significant improvement in the energy savings which is the primary motivation of the paper.

2.     NaDa uses existing infrastructure which can significantly reduce load on conventional servers.

3.     Simulations done are using real time scenarios. Simulations demonstrated energy savings ranging from 20% to 60% versus data centers.

Weakness

1.      Uplink bandwidth is often limited. The paper does not provide any solution to this.

2.     Real time deployment- Since there are millions of gateways to manage using P2P architecture.

3.     Data privacy- Since centralized data centers are more secure physically and have advanced security measures implemented, how do we manage privacy of data at the gateways.

4.     Price of the gateway - The paper makes major assumption that the cost of replacing new gateways is less the cost(power cost) incurred in running the data center.

5.     Although the idea was very well received by some companies and academia, the project seems to have no success stories on the market yet.

Discussion points

1.      Privacy is major concern. How do we improve security and privacy at the edge/home gateways?

2.     Potential QoS issues moving control from content providers (YouTube) to ISPs. How do we resolve this?

3.     How do we manage the effects of consumer line overprovisioning ?

4.     How can we encourage users to agree on the NaDa philosophy ?

Auditeur: A Mobile-Cloud Service Platform for Acoustic Event Detection on Smartphones

Many number of apps are being developed on the acoustic event detection i.e. on basis of speech, music, heartbeat etc. It is inconvenient for the app developers to write efficient acoustic processing algorithm separately. Auditeur is a platform where developers can register for acoustic events and whenever an event occurs the app would be notified.

Auditeur provides API to enable the registration of the applications for which events could be manmade sounds, music, vehicle sounds etc. It generates a context aware and energy aware classifier for event detection and notifies the application when the event occurs.

Collection of training data:

Training data that are used in the classification problem are collected in form of soundlet which is 3- 30s audio clip. The audio clip is attached with the contextual information which combines phone generated context about audio clip and also the user tags. There are two types of tags: content which describes what sound is and container that describes the background e.g. office. An example of phone context information could be location of the phone, body position w.r.t. phone etc.

Storage of the training data:

The collection of data is logically divided into public and private spaces. Soundlet in public space can be shared between developers but private space is for each developer. To prevent malicious tags in the public user domain, sanity check are performed and there are fixed set of tags that are predefined.

Training model:

In cloud, the feature vector is generated from the audio clip which is 121 dimension vector. The content tags are used in two different ways, look for tags that describes a class of soundlet and within tags which describe sounds in the universe. The request for training a model contains the sound app is looking for, other unwanted sounds that can occur in the environment, contextual information and energy constraints. These parameters can be controlled by the developer of the app.

The process of Auditeur is as follows:

1. Auditeur provides and API that can used to record, add tags and upload soundlet to cloud.

      2. After sound is captured, tagging is done by the user / phone generated.

      3. Upload the audio clip and tags to the cloud.

      4. Auditeur generated a model taking into account the energy constraints of the mobile device and transfers the plan to the mobile phones in XML format in terms of components to attach for a particular model.

      5. Periodically if there are changes in the mobile phone resources such as battery etc. a model is regenerated by reducing the number of features used.

      6. Sound engine service present inside phone detects the events by running the model and notifies the model.

Strengths

      1. The paper is well described and thoroughly evaluated for all the design choices made.

      2. The framework is built to make it easy for the application developers.

      3. The framework presented in the paper is a combination of both in-phone and cloud but once a model is obtained there is no latency in communicating with cloud for further steps.

      4. It is a single framework where all speech recognition applications can subscribe for any event detection. If every application has their own event detection then energy consumption in that case is more.

           5. The context information is also taken into consideration while training a model which gives improves accuracy of model.

      6. The pipeline developed is adaptable i.e. it can be changed dynamically based on the energy constraints. 

      7. An experiment is conducted for the user experience both for developers and users and feedback given is incorporated into the system.

      8. While doing classification, the pipeline contains both frame level classification and also window level classification.

     Weakness 

      1. The User while labelling the context and container should label them properly especially for videos in the private space.

      2. The paper mentions that the typical users for Auditeur are the developers. For the private space videos, they are stored for every user separately. What if there is a particular sound that is required by multiple developers? Will Auditeur provide any API to actually share the private space between developers?

     3. When uploading an audio clip to the cloud it is uploading the whole audio clip instead of just the feature vector. The feature vector would be small in size compared to the whole audio clip which would save energy and bandwidth of the phone.

     4. Sanity check is performed for public space sound clips using outlier detection method. But this method doesn’t perform well when there is huge increase in the training data present.

    Discussion 

    1. Can edge devices such as Wi-Fi routers etc. can be used to process the sounds in the public domain? What could be advantages and challenges for such an approach?

    2. Can this framework be used for smart home applications?

    3. Since the processing is divided into stages, can we improve performance by offloading some of the computations like window level classification which takes up almost 90% of the time to a nearby edge device like desktop when at home?

    4. How feasible is it to extend the framework to adapt to different languages?