12-08-2014, 02:30 PM
Project Report On Social Cloud Computing: A Vision for Socially Motivated Resource Sharing
[attachment=66576]
Abstract
Online relationships in social networks are often based on real world relationships and can therefore be used to infer a level of trust between users. We propose leveraging these relationships to form a dynamic “Social Cloud,” thereby enabling users to share heterogeneous resources within the context of a social network. In addition, the inherent socially corrective mechanisms (incentives, disincentives) can be used to enable a cloud-based framework for long term sharing with lower privacy concerns and security overheads than are present in traditional cloud environments. Due to the unique nature of the Social Cloud, a social market place is proposed as a means of regulating sharing. The social market is novel, as it uses both social and economic protocols to facilitate trading. This paper defines Social Cloud computing, outlining various aspects of Social Clouds, and demonstrates the approach using a social storage cloud implementation in Facebook.
INTRODUCTION
DIGITAL relationships between individuals are becoming as important as their real world counterparts. For many people social networks provide a primary means of communication between friends, family, and coworkers. The increasing ubiquity of social network platforms is evidenced by their rapid and ongoing growth. For instance, Facebook has over 500 million active users of which
50 percent log on every day.1
Users are more likely to trust information from a “friend”
if the digital relationship between the two is based on a real world relationship (friend, family, colleague) rather than a purely online relationship (second life, online games, etc.). As relationships within online social networks are at least partly based on real-world relationships, we can therefore use them to infer a level of trust that underpins and transcends the online community in which they exist.
This implicit trust along with the application of socially corrective mechanisms (incentives, disincentives) inherent
SOCIAL CLOUD COMPUTING
The act of adding an individual as a social network “friend”
implies that a user has some degree of knowledge of the
individual being added. Such connectivity between indivi-
duals can be used to infer that a trust relationship exists
between them. However, it does not describe the level of
trust or the context of the relationship. For instance a
“friend” can be a member of the family, a work colleague,
a college affiliate, a member of the same sports club, etc.
Facebook has recently recognized the need for the
creation of such groups and allows users to differentiate
between, for example, close friends and colleagues. In a
Social Cloud, this provides the basis for defining different
levels of trust based on the group abstraction supported by
the infrastructure. For example, a user could limit sharing
with close friends only, friends in the same country,
network or group, all friends, or even friends of friends.
Another way of thinking about the Social Cloud is to
consider that social network groups are analogous to
dynamic Virtual Organizations (VOs) [1]. Groups, like
VOs, have policies that define the intent of the group,
the membership of the group, and sharing policies for the
group. This model is illustrated in Fig. 2, where user-
specific groups, defined by relationship types, are shown in
the context of a social network. In this example group A is
composed of only coworker members, whereas group B is
formed by family members and group C includes only
friends. Clearly the level of trust and mechanisms for social
correction (identifying incentives and disincentives for users
to participate) differ between groups. This figure also
highlights that Social Clouds are not mutually exclusive,
that is, users may be simultaneously members of multiple
Social Clouds. Whereas a VO is often associated with a
particular application or activity, and is often disbanded
once this activity completes, a group is longer lasting and
may be used in the context of multiple applications or
activities. We take this latter view, and use the formation of
social groups to support multiple activities.
Resource Trading
A Social Cloud resource represents a physical or virtual
entity (or capability) of limited availability. A resource
could therefore encompass people, information, computing
capacity, or software licenses—hence, a resource provides a
particular capability that is of use to other members of a
group or community. Resources shared in a Social Cloud
are by definition heterogeneous and potentially comple-
mentary, for example, one user may share storage in
exchange for access to a specific workflow. Or in another
example, a user may back up photos from their digital
Social Capital
Social capital represents an investment in social relation-ships with expected returns [9]. From an individual standpoint, social capital is similar to human capital in that users of a social network may gain individual returns for specific actions (e.g., selling goods or finding a new job). From a group perspective, social capital represents the intrinsic (intangible) value of the social community, that is, the community as a whole generates returns by the actions (or cooperation) of its members.
Provision of the Trading Infrastructure
The host infrastructure for a Social Cloud could be provisioned in multiple ways, for example, it could be provided externally (i.e., outsourced to an external vendor) or internally by the members themselves. Using an external provider is potentially easier, however it may be expensive and might not scale if a single market instance vendor is used for all groups. Supplying the infrastructure internally can more easily scale with the size of the group and it maps to the philosophy of social contribution inherent in a Social Cloud, however it requires a high degree of trust and cooperation between users.
A co-op is a business owned and operated by a community for the mutual benefit of the community (e.g., community managed grocery stores and credit unions). In a co-op customers using the business are also partial stake holders in the business, they therefore own the property, employ the workers, and have input into how the business is managed. A similar model is particularly apt when considering a Social Cloud. Due to the inherent social incentives the market itself can be hosted on resources contributed by members of the community, therefore establishing a Social Cloud co-op. This alleviates the expense involved in outsourcing the infrastructure and it
Storage as a Service
There are two generic requirements of the shared storage service: first, the interface needs to provide a mechanism to create a stateful instance for a reservation. In our model, the social storage cloud application passes a WS-Agreement [39]-based SLA to the service which is parsed and used to instantiate the required state. Second, in order to be discovered the service needs to advertise capacity so that it can be included in the market. In the social storage cloud this advertised capacity is encoded using XML-based metadata which is periodically refreshed and stored in a Globus Monitoring and Discovery System (MDS) [40]. The social storage cloud is based on a generic Web Services Resource Framework [41] (WSRF) storage service, which provides an interface for users to access virtualized storage. This service exposes a set of file manipulation operations to users and maps their actions to operations on the local file system. Users create storage by passing an agreement to the storage service, this creates a mapping between a user, an agreement, and the storage instance. Instances are identi-fied by a user and an agreement allowing individual users to have multiple storage instances in the same storage service. The storage service creates a representative WSRF resource and an associated working directory for each instance. The resource keeps track of service levels as outlined in the agreement such as the data storage limit. Additionally, the service has interfaces to list storage contents, retrieve the amount of storage used/available, upload, download, preview, and delete files.
Registration
The registration process is shown in Fig. 6. Upon joining the cloud users first need to register themselves, and then specify the cloud services they are willing to trade. As users are preauthenticated through Facebook, user in-stances can be transparently created in the banking service using the user’s Facebook ID. Having registered, the user is presented with an MDS EndPoint Reference (EPR) and cloud ID which they use to configure their cloud services for registration (and refreshment) of resource capacity. Market services utilize the MDS XPath interface to discover suitable services based on user IDs and real-time capacity. The service updates its metadata whenever resource state changes, this update is reflected in MDS according to the application policies.
CPU Usage
Fig. 12 shows the CPU usage of each service for the duration of the sample workload. As the number of requests submitted increases the peak CPU usage of all services and the duration of usage increases. The order of events between services is evident in the graph: as requests are submitted the CPU usage of the AM peaks, which in turn generates work for MDS (to discover bidders) and the Storage Service BA (computing a bid). After the auction period of 30 seconds has elapsed the AM computes a winner and the AgM creates an SLA. As the AgM is operating there is an additional peak in the AM due to result retrieval and the computation of substitute providers. The CPU usage of the AM and AgM use up to 80 percent capacity of the test machine (when 50 simultaneous
Summary
The CPU and memory footprint of the core market services was shown to be relatively low and generally short duration for up to 50 simultaneous auctions. The AM exhibited the highest overhead, utilizing almost 100 percent CPU for 10 seconds and 125 MB of RAM with 50 concurrent auctions and 20 bidders, however this scenario represents a worst case scenario when all auctions are started concurrently. For a moderately sized Social Cloud one would expect to host far fewer auctions over a much longer timespan which would therefore utilize less resources for shorter periods of time, in addition the WSRF resource lifetime would ensure memory usage is reduced periodically. The posted priced market was shown to require negligible resources
REFLECTIVE ANALYSIS
The social storage cloud provides a first step toward realizing the vision of Social Cloud computing. In parti-cular, it provides an integrated platform on which social network friends can trade a single resource (storage) with one another using a credit model. The cloud model was shown to be well suited to this type of scenario as users are able to lease capacity through standardized service-based interfaces using an abstracted virtualized resource layer. This section discusses how the social storage cloud fulfils the high-level vision of Social Cloud computing.
The relationships and policies represented in the social storage cloud are one dimensional, in that all friends are treated equally. At present all users belong to the same group and there is no ability to define different sharing policies based on relationship type. The architecture is able to select users based on their friend relationship and could be extended to retrieve users based on their group membership or relationship type. The evaluation showed the cost of friend selection in MDS to be low for moderately sized Social Clouds. Simple policies are supported in the auction scenario to alter the bid price based on the identity of the requester.
CONCLUSION
This paper has presented the vision of Social Cloud computing, an amalgamation of cloud computing and social networking. A Social Cloud is unique in that it builds upon the social incentives and external real-world relationships inherent in social networks to provide heterogeneous resource trading. This work represents a novel approach to collaborative computing utilizing so-cially corrective mechanisms to motivate contribution and compliance without requiring extensive incentive and enforcement architectures.
A Facebook-based social storage cloud has been devel-oped and deployed. The social storage cloud supports storage trading through a two protocol social marketplace. The integrated social storage Facebook application allows users to discover and trade storage contributed by their friends, taking advantage of preexisting trust relationships. A credit-based trading approach has been adopted to discourage free loading.
It was shown empirically that the marketplaces used for trading and/or reciprocation of services could be hosted using small scale resources, based upon the observation that individual groups are small in size (averaging 130 individuals). In addition, it was shown even under load, the system can perform multiple concurrent auctions that would satisfy the requirements for a moderately sized social network. Finally, the overhead of the Social Cloud services was shown to be small under realistic load conditions, thereby verifying the assertion that a co-op model can be employed to enable a scalable self-contained Social Cloud.
[attachment=66576]
Abstract
Online relationships in social networks are often based on real world relationships and can therefore be used to infer a level of trust between users. We propose leveraging these relationships to form a dynamic “Social Cloud,” thereby enabling users to share heterogeneous resources within the context of a social network. In addition, the inherent socially corrective mechanisms (incentives, disincentives) can be used to enable a cloud-based framework for long term sharing with lower privacy concerns and security overheads than are present in traditional cloud environments. Due to the unique nature of the Social Cloud, a social market place is proposed as a means of regulating sharing. The social market is novel, as it uses both social and economic protocols to facilitate trading. This paper defines Social Cloud computing, outlining various aspects of Social Clouds, and demonstrates the approach using a social storage cloud implementation in Facebook.
INTRODUCTION
DIGITAL relationships between individuals are becoming as important as their real world counterparts. For many people social networks provide a primary means of communication between friends, family, and coworkers. The increasing ubiquity of social network platforms is evidenced by their rapid and ongoing growth. For instance, Facebook has over 500 million active users of which
50 percent log on every day.1
Users are more likely to trust information from a “friend”
if the digital relationship between the two is based on a real world relationship (friend, family, colleague) rather than a purely online relationship (second life, online games, etc.). As relationships within online social networks are at least partly based on real-world relationships, we can therefore use them to infer a level of trust that underpins and transcends the online community in which they exist.
This implicit trust along with the application of socially corrective mechanisms (incentives, disincentives) inherent
SOCIAL CLOUD COMPUTING
The act of adding an individual as a social network “friend”
implies that a user has some degree of knowledge of the
individual being added. Such connectivity between indivi-
duals can be used to infer that a trust relationship exists
between them. However, it does not describe the level of
trust or the context of the relationship. For instance a
“friend” can be a member of the family, a work colleague,
a college affiliate, a member of the same sports club, etc.
Facebook has recently recognized the need for the
creation of such groups and allows users to differentiate
between, for example, close friends and colleagues. In a
Social Cloud, this provides the basis for defining different
levels of trust based on the group abstraction supported by
the infrastructure. For example, a user could limit sharing
with close friends only, friends in the same country,
network or group, all friends, or even friends of friends.
Another way of thinking about the Social Cloud is to
consider that social network groups are analogous to
dynamic Virtual Organizations (VOs) [1]. Groups, like
VOs, have policies that define the intent of the group,
the membership of the group, and sharing policies for the
group. This model is illustrated in Fig. 2, where user-
specific groups, defined by relationship types, are shown in
the context of a social network. In this example group A is
composed of only coworker members, whereas group B is
formed by family members and group C includes only
friends. Clearly the level of trust and mechanisms for social
correction (identifying incentives and disincentives for users
to participate) differ between groups. This figure also
highlights that Social Clouds are not mutually exclusive,
that is, users may be simultaneously members of multiple
Social Clouds. Whereas a VO is often associated with a
particular application or activity, and is often disbanded
once this activity completes, a group is longer lasting and
may be used in the context of multiple applications or
activities. We take this latter view, and use the formation of
social groups to support multiple activities.
Resource Trading
A Social Cloud resource represents a physical or virtual
entity (or capability) of limited availability. A resource
could therefore encompass people, information, computing
capacity, or software licenses—hence, a resource provides a
particular capability that is of use to other members of a
group or community. Resources shared in a Social Cloud
are by definition heterogeneous and potentially comple-
mentary, for example, one user may share storage in
exchange for access to a specific workflow. Or in another
example, a user may back up photos from their digital
Social Capital
Social capital represents an investment in social relation-ships with expected returns [9]. From an individual standpoint, social capital is similar to human capital in that users of a social network may gain individual returns for specific actions (e.g., selling goods or finding a new job). From a group perspective, social capital represents the intrinsic (intangible) value of the social community, that is, the community as a whole generates returns by the actions (or cooperation) of its members.
Provision of the Trading Infrastructure
The host infrastructure for a Social Cloud could be provisioned in multiple ways, for example, it could be provided externally (i.e., outsourced to an external vendor) or internally by the members themselves. Using an external provider is potentially easier, however it may be expensive and might not scale if a single market instance vendor is used for all groups. Supplying the infrastructure internally can more easily scale with the size of the group and it maps to the philosophy of social contribution inherent in a Social Cloud, however it requires a high degree of trust and cooperation between users.
A co-op is a business owned and operated by a community for the mutual benefit of the community (e.g., community managed grocery stores and credit unions). In a co-op customers using the business are also partial stake holders in the business, they therefore own the property, employ the workers, and have input into how the business is managed. A similar model is particularly apt when considering a Social Cloud. Due to the inherent social incentives the market itself can be hosted on resources contributed by members of the community, therefore establishing a Social Cloud co-op. This alleviates the expense involved in outsourcing the infrastructure and it
Storage as a Service
There are two generic requirements of the shared storage service: first, the interface needs to provide a mechanism to create a stateful instance for a reservation. In our model, the social storage cloud application passes a WS-Agreement [39]-based SLA to the service which is parsed and used to instantiate the required state. Second, in order to be discovered the service needs to advertise capacity so that it can be included in the market. In the social storage cloud this advertised capacity is encoded using XML-based metadata which is periodically refreshed and stored in a Globus Monitoring and Discovery System (MDS) [40]. The social storage cloud is based on a generic Web Services Resource Framework [41] (WSRF) storage service, which provides an interface for users to access virtualized storage. This service exposes a set of file manipulation operations to users and maps their actions to operations on the local file system. Users create storage by passing an agreement to the storage service, this creates a mapping between a user, an agreement, and the storage instance. Instances are identi-fied by a user and an agreement allowing individual users to have multiple storage instances in the same storage service. The storage service creates a representative WSRF resource and an associated working directory for each instance. The resource keeps track of service levels as outlined in the agreement such as the data storage limit. Additionally, the service has interfaces to list storage contents, retrieve the amount of storage used/available, upload, download, preview, and delete files.
Registration
The registration process is shown in Fig. 6. Upon joining the cloud users first need to register themselves, and then specify the cloud services they are willing to trade. As users are preauthenticated through Facebook, user in-stances can be transparently created in the banking service using the user’s Facebook ID. Having registered, the user is presented with an MDS EndPoint Reference (EPR) and cloud ID which they use to configure their cloud services for registration (and refreshment) of resource capacity. Market services utilize the MDS XPath interface to discover suitable services based on user IDs and real-time capacity. The service updates its metadata whenever resource state changes, this update is reflected in MDS according to the application policies.
CPU Usage
Fig. 12 shows the CPU usage of each service for the duration of the sample workload. As the number of requests submitted increases the peak CPU usage of all services and the duration of usage increases. The order of events between services is evident in the graph: as requests are submitted the CPU usage of the AM peaks, which in turn generates work for MDS (to discover bidders) and the Storage Service BA (computing a bid). After the auction period of 30 seconds has elapsed the AM computes a winner and the AgM creates an SLA. As the AgM is operating there is an additional peak in the AM due to result retrieval and the computation of substitute providers. The CPU usage of the AM and AgM use up to 80 percent capacity of the test machine (when 50 simultaneous
Summary
The CPU and memory footprint of the core market services was shown to be relatively low and generally short duration for up to 50 simultaneous auctions. The AM exhibited the highest overhead, utilizing almost 100 percent CPU for 10 seconds and 125 MB of RAM with 50 concurrent auctions and 20 bidders, however this scenario represents a worst case scenario when all auctions are started concurrently. For a moderately sized Social Cloud one would expect to host far fewer auctions over a much longer timespan which would therefore utilize less resources for shorter periods of time, in addition the WSRF resource lifetime would ensure memory usage is reduced periodically. The posted priced market was shown to require negligible resources
REFLECTIVE ANALYSIS
The social storage cloud provides a first step toward realizing the vision of Social Cloud computing. In parti-cular, it provides an integrated platform on which social network friends can trade a single resource (storage) with one another using a credit model. The cloud model was shown to be well suited to this type of scenario as users are able to lease capacity through standardized service-based interfaces using an abstracted virtualized resource layer. This section discusses how the social storage cloud fulfils the high-level vision of Social Cloud computing.
The relationships and policies represented in the social storage cloud are one dimensional, in that all friends are treated equally. At present all users belong to the same group and there is no ability to define different sharing policies based on relationship type. The architecture is able to select users based on their friend relationship and could be extended to retrieve users based on their group membership or relationship type. The evaluation showed the cost of friend selection in MDS to be low for moderately sized Social Clouds. Simple policies are supported in the auction scenario to alter the bid price based on the identity of the requester.
CONCLUSION
This paper has presented the vision of Social Cloud computing, an amalgamation of cloud computing and social networking. A Social Cloud is unique in that it builds upon the social incentives and external real-world relationships inherent in social networks to provide heterogeneous resource trading. This work represents a novel approach to collaborative computing utilizing so-cially corrective mechanisms to motivate contribution and compliance without requiring extensive incentive and enforcement architectures.
A Facebook-based social storage cloud has been devel-oped and deployed. The social storage cloud supports storage trading through a two protocol social marketplace. The integrated social storage Facebook application allows users to discover and trade storage contributed by their friends, taking advantage of preexisting trust relationships. A credit-based trading approach has been adopted to discourage free loading.
It was shown empirically that the marketplaces used for trading and/or reciprocation of services could be hosted using small scale resources, based upon the observation that individual groups are small in size (averaging 130 individuals). In addition, it was shown even under load, the system can perform multiple concurrent auctions that would satisfy the requirements for a moderately sized social network. Finally, the overhead of the Social Cloud services was shown to be small under realistic load conditions, thereby verifying the assertion that a co-op model can be employed to enable a scalable self-contained Social Cloud.