A Game-theoretic Framework for Revenue Sharing in Edge-Cloud Computing System

11/28/2017 ∙ by Zhi Cao, et al. ∙ UMass Lowell University of Massachusetts-Boston 0

We introduce a game-theoretic framework to ex- plore revenue sharing in an Edge-Cloud computing system, in which computing service providers at the edge of the Internet (edge providers) and computing service providers at the cloud (cloud providers) co-exist and collectively provide computing resources to clients (e.g., end users or applications) at the edge. Different from traditional cloud computing, the providers in an Edge-Cloud system are independent and self-interested. To achieve high system-level efficiency, the manager of the system adopts a task distribution mechanism to maximize the total revenue received from clients and also adopts a revenue sharing mechanism to split the received revenue among computing servers (and hence service providers). Under those system-level mechanisms, service providers attempt to game with the system in order to maximize their own utilities, by strategically allocating their resources (e.g., computing servers). Our framework models the competition among the providers in an Edge-Cloud system as a non-cooperative game. Our simulations and experiments on an emulation system have shown the existence of Nash equilibrium in such a game. We find that revenue sharing mechanisms have a significant impact on the system-level efficiency at Nash equilibria, and surprisingly the revenue sharing mechanism based directly on actual contributions can result in significantly worse system efficiency than Shapley value sharing mechanism and Ortmann proportional sharing mechanism. Our framework provides an effective economics approach to understanding and designing efficient Edge-Cloud computing systems.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Edge computing [1, 2, 3, 4, 5, 6, 7] is an emerging computing paradigm that is transforming the landscape of provision and consumption of computing services for a wide range of applications and end users at the edge of the Internet. This paradigm will be particularly helpful to those latency-sensitive and bandwidth-hungry (due to a large amount of data) applications brought by Internet of Things (IoT) systems.

In this paper, we are interested in a hybrid system where computing service providers at the edge of the Internet (referred to as edge providers, which are close to IoT sensors, mobile devices, and end users) and the providers at the cloud (referred to as cloud providers) co-exist and collectively provide computing services to the clients at the edge. Such a system is referred to as an Edge-Cloud system. Different from a traditional cloud computing environment in which all servers are organized in data centers and tightly controlled and managed by a provider, the various providers that offer computing servers in an Edge-Cloud system are independent and located at various distances away from clients, and they can make independent decisions on the computation resources that they provide to the system.

In order to achieve a high system-level efficiency, an Edge-Cloud system adopts a task distribution mechanism to maximize the total revenue received from clients, and it adopts a revenue sharing mechanism to fairly split its received revenue among computing servers (and hence service providers). Under any given system-level mechanism, the providers are likely to compete with each other and game with the system in order to maximize their own utilities by strategically adjusting the resources that they offer to the system.

The self-interested behaviors of those providers might result in an inefficient system with low overall performance, as their individual self-interested objectives (a provider tries to maximize its own utility) do not collectively align with the system-wide objective (i.e., to maximize the overall system utility). Therefore, it is important to choose a system-level mechanism that will minimize the loss of system-wide efficiency in the face of the self-interested behaviors of the providers. To that end, we introduce a game-theoretic framework to investigate the impact of revenue sharing mechanisms on an Edge-Cloud system’s overall efficiency. To demonstrate the effectiveness of the framework, we have conducted extensive simulations and experiments on an edge-computing emulation system.

Our major contributions are summarized below.

  1. We introduce a game-theoretic framework to investigate an Edge-Cloud hybrid computing system of edge providers and cloud providers offering their computing resources to clients at the edge. To the best of our knowledge, our work is the first to investigate such a problem from an economics and game-theoretic perspective. Our findings demonstrate that it is crucially important to design an appropriate revenue sharing mechanism in order to maintain high system-level efficiency in the face of service providers’ self-interested behaviors.

  2. We demonstrate the existence of Nash equilibrium in the game between edge and cloud providers, under three revenue sharing mechanisms (Shapley value sharing [8], Ortmann proportional sharing [9], and Direct-contribution-based sharing), and across a wide range of system/networking settings. We find that when the servers from different providers have quite different capacities (e.g., the transmission bandwidth between clients and servers), different revenue sharing mechanisms can result in drastically different system-level utility loss at equilibria when compared with maximum system utility (which is achieved when providers do not game with the system).

  3. Our results show that at the Nash equilibria of the game, Direct-contribution-based sharing (i.e., revenue split based directly on actual contributions of servers) results in the worst system-level utility. This seemingly counter-intuitive result is not surprising, as under Direct-contribution-based sharing, a provider with very low transmission bandwidth keeps placing many servers in the system (as it is rewarded directly based on its actual contribution) even when doing so actually hurts the overall system performance. On the other hand, Shapley mechanism gives the least utility loss in most cases, and Ortmann mechanism’s utility loss is close to Shapley’s. This is because Shapley mechanism and Ortmann mechanism discourage a low bandwidth provider from offering many servers by setting its revenue share as a decreasing function of its number of servers placed in the system.

  4. We demonstrate that our framework is a valid and effective economics approach to understanding and designing efficient Edge-Cloud computing systems, based on our extensive simulations driven by the empirical data derived from our experiments on an emulation system we have developed and from Google cloud trace [10].

In the rest of the paper, we first present the architecture of an Edge-Cloud system and give an overview of our game-theoretic framework in Section II. Then in Sections III and IV, we describe task distribution mechanisms and revenue sharing mechanisms. Section V presents our findings via experiments and simulations, and we conclude the paper in Section VI.

Ii Edge-Cloud system

In this section, we first discuss background and related work, and then we give an overview of an Edge-Cloud system.

Ii-a Background and Related Work

This paper studies a computing system in the emerging edge computing paradigm, which broadly includes cloudlets, mobile edge computing, fog computing, fog networks, and mobile cloud computing [1, 2, 3, 4, 5, 6, 7]. Besides the low latency benefit of edge computing, recent research on Internet of Things (IoT) has shown that, by processing at the edge the large amount of raw data collected by IoT sensors (e.g., in a smart home or smart city system) or human users (e.g., videos, pictures taken by smartphones), edge computing can significantly reduce the consumption of network bandwidth in wide area and core networks when compared with transferring raw data to a cloud [11, 12]. ATT, a large Internet service provider, has recently announced plans to deploy edge computing servers in their mobile access towers on a large scale [13]

. The economics and game-theoretic approach adopted in this paper is related to the existing rich literature of applying economics and game theory in networking research

[14, 15, 16, 17].

Ii-B System Architecture Overview

There are three types of entities in an Edge-Cloud system, as shown in Figure 1. (1) Clients, including applications and end users, that are at the edge of the Internet and submit computing tasks to the system. (2) Edge providers (computing service providers at the edge of the Internet and close to clients, and hence have high communication bandwidth and low propagation delay to clients), and cloud providers (providers in the cloud that offer servers to edge clients by joining an Edge-Cloud system). (3) A system manager, which is a software component that implements mechanisms/algorithms for various management issues such as facilitating task submissions, revenue collection from clients, revenue split among servers, accounting/auditing, etc. The main part of the manager resides on the edge and some of its components are distributed among providers throughout the Internet. In the system, clients communicate with and submit their tasks to the system manager through apps on their devices.

Fig. 1: System architecture. Computing service providers compete with each other under system-level mechanisms: task distribution and revenue sharing.

In an Edge-Cloud system, a monetary value is associated with each task. A system manager’s objective is to maximize its total values or revenue received from clients via a task distribution mechanism that optimally assigns tasks to servers subject to the latency requirements of those tasks. Based on the revenue collected and the tasks completed by the servers, the manager utilizes a revenue sharing mechanism to split the received revenue among the servers (and hence between the service providers who own those servers). Therefore, an Edge-Cloud system has two basic types of mechanisms: a task distribution mechanism and a revenue sharing mechanism. In this paper, we investigate three types of revenue sharing mechanisms: Shapley value sharing [8], Ortmann proportional sharing [9], and Direct-contribution-based sharing. They will be discussed in detail in Sections III and IV.

Ii-C A Game-theoretic Framework for an Edge-Cloud System

Ii-C1 Assumptions

We assume that each service provider in an Edge-Cloud system is independent and self-interested. This assumption describes an important characteristic of an Edge-Cloud system: a service provider can choose to join an Edge-Cloud system and decides by itself the amount of computing resources it offers to the system. This characteristic differentiates an Edge-Cloud system from a traditional cloud computing system in which all computing resources are centrally managed and tightly controlled by an entity and they are typically placed in data centers. A traditional cloud computing provider can also join an Edge-Cloud system and offer service to the clients in the system, and such a cloud provider is treated equally as other edge providers in the same system.

We assume that the two types of mechanisms (i.e., task distribution and revenue sharing) work on individual servers, without any consideration of the identities of the owners (i.e., providers) of those servers, as the objectives of those system-level mechanisms are to optimally utilize available servers to maximize total received revenue and fairly distribute the revenue111A system manager may keep a share of the total received revenue and split the rest among servers. We assume that a system manager’s own revenue share is negligible compared with the rest of the revenue given to servers. among participating servers. Those mechanisms are publicly known to all clients and service providers. Under those mechanisms, a service provider attempts to maximize its received benefit or utility (defined below) by strategically adjusting the computing resources it provides to the system.

Ii-C2 The game

We model the competition among service providers in an Edge-Cloud system as a non-cooperative game [18], and the providers are players in the game. We focus on the case where a provider’s available strategy is to adjust the number of servers it offers to the system in order to maximize its utility. A utility function captures the tradeoff between the revenue and the cost of a provider. Providing more servers will incur more cost to a provider, even though more servers imply more revenue that the provider can potentially receive. Then the utility function of a provider can be described as

(1)

where is the revenue received by provider when placing servers in the system, and the cost is an increasing function of the number of servers. We focus on a linear cost function with .

Now we define a Nash equilibrium [18] for the game we study through a game of two players: an edge provider and a cloud provider . Let and denote the revenue received by the edge player and the cloud player respectively. Let and denote a task distribution mechanism and a revenue sharing mechanism respectively. Then we know is a function of and . Note that is a function of , i.e., the number of servers provided by the edge player and the cloud player respectively, given that they work on a certain set of tasks.

The edge player and the cloud player attempt to solve the following optimization problems respectively

A Nash equilibrium [18] of the game is a particular combination of players’ strategies from which a player has no incentive to unilaterally deviate (i.e., does not change its number of servers, given that the other player’s number of servers remains unchanged), as any unilateral deviation will not increase its utility. The Nash equilibrium is denoted by

(2)

where and . Note that the definition (2) can be easily generalized to the definition of a Nash equilibrium of a -player game: with (where denotes the set of all players except ).

Iii Mechanism for Distributing Computing Tasks

In this section, we discuss mechanisms that distribute tasks of edge clients to the servers in an Edge-Cloud system.

Iii-a Objective of task distribution

Since an important application of edge computing is to serve tasks with low latency requirement, we focus on tasks with completion deadlines. Recall that a task has a value, which can be regarded as the payment that the task’s owner (i.e., a client) is willing to pay for completing the task. The objective of a task distribution mechanism is to maximize the total received value (as a revenue) for the tasks that are completed before their deadlines. In this section, we present an optimization formulation for the case where tasks arrive in a batch (i.e., at the same time) to illustrate the characteristic of task distribution, and then we will present a greedy algorithm to address a practical dynamic task arrival setting.

Iii-B Optimal Task Distribution Formulation

Iii-B1 Batch task arrival

A system manager distributes all tasks arriving in a batch to servers by solving an optimization problem to maximize the total received revenue from those completed tasks. We assume that the execution order of those tasks on a server should be the same as the order of their arrivals. We also assume that tasks are not splittable.

Let denote the set of tasks with , and let denote the set of servers with . Tasks are ordered increasingly according to their arrival times and indexed by , and servers are indexed by . Let denote the assignment of task to server . Then represents that task is assigned to server ; otherwise . Let denote the completion time of task when it is assigned to server . Note that includes the computation time of task on server and the time to transfer task to server . In addition, a task might experience a queuing delay if some other tasks are scheduled on the same sever (as task ) but should be executed before task as they arrive earlier than task . Queuing delay is discussed next.

Let denote the value of task or the payment that the owner (i.e., client) of task will pay for completing task . If task is completed before its deadline, the system manager will receive ; otherwise, the manager receives nothing. The objective of the manager is to maximize its total received payment or value (as a revenue) by solving the following optimization problem.

(3)
(4)
(5)
(6)
(7)
(8)
(9)

where (4) and (5) say that a task can be assigned to at most one server. The three constraints (6), (7), and (8) collectively say that when assigned to server , task should be completed no later than its deadline (i.e., the maximum allowed latency ). Task ’s total delay on server is given by , as shown in (6). The two constraints (7) and (8) indicate that is equivalent to . Note that (7) and (8) are called indicator constraints in CPLEX solver [19]. The represents the queuing delay of task if it is assigned to server . Recall that the tasks are served in a first-come first-serve order. If task arriving before task (with ) is also assigned to server , then task has to wait till task is finished. The queuing delay of task on server only makes sense when task is assigned to server . Therefore, (7) says that when task is not assigned to server , its queuing delay constraint (6) on server should be removed.

Iii-B2 Dynamic task arrival

The above optimization formulation for batch arrival of tasks illustrates the nature of the optimization problem to be solved by an Edge-Cloud system’s manager, but it is difficult to implement in practice. This is because usually tasks arrive in a dynamic fashion, and since they have deadlines, they need to be sent to available servers immediately in order to meet their latency requirements.

To address the case of dynamic task arrival, we introduce an online greedy algorithm (shown as Algorithm 1) to be used by a system manager to maximize its total received revenue. The idea of the algorithm is: whenever a server is available, it should be given the task with the highest value among all tasks that are present in the system and can be completed before their deadlines by the server.

If all tasks arrive at time , then Algorithm 1

is essentially a heuristic to solve the optimization problem (

3) formulated for the batch task arrival case. In addition, if a task’s value is inversely proportional to its deadline, then Algorithm 1 is a type of earliest-deadline-first scheduling algorithm, but without preemptive scheduling. In an Edge-Cloud system, a server cannot suspend the execution of a task in order to execute some other task with higher priority, due to the non-negligible communication cost/delay in edge computing environment. Both batch arrival and dynamic arrival of tasks will be investigated in Section V.

0:  , where is the time period during which the algorithm executes, and is a set of tasks and their arrival times during , and is a server set.
1:  , ( is a priority queue where the task with the highest value is at the front of ).
2:  while  do
3:     If a task arrives at time , insert it into :
4:        If multiple tasks have the same value, order them according to their arrival time order.
5:     If a set of servers are available at time (denoted by ), use a loop to select all servers one at a time and in random order from , and for each selected server :
6:        Start from the front of , search for the task with the highest value among all tasks that can be finished before their deadlines if processed by . Let denote such a task.
7:           If is found, stop search and start a new thread for to work on .
8:  end while
Algorithm 1 Online Greedy Task Distribution Algorithm

Iv Mechanisms for revenue sharing

In this section, we investigate the following three revenue sharing mechanisms: (1) Shapley value [8]; (2) A proportional sharing mechanism proposed by Ortmann [9], referred to as Ortmann proportional sharing; (3) and a sharing mechanism based directly on each server’s actual contribution, referred to as Direct-contribution-based sharing mechanism.

Iv-a Shapley-value revenue sharing mechanism

Shapley value [8] is a well-known revenue sharing mechanism. For an Edge-Cloud system, Shapley value defines a function that distributes among a set of servers the total revenue received by the system in organizing the servers to work on a set of tasks. It specifies that the revenue a server receives equals the server’s expected marginal contribution.

Formally, consider a set of tasks , and a set of servers (with ). Note that a server can be owned by a cloud provider or an edge provider. Define the value of set , denoted by , as the total received value by only using servers in set (with ) to work on the tasks in . Note that is a function of task distribution mechanism. Let denote the revenue share given to server . The Shapley value mechanism assigns the following revenue share to server :

(10)

This revenue distribution mechanism satisfies the following desired property [8, 20, 15, 21]: fairness or balanced contribution, which says that for any pair of servers , ’s contribution to equals ’s contribution to , i.e., . Shapley value sharing mechanism also has some other important properties such as efficiency (the sum of revenue shares distributed to all servers equals the total received revenue) and symmetry.

Iv-A1 Computing Shapley values

The amount of time to compute Shapley values for all servers in a game is exponential, if the computation is done according to the definition in Equation (10). However, we are able to derive a polynomial time algorithm, shown as Algorithm 2, based on the following assumptions. The servers in a system can be divided into groups, which belong to different providers. For ease of exposition, assume that a provider has one and exactly one group. Further we assume that the servers in a group or provider are identical (in terms of CPU, path bandwidth, and propagation delay) as they are offered by the same provider. Then the Shapley values for all servers in a provider should be the same. Therefore for provider , we just need to calculate a Shapley value , where is an arbitrary server in the set of servers of provider (denoted by ), i.e., . Then, provider ’s revenue is , with .

0:  Task set ; Server set , where is the set of servers of provider , , , .
1:  for  do
2:     Initialize .
3:     for ;  do
4:        Do a level nested loop to find all combinations , where each number (with ) varies from to .
5:        For each , do:
6:           Invoke a task distribution algorithm (e.g., Algorithm 1) for task set to calculate two values and :
7:           , i.e., the value of the set that contains servers from provider , with .
8:           . (Similar to , except that is used for provider ).
9:           Calculate . (Note that is used for provider ).
10:           Let .
11:           Calculate .
12:           Increase by .
13:     end for
14:     Record (Shapley value of a server in provider ).
15:  end for
16:  Return Shapley value , with . (All servers in a provider have the same Shapley value.)
Algorithm 2 Compute the Shapley value of each server of providers in an Edge-Cloud system.

An example of computing Shapley values. We use a simple example of two providers to illustrate Algorithm 2. Consider a cloud provider that offers two cloud servers , and an edge provider that offers three edge servers , , and in an Edge-Cloud system. According to equation (10), in order to derive the Shapley value of , we need to find the values of sets and . There are such sets (including the empty set). Due to space limitations, they are not listed here.

However, all three edge servers can be treated as equivalent, and both cloud servers are also equivalent. For example, the value of set equals the values of sets , , and . Therefore, to calculate the Shapley value of cloud server , we only need to calculate the values of the following eleven sets , , , , , , , , , , , based on Algorithm 2.

Iv-A2 Time complexity of Algorithm 2

Consider a system of two providers, in which an edge provider has a set of servers , and a cloud provider has a set of servers . All cloud servers are equivalent, and all edge servers are equivalent. Suppose we would like to apply Algorithm 2 to calculate the Shapley value of a particular edge server . For any two subsets and that do not contain , we have and , if the number of edge servers in equals the number of edge servers in , and the number of cloud servers in equals the number of cloud servers in . Then, we only need to calculate the values of sets. This is because, for a set listed in the Shapley value formula (10), the set might contain a number of edge servers and the number can be ; similarly, the set might contain a number of cloud servers and the number can be . Thus the total number of the unique sets is , where the “-1” is for removing the value calculation for the empty set which is always zero. Therefore, the time complexity of Algorithm 2 is . In general, if there are providers which have servers, the time complexity of Algorithm 2 is .

Iv-B Direct-contribution-based and Ortmann proportional sharing mechanisms

The idea of Direct-contribution-based sharing is simple. A server is rewarded with a share of revenue that is proportional to the actual contribution that it has made when working together with other servers to complete a set of tasks. In the case where a system manager distributes all of its received revenue among participating servers (i.e., with no revenue share left for itself), the amount of revenue that a server receives is exactly the same amount of payment given by the clients whose tasks are completed by the server.

Ortmann proportional sharing [9] is a sharing mechanism that is similar to Shapley value, in the sense that it also relies on some calculation of the marginal contribution of a server, instead of relying directly on the server’s actual contribution. For example, for a system with only two servers and , according to Ortmann proportional sharing, the revenue received by server should be , where is the revenue or value generated by the system when it only contains server , and is the revenue generated by the system when it contains servers and . For a formal definition of Ortmann proportional sharing, see [9].

Note that Ortmann proportional sharing also has a balanced contribution property, but it differs from Shapley value’s balanced contribution in the following sense. Under Ortmann sharing, for any pair of servers , ’s contribution to equals ’s contribution to in terms of quotient, i.e., . That is, Ortmann’s balanced contribution property is in the form of ratio equality instead of the difference equality of Shapley’s. For example, consider a system of two players and . Let , , and . Based on Shapley value sharing, they will get and ; based on Ortmann proportional sharing, they will get and . The Shapley value sharing satisfies , but Ortmann proportional sharing satisfies .

V Impact of Revenue Sharing Mechanisms on System Performance

We discuss in this section the impact of revenue sharing mechanisms on the performance of an Edge-Cloud system. Our investigation is mainly conducted through a combination of emulations and simulations222Due to resource constraints, it is impossible for us to conduct Internet-scale experiments. Therefore we mainly rely on simulations with system parameters derived from our experiments and empirical trace..

V-a Edge-Cloud emulation system

We have built an experimental system to emulate an Edge-Cloud system, and based on which we have conducted experiments to derive system parameters to drive our simulations. The system consists of a pool of edge clients (on a number of Raspberry Pi’s [22] and Ubuntu laptops), a system manager (a distributed software component), and a pool of servers (on a number of Ubuntu workstations), as shown in Figure 2. A client at the edge submits its computation tasks to the manager at the edge who schedules and dispatches received tasks to servers. There are two types of servers in the system: edge servers and cloud servers, which respectively belong to edge service providers and cloud service providers. The edge servers have higher bandwidth and shorter propagation delays (on the paths between them and clients) than the cloud servers. Once a server receives a task, a Docker container [23] will be launched on the server to process the task. Once the task is completed, the server will notify the manager and sends back the result of the task to the edge client. The communication between the clients, the manager, and the servers is through Web Application Messaging Protocol (WAMP) [24], a real-time messaging protocol.

Fig. 2: Edge-Cloud emulation system.

V-B Determining Simulation Parameters

We utilize image processing (a typical edge computing application) in our simulations to investigate the impact of revenue sharing mechanisms. In this subsection, we discuss how to derive system parameters used in our simulations.

We focus on an object detection application, i.e., a client’s task is to detect whether a specific object appears in a collection of images. The client submits a collection of images including the image of the target object and a number of candidate images in a batch to the system, and then the system assigns the task to a server. The server launches a Docker container [23] to process the images using OpenCV [25].

A simulation run is characterized by a group of system parameters:

(11)

where is the system time duration we simulate, denotes the set of tasks and their arrival times during , denotes the set of servers, denotes task arrival rate, denotes the function to calculate the completion time of a task, denotes a latency factor, and denotes a bandwidth factor. These parameters are discussed below.

In our simulations, we let the size of a task be a uniform random number in range MB. We can think of this task size in the context of an object detection application as follows. The average task size MB (in our simulations) roughly corresponds to a batch of images with a regular image size (about MB on a typical smartphone). The average task size also roughly corresponds to a collection of images from the Microsoft COCO image dataset [26] with an average image size of KB. The value of a task is a number chosen uniformly at random from range .

We assume that tasks arrive at the system in a Poisson process with rate (number of tasks per minute). Poisson process is a typical stochastic process used in modeling job arrival process. We choose in our simulations, which is the average job arrival rate in Google cloud trace [10].

The completion time of a task on a server depends on the server’s CPU and bandwidth (of the path between itself and clients). Through our experiments on the emulation system, we find that for the object detection application, the computation time of processing a batch of images is linearly proportional to the size of the batch. For example, we tested a server in our experiments, which was a Dell mobile workstation with Intel Core GHz, cores CPU, and GB memory. We randomly selected images from Microsoft COCO image database [26] and then ran the object detection application with OpenCV. Each experimental setting was repeated times. We choose , and for each value and each experiment replicate, we recorded the total size of the batch of images. Let (sec) denote the computation time of processing a batch of images of MB. A plot of vs.

shows a strong linear relationship between them, and a linear regression analysis shows that

. We will utilize this function to calculate the computation time of a task in our simulations reported in the rest of this section.

A task has a latency requirement, denoted by (i.e., the maximum allowed delay). It is determined as follows. Let denote the amount of time to complete task on an average server (i.e., a server with an average CPU power and average bandwidth to clients in the system) without considering any queuing delay (i.e., waiting for other tasks to be completed on the same server). Note that includes computation time and task transmission time. Assume that the average upload bandwidth of the paths from clients to servers is Mbps, and assume that an average server has a CPU similar to the one used in our experiments described above. Then, sec, where is task ’s size (MB), and the average propagation delay is negligible compared with computation and transmission delays. In our experiments, we let the bandwidth from a client to an edge server be Mbps (i.e., a WiFi environment), and then we let the bandwidth from a client to a cloud server be Mbps, where bandwidth factor , and model the practice where a cloud server usually has lower bandwidth to clients than an edge server. In calculating , we do not consider the time to transfer results back to clients as the sizes of the results are very small and negligible. Then, we let be a number chosen uniformly at random from range , where latency factor . The rationale of choosing such a latency requirement is that, a client should not expect that its task to be completed earlier than what an average server can offer; and it is reasonable for a client to expect its task to be completed not times longer than what an average server can offer. The actual deadline of task is given by , where is the arrival time of task .

Recall that the utility of a provider is given by . We choose a value for to make the cost of providing a certain number of servers be comparable to the revenue received due to making those servers available333As a future work, we will decide empirically the cost coefficient by considering actual operating cost, e.g., power consumption, electricity usage.. Specifically, we simulated an Edge-Cloud system with an edge player and a cloud player, and with one-minute simulation time and . We repeated the simulation for various combinations of the numbers of edge and cloud servers, with a total number of servers varying from to . Based on these simulation runs, we choose and for edge and cloud player respectively. We let , as typically a cloud provider can deploy servers with a lower cost due to it’s economy of scale compared with edge providers.

V-C Existence of Nash equilibrium and efficiency loss metric

We have conducted extensive simulations of dynamic task arrivals via an event-driven simulator that we developed in Python and we have applied CPLEX [19] to solve the optimization problem for tasks arriving in a batch. Our results have demonstrated the existence of Nash equilibrium. In this subsection, we first illustrate the structure of the game between two players, through our results on the case of batch task arrivals, and we introduce a metric to measure the efficiency of an Edge-Cloud system. Then we discuss the impact of revenue sharing via simulations of dynamic task arrivals.

Recall that for a batch arrival of tasks, the solution of optimization problem (3) gives a system manager the maximum total received value or revenue by optimally assigning those tasks to its servers, and then the manager utilizes a revenue sharing mechanism to split the revenue among its servers.

Fig. 3: Revenue of a provider.
Fig. 4: Utility of a provider.

Fig. 5: Best response curves of two providers in a symmetric game.
Fig. 6: Best responses of two providers in an asymmetric game.

(a)

(a) (a)
Fig. 7: Utility loss (compared with the maximum utility) at Nash equilibria.

(a)

(a) (a)
Fig. 8: Ratio of the number of servers of the edge player over that of the cloud player at Nash equilibria.

Consider a system that consists of two providers, with a set of tasks arriving in a batch, and Shapley value mechanism is adopted by the system. First suppose that the servers of both providers are all identical in terms of CPU and bandwidth. This game is referred to as a symmetric game. Figure 4 shows the revenue received by a provider by varying its number of servers in the system, when the other provider places servers in the system. The revenue curve is increasing and concave, which shows that the provider’s marginal revenue is decreasing even though its received revenue is increasing due to its increasing number of servers. Figure 4 shows the utility received by the provider. We see that due to the decreasing marginal revenue and the increasing cost, the utility first increases and then drops.

Based on the utilities of the two players, we derive their best response curves [18, 16] and draw them in Figure 6. Each point of a player’s best response curve represents the player’s best strategy in response to the other player’s strategy. For example, a point on the best response curve of player 2 to player 1 represents the number of servers (the y-axis value of the point) that gives player 2 the maximum utility given that player 1 chooses a certain number of servers (the x-axis value of the point). Therefore, any intersection point of the two best response curves represents a Nash equilibrium. Figure 6 shows that the game has two Nash equilibria or , where is the optimal strategy of player with respect to player ’s strategy , and vice versa.

Note that a typical metric to measure a system’s performance at a Nash equilibrium is efficiency loss [27, 16], which is a comparison between the overall system utility at the equilibrium with the maximum overall system utility. We use the relative utility loss of an equilibrium to capture the efficiency loss of the equilibrium, which is defined as

(12)

where is the utility of player at Nash equilibrium , and is the maximum overall system utility444It is the solution of a system-wide utility maximization problem, and the numbers of servers specified by the solution for the providers may not maximize their individual utilities.. For example, in the above game with tasks arriving in a batch, we observe that the system’s utility loss is around at the unique equilibrium555In some games, there are two Nash equilibria and they are very close to each other, similar to the case shown in Figure 6. The existence of multiple equilibria is due to the discrete nature of strategies (i.e., number of servers). In those cases, utility loss is calculated as the average of those equilibria.. As another example, we change the previous game by setting (then the game is asymmetric as the two players have different bandwidth). Figure 6 shows the existence of Nash equilibrium in this game.

V-D Impact of Revenue Sharing on System Performance

Our extensive simulations have demonstrated the existence of Nash equilibrium in the game between edge and cloud providers in a wide range of system/network settings, when tasks arrive in a dynamic process. We find that different revenue sharing mechanisms have quite different impacts on the performance of an Edge-Cloud system, and in general Direct-contribution-based sharing mechanism results in the worst system-level efficiency than Shapley and Ortmann mechanisms. Due to space limitations, we only present in this section some results of the game between a cloud player and an edge player, shown in Figures 7 and 8. For ease of exposition, we let the cloud player’s servers differ from the edge player’s servers only in the bandwidth of the paths between themselves and clients, and we let all servers have the same CPU capacity. Each simulation presented here lasts minutes, and tasks arrive at the system in a Poisson process with tasks per minute. The results of our simulations based on the empirical task arrival process in Google trace [10] are similar to the results presented in this subsection.

V-D1 Utility loss

We observe from Figure 7 that when the transmission bandwidth difference between cloud servers and edge servers is small (i.e., or ), the losses of system-level utility are roughly the same for all three different revenue sharing mechanisms and across different latency requirement levels of tasks ()666If , then is the amount of time to complete task (without queuing delay) on the server with the lowest bandwidth..

However, when the cloud player’s transmission bandwidth is significantly lower than that of the edge player (), Figure 7 shows that Direct-contribution-based sharing gives the worst utility loss among all three mechanisms, across different latency requirement levels () of tasks. In addition, when tasks have very stringent latency requirement (i.e., ), Shapley mechanism gives the lowest utility loss (only ). When latency requirement becomes less stringent (), Shapley mechanism and Ortmann mechanism have roughly the same utility loss. When tasks have very flexible latency requirements (), the utility loss of Shapley mechanism is higher than that of Ortmann mechanism, but still they both are lower than that of Direct-contribution-based mechanism.

V-D2 Numbers of servers at equilibria

In addition, we have also examined the ratio of the number of the edge player’s servers over the number of the cloud player’s servers at Nash equilibrium777In the case where there are two Nash equilibria, the ratio is calculated as the average of the two equilibria, similar to the calculation of utility loss.. Figure 8 shows that when the bandwidth difference between the two players is not big ( or ), the edge player has fewer number of servers at equilibria than the cloud player across all three different revenue sharing mechanisms and all three different levels of latency requirements. This is because the edge player’s cost of placing servers in the system is higher than that of the cloud player.

When gets higher () and task latency requirement is stringent or normal ( or ), the cloud player will place fewer number of servers (than the edge player) at equilibria under Shapley or Ortmann mechanism. This is because the cloud player’s servers are less likely able to meet tasks’ deadline requirements, and the two revenue sharing mechanisms discourage the cloud player from putting more servers in the competition. This discouragement leads to a better system-level performance (i.e., low system utility loss) than the Direct-contribution-based sharing, as shown in Figure 7 (a) and (b).

V-D3 The case of large bandwidth difference () and stringent latency requirements of tasks ()

The disadvantage of Direct-contribution-based sharing mechanism is quite obvious in this case. Figure 7 (a) shows that its utility loss () is significantly higher than that of Shapley’s () and Ortmann’s ().

This is because that under the Direct-contribution-based sharing, the very low bandwidth provider (i.e., the cloud player) still aggressively utilizes many servers in order to gain a high revenue (as they are rewarded directly based on their actual contributions), which leads to a very low overall system efficiency. But Shapley and Ortmann mechanisms discourage such an aggressive behavior of the provider with very low bandwidth, because our results show that in this case, Shapley and Ortmann mechanisms give penalty instead of reward to the low bandwidth cloud servers. Specifically, Shapley mechanism will start to assign decreasing or even negative revenue to cloud servers once the number of cloud servers increases over a threshold (which implies that the addition of a cloud server with very low bandwidth will bring negative marginal contribution to the system); and similarly, Ortmann mechanism will assign lower and lower revenues to cloud servers. Our results also show that in this case, Shapley and Ortmann mechanisms bring significant more revenue to the system than Direct-contribution-based sharing at Nash equilibria. Our finding suggests that Shapley and Ortmann mechanisms, the two mechanisms that distribute revenue based on marginal contributions instead of directly on actual contributions, can help improve a system’s overall utility in the face of the self-interested behavior of providers.

Summary. Shapley mechanism gives the best system-level performance in most cases in our simulations, despite that providers game with the system to pursue their self-interested optimization goals. Ortmann mechanism is similar to Shapley mechanism in terms of system utility loss at Nash equilibria. Direct-contribution-based mechanism results in the worst system performance at equilibria.

Vi Conclusions and Future work

We have proposed a game-theoretic framework to investigate the impact of revenue sharing mechanisms on the performance of an Edge-Cloud system in which edge providers and cloud providers compete with each other and game with the system in order to maximize their own utilities. We have found that the revenue sharing based directly on actual contributions of servers can result in significantly worse system-level performance than Shapley value and Ortmann proportional sharing mechanisms at the Nash equilibria of the game between providers. For future work, we will conduct a theoretic analysis, study dynamic game playing processes, and conduct large scale experiments of Edge-Cloud systems.

References

  • [1] F. Bonomi, R. Milito, J. Zhu, and S. Addepalli, “Fog computing and its role in the internet of things,” in ACM MCC 2012.
  • [2] M. Chiang, “Fog networking: An overview on research opportunities,” arXiv preprint arXiv:1601.00835, 2016.
  • [3] Y. C. Hu, M. Patel, D. Sabella, N. Sprecher, and V. Young, “Mobile edge computing: A key technology towards 5g,” ETSI White Paper, 2015.
  • [4]

    W. Shi, J. Cao, Q. Zhang, Y. Li, and L. Xu, “Edge computing: Vision and challenges,”

    IEEE Journal of Internet of Things, vol. 3, 2016.
  • [5] S. Yi, C. Li, and Q. Li, “A survey of fog computing: concepts, applications and issues,” in Proceedings of the 2015 Workshop on Mobile Big Data.   ACM, 2015, pp. 37–42.
  • [6] P. Liu, D. Willis, and S. Banerjee, “Paradrop: Enabling lightweight multi-tenancy at the network’s extreme edge,” in IEEE/ACM SEC 2016.
  • [7] J. Yoon, P. Liu, and S. Banerjee, “Low-cost video transcoding at the wireless edge,” in IEEE/ACM SEC, 2016.
  • [8] L. S. Shapley, “A value for n-person games,” Contributions to the Theory of Games, Princeton University Press, vol. 28, 1953.
  • [9] K. M. Ortmann, “The proportional value for positive cooperative games,” Math. Methods of Operations Research, vol. 51.
  • [10] Google. Google cloud cluster data. http://googleresearch.blogspot.com/2010/01/google-cluster-data.html.
  • [11] T. Zhang, A. Chowdhery, P. V. Bahl, K. Jamieson, and S. Banerjee, “The design and implementation of a wireless video surveillance system,” in ACM MobiCom 2015.
  • [12] K. Ha, Z. Chen, W. Hu, W. Richter, P. Pillai, and M. Satyanarayanan, “Towards wearable cognitive assistance,” in ACM MobiSys 2014.
  • [13] . The cloud comes to you. http://about.att.com/story/reinventing_the_cloud_through_edge_computing.html. Accessed: 2017-07-27.
  • [14] R. T. Ma, D. M. Chiu, J. Lui, V. Misra, and D. Rubenstein, “Internet economics: The use of shapley value for isp settlement,” IEEE/ACM Transactions on Networking (TON), vol. 18, no. 3, pp. 775–787, 2010.
  • [15] V. Misra, S. Ioannidis, A. Chaintreau, and L. Massoulié, “Incentivizing peer-assisted services: a fluid shapley value approach,” in ACM SIGMETRICS Performance Evaluation Review, vol. 38, no. 1, 2010.
  • [16] H. Zhang, D. Towsley, and W. Gong, “TCP connection game: A study on the selfish behavior of TCP users,” in IEEE ICNP 2015.
  • [17] H. Zhang, B. Liu, H. Susanto, G. Xue, and T. Sun, “Incentive mechanism for proximity-based mobile crowd service systems,” in IEEE INFOCOM, 2016.
  • [18] T. Basar and G. J. Olsder, Dynamic Noncooperative Game Theory.   New York: Academic Press, 1998.
  • [19] Cplex. https://www.ibm.com/us-en/marketplace/ibm-ilog-cplex. Accessed: 2017-07-20.
  • [20] R. B. Myerson, “Graphs and cooperation in games,” Mathematics of operations research, vol. 2, no. 3, pp. 225–229, 1977.
  • [21] H. Susanto, B. Kaushik, B. Liu, and B.-G. Kim, “Pricing and revenue sharing mechanism for secondary re-distribution of data service for mobile devices,” in IEEE IPCCC 2014.
  • [22] Raspberry pi. https://www.raspberrypi.org. Accessed: 2017-07-20.
  • [23] docker. http://www.docker.com. Accessed: 2017-03-10.
  • [24] The web application messaging protocol. http://wamp-proto.org. Accessed: 2017-03-10.
  • [25] G. Bradski and A. Kaehler, Learning OpenCV: Computer vision with the OpenCV library.   ” O’Reilly Media, Inc.”, 2008.
  • [26] T.-Y. Lin and et al., “Microsoft coco: Common objects in context,” in European Conference on Computer Vision.   Springer, 2014, pp. 740–755.
  • [27] R. Johari and J. N. Tsitsiklis, “Efficiency loss in a network resource allocation game,” Mathematics of Operations Research, vol. 29, no. 3, pp. 407–435, 2004.