{'fraction_non_alphanumeric': 0.04994999805187215, 'fraction_numerical': 0.009896489473615855, 'mean_word_length': 4.4791147797623285, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 6, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 5, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Joint Compute-Caching-Communication Control for Online Data-Intensive Service Delivery

Emerging Metaverse applications, designed to deliver highly interactive and immersive experiences that seamlessly blend physical reality and digital virtuality, are accelerating the need for distributed compute platforms with unprecedented storage, computation, and communication requirements. To this end, the integrated evolution of next-generation networks (e.g., 5G and beyond) and distributed cloud technologies (e.g., fog and mobile edge computing), have emerged as a promising paradigm to address the interaction- and resource-intensive nature of Metaverse applications. In this paper, we focus on the design of control policies for the joint orchestration of compute, caching, and communication (3C) resources in next-generation distributed cloud networks for the efficient delivery of Metaverse applications that require the real-time aggregation, processing, and distribution of multiple live media streams and pre-stored digital assets. We describe Metaverse applications via directed acyclic graphs able to model the combination of real-time stream-processing and content distribution pipelines. We design the first throughput-optimal control policy that coordinates joint decisions around (i) routing paths and processing locations for live data streams, together with (ii) cache selection and distribution paths for associated data objects. We then extend the proposed solution to include a max-throughput database placement policy and two efficient replacement policies. In addition, we characterize the network stability regions for all studied scenarios. Numerical results demonstrate the superior performance obtained via the novel multi-pipeline flow control and 3C resource orchestration mechanisms of the proposed policy, compared with state-of-the-art algorithms that lack full 3C integrated control.

vices, especially the Metaverse applications, is data-intensive. In the Metaverse, user experiences result from real-time aggregation, processing, and distribution of multiple live media streams (collected by sensors) and digital assets (prestored in network). Augmented reality (AR), as illustrated in Fig. 2, is a clear example, which enriches initial videos with scene objects to generate enhanced experiences that can be consumed by users [5]. Face/object recognition is another example, where the access to training samples is required to classify images uploaded by users [6].
Indeed, the efficient delivery of data-intensive services requires joint orchestration of computation, caching and communication (3C) resources and end-to-end optimization of the associated decisions, including the following aspects: (i) packet processing: where to execute the service functions in order to process the multiple source data streams, (ii) packet routing: how to route each data stream to the processing location, and (iii) packet caching: where to create the digital objects, and how to place and replace them in the network. In addition, the processing, routing and caching problems must be addressed in an online manner, in response to stochastic network conditions and service demands.

Computation and Communication
The distributed cloud network control problem has been intensely studied in the recent literature, mainly focusing on virtual network function (VNF) placement and service embedding (i.e., flow routing), especially for applications that can be modeled by service function chains (SFCs), with the single task offloading problem [7] as a special case [8].
One line of work studies this problem in a static setting, with the objective of either maximizing accepted service requests [9], [10], or minimizing overall operational cost [11], [12]. While useful for long timescale end-to-end service optimization, these solutions exhibit two main limitations: first, the problem is formulated as a static optimization problem without considering the dynamic nature of service requests, a critical aspect in next-generation AgI services; second, due to the combinatorial nature of the problem, the corresponding formulations typically take the form of (NPhard) mixed integer programs (MIP), and either heuristic solutions or loose approximation algorithms are developed, compromising the quality of the resulting solution.
To address the SFC optimization problem in dynamic scenarios, one needs to make joint packet processing and routing decisions in an online manner, as well as traffic scheduling and resource allocations, in response to stochastic system states (e.g., service demands, link capacities). Among existing techniques, Lyapunov drift control, firstly applied to communication networks [13], [14], [15], proves to be a powerful tool to guide the design of throughputoptimal cloud network control policies, such as DCNC [16] and UCNC [17], by dynamically exploring processing/routing diversity. In general, centralized routing approaches, e.g., UCNC, can attain better delay performance than distributed routing, e.g., DCNC, by delivering data packets along acyclic paths [18], [19].

Caching and Communication
Over the past decade, the dramatic growth of user demands for multimedia contents (e.g., videos) has fueled rapid advances in caching techniques, especially at the wireless edge. By storing copies of popular contents close to users, the network traffic and latency for content retrieval and distribution are significantly reduced [20], [21], [22].
Caching policy and transmission policy are two key elements in content distribution network design, dealing with (i) content placement in the network, and (ii) content delivery to users, respectively. Driven by different performance metrics, various caching policies have been designed, e.g., throughput [23], delay [21], energy efficiency [24], etc., and some of them are jointly optimized with the employed communication techniques, e.g., non-orthogonal multiple access (NOMA) [25], multiple-input and multiple-output (MIMO) [26], coded-multicast [27], etc..
In multi-hop networks, flow routing, including the selections of the caching node to create and the path to deliver the content, plays an important role in the content distribution. In addition, the joint optimization of caching and routing can benefit the overall network performance [28]. Some existing studies propose formulations targeting either throughput maximization [29], or service cost minimization [30], and approximation algorithms are developed to address the resulting MIP problems.

Joint 3C Optimization
While there is a large body of works on the integration of computation-communication and caching-communication  Fig. 1. Network and service models studied in this paper and related works. Data-intensive AgI [35] (this paper): distributed cloud network, service DAG (see Section 2.2) with both live data and digital objects. DECO [36]: distributed cloud network, one-step processing with digital objects. MEC [7]: single computing server, one-step processing with live data. AgI [16], [17]: distributed cloud network, SFC with live data.
technologies into network design, the integration of 3C is a less explored topic.
Two combinations, computing-assisted information centric networking (ICN) and cache-enabled MEC, are studied in [31], and both of them are promising directions for 3C integration. In cache-enabled MEC, one topic is service caching/provisioning, dealing with service functions/programs with non-trivial storage requirements [32]; another topic is data caching, i.e., caching frequently used databases [33], such as processed results (of previous tasks) that might be repeatedly requested [34], which can save the latency and computation resources to generate the content.
In this paper, we focus on the data caching aspect in the delivery of data-intensive services (in particular, Metaverse applications), assuming that the cached digital objects (or static objects) will be aggregated with user-specific data (or live data) and processed to generate highly personalized experiences for different users. Under such assumption, [35] develops approximation algorithms for the data-intensive service embedding problem in a static setting; the dynamic (but simplified) setting is investigated in [36], focusing on the digital object retrieval and processing while ignoring the live service chain routing pipeline.

Our Contributions
In this paper, we investigate the problem of joint 3C control for online data-intensive service delivery. As illustrated in Fig.  1, the data-intensive service can include multiple functions, each requiring multiple source data streams as inputs that can be live data (collected by sensors), static objects (prestored in network), or intermediate results (generated by previous processing), e.g., F2 in blue.
Compared to existing service models, e.g., MEC, DECO, AgI as illustrated in Fig. 1, two challenges arise in the delivery of data-intensive AgI services: (i) processing location selection affects not only the processing procedure, but also the transmission loads of all input streams, (ii) the digital object input can be created (by replication) at any caching location in an on-demand manner (i.e., per service function's request), which is fundamentally different from a live data input generated by the end user, with a fixed source and a spontaneous rate. While existing cloud network control policies [7], [16], [17], [36], designed for simplified service models, are not able to handle these challenges, not to mention the coupling of them, i.e., jointly selecting the processing and caching locations. We term this problem multi-pipeline flow control.
Another key element that impacts the service delivery performance is the caching policy design, including "which databases to cache" and "at which node". Similar to existing works in caching-communication integration, database placement should be jointly optimized with the flow control decisions, but going beyond flow routing to also include flow processing, especially for heterogeneous networks with highly-distributed 3C resources. Furthermore, when considering time-varying popularity distribution (or service demand statistics), the service delivery performance shall benefit from the dynamic adjustment of the caching policy. These problems are collectively referred to as joint 3C resource orchestration.
In this paper, we address the above two problems, and our contributions can be summarized as follows: 1) We characterize the network stability regions for data-intensive AgI service delivery, in the settings of (i) fixed and (ii) dynamic database placements. 2) We design the first throughput-optimal control policy, DI-DCNC, that coordinates joint decisions around (i) routing paths and processing locations for live data streams, together with (ii) cache selection and distribution paths for associated static data objects, under any fixed database placement. 3) We propose a database placement policy targeting throughput maximization, and derive an equivalent mixed integer linear programming (MILP) problem that can be used for implementation. 4) We develop two database replacement policies able to adapt to time-varying demand statistics, based on online estimations of (i) popularity distribution, and (ii) database score, respectively.
The rest of this paper is organized as follows. In Section 2, we introduce the models for cache-enabled edge cloud and data-intensive service. In Section 3, we define the policy space and characterize the network stability regions. We devise the DI-DCNC control policy (for fixed database placement) in Section 4, followed by a max-throughput database placement policy in Section 5, as well as two replacement policies in Section 6. Section 7 present the numerical results, and conclusions are drawn in Section 8.
Frequently used notations are summarized in Table 1. Fig. 1 illustrates the data-intensive AgI service model and the cache-enabled MEC network supporting its delivery, described as follows. Arrivals of client c, arrival rate.

SYSTEM MODEL
Node and edge sets of ALG for service φ. o ′ m Super static source (of stage m static objects). σ, Fc(x) Efficient route and the set of them. a (c,σ) (t) Number of service requests selecting ER σ. θ (m) Processing location for function m. Λ(x), Λ Stability region (under placement x/replacement).
Virtual queue and normalized virtual queue.
Popularity distribution of service requests.
Live/static flows in ALG/actual network.
Resource load on an ALG edge/actual link. V i,k Score (of database k at node i).

Cache-Enabled MEC Network Model
The considered cache-enabled MEC network is modeled by a directed graph G = (V, E), with V and E denoting the node and edge sets, respectively. Each node i ∈ V represents an edge server, equipped with computation resources (i.e., computing devices) for service function processing. Each edge (i, j) ∈ E represents a network link supporting data transmission from node i to j. Denote by δ − (i) and δ + (i) the incoming and outgoing neighbor sets of node i, respectively. Time is slotted, and the available processing and transmission resources are quantified as follows: • Processing capacity C i : the maximum number of instructions (e.g., floating point operations) that can be executed in one time slot at node i.
• Transmission capacity C ij : the maximum number of data units (e.g., packets) that can be transmitted in one time slot over link (i, j).
The network nodes are also equipped with storage resources 1 to cache databases, which are composed of digital objects whose access may be required for service function processing, and we denote by K the set of all databases. Define the caching vector as . We refer to a node i as a static source of database k if x i,k = 1, and denote by V(k) = {i ∈ V : x i,k = 1} ⊂ V the set of all static sources. A caching vector must satisfy the following storage resource constraint: 1. In this paper, "storage resources" refers to spaces used for database caching, and data packets associated with service requests are collected in separate spaces, referred to as "actual queues" (see Section 2.4).
The basic model for data-intensive services, including multiple functions (denoted by "F"), each requiring one live and static streams as inputs. We also depict the AR application as a special case requiring one-step processing, and some practical extensions that can be included in the general DAG model (using F M φ − 1 as an example).
where F k denotes the size of database k ∈ K, and S i the storage capacity of node i ∈ V, i.e., the maximum number of static object units (e.g., databases) that can be cached at node i ∈ V, respectively. Denote by X the set of all caching vectors x satisfying (2). There is a cloud data-center in the network, serving as external trusted source with all databases stored, from which the edge servers can download some databases for caching. We assume that the downloads are supported by another communication system and do not consume the communication resources introduced above. 2

Data-Intensive Service Model
Next, we introduce the model for data-intensive service [35], which can be described by a directed acyclic graph (DAG). For ease of exposition, we illustrate the proposed design using a basic model, which simplifies the general model while maintaining the key elements, as illustrated in Fig.  2. Extensions of the model are described in Remark 2.
Each data-intensive service φ includes a sequence of M φ − 1 functions, through which the user-specific packets, referred to as live data, must be processed to produce consumable results, resulting in the end-to-end data stream divided into M φ stages, and we refer to the input to function m ∈ {1, · · · , M φ − 1} as stage m live packet. In order to process each live packet, the service function requires the other input of a digital object, referred to as static object [35], [36], which can be requested repeatedly and is prestored in the network, and we abuse the term stage m static object to denote the static object input to function m without ambiguity. Each processing step can take place at different network locations hosting the required service functions: for example, in Fig. 1, the two service functions F1 and F2 (in blue) are executed at different edge servers.
Each service function, say the mth function of service φ, is specified by 4 parameters (ξ  2. Database replacement can be completed with backhaul links between the cloud data-center and edge servers, subject to restricted transmission rates.  Note that the "input live packet" mentioned in the above definitions refers to the stage m live packet, and we define the cumulative scaling factor Ξ (φ) m as the number of stage m live packets per stage 1 live packet (i.e., the initial packet arriving to the network), given by (3)

Remark 1 (Static Object).
Each database can include multiple static objects, e.g., the scene object library in the AR application, and distinct static objects can be required in different service requests. We assume that the live packet and static object belonging to a given request get associated, i.e., static objects will only be used for the processing of corresponding live packets.

Remark 2 (Extended Models).
In general, a data-intensive service can be described by a DAG, and we present two practical extensions to the basic model in the following.
(i) For functions with multiple static inputs, we can extend k m (from scalars) to sets. (ii) For functions with multiple live inputs, we can adopt a tree definition that creates a node for each service function and describes the inputs to it as its child-nodes until reaching the initial/unprocessed live data (i.e., leaf nodes). The extensions are straightforward and thus omitted.

Client Model
We define each client c by a 3-tuple (s, d, φ), denoting the source node s (where the live packets arrive to the network), the destination node d (where the final packets are requested for consumption), and the requested service φ (which defines the sequence of service functions and the static objects that are required to process the live packets and create the final packets), respectively. 3 We refer to a live packet and all static objects required for its processing as belonging to the same packet-level request.

Live Packet Arrival
For each client c, let a (c) (t) be the number of live packets arriving at the source node s at time t. We assume that the arrival process {a (c) (t) : t ≥ 0} is i.i.d. over time, with a mean arrival rate of λ (c) and a maximum number of packet arrivals A (c) max . Each live packet is immediately admitted to the network upon arrival. Remark 3. In Section 5 (and the subsequent sections), we assume that there exists a popularity distribution (31) governing the arrival rates of all clients, i.e., λ (c) : ∀ c , when designing database placement policies targeting throughput maximization.

Remark 4.
We assume i.i.d. arrivals for ease of exposition. Some results, i.e., Theorem 1, 2, and Proposition 3. A packet defines the service data unit that can be processed independently, such as a video segment/frame in practice.

Transmission queue
Processing queue (paired packets) Node Waiting queue (unpaired packets) Node i j Fig. 3. Illustration of the queuing system, and in particular, the paired packet queue. Different shapes denote packets associated with different requests, blue and red colors the live and static packets, and solid and dashed lines the current and next time slots, respectively.
2, are valid under the general assumption of Markovmodulated arrivals, i.e., the arrival rate is time-varying and follows a Markov process (see [14,Section 4.9]).

Static Object Provisioning
Upon receiving a packet-level request, for each required static object, one static source is selected to create (by replication) a replica and load it into the network immediately. Recall that the static object replica gets associated with the corresponding live packet (see also Remark 1).

Queuing System
Each packet (live or static) admitted to the network gets associated with a route encompassing its delivery, and we establish actual queues at each node/link to accommodate packets waiting for processing/transmission at the corresponding locations, respectively.
For each link (i, j) ∈ E, we create one transmission queue collecting all packets -regardless of the client, stage, or type (i.e., live or static) -waiting to cross the link, i.e., packets currently located at node i and having node j as its next hop in the route. In contrast, two queues are constructed at each node i ∈ V: (i) the processing queue collecting the paired live and static packets concurrently present at node i, which are ready for processing, and (ii) the waiting queue collecting the unpaired live or static packets waiting for their in-transit associates, which are not qualified for processing until joining the processing queue upon their associates' arrival.
An illustrative example is shown in Fig. 3. At the current time slot, the paired packet queue (i.e., processing queue) holds a blue and red circle pair, representing live and static packets associated with the same request, which are ready for processing. At next time slot, when node i receives the red square packet, it gets paired with the blue square packet held in the waiting queue, which together enter the paired packet queue and can be scheduled for processing.

POLICY SPACE AND STABILITY REGION
In this section, we establish an augmented layered graph (ALG) model for the analysis and optimization of the dataintensive service delivery problem, based on which we characterize the network stability regions.  Fig. 4. Illustration of the ALG model.

Augmented Layered Graph
Recent studies have shown that the AgI service (modeled by SFC) control problem can be transformed into a packet routing problem on a properly constructed layered graph [17]. While this initial model focuses on the single live service chain routing and processing pipeline, in the data-intensive service involving multiple input streams, a straightforward extension is to incorporate multiple pipelines into the model.

Topology of the ALG
The ALG associated with service φ is composed of M φ layers, indexed by layer 1, · · · , M φ , respectively. Within each layer, there are two pipelines, termed live and static pipelines, respectively, except for the last layer M φ , which only includes the live pipeline. Each live pipeline has the same topology as the actual network, while each static pipeline (e.g., in layer m) includes an additional super static source node o ′ m and the outgoing edges (o ′ m , v ′ m ) connecting to all static sources ∀ v ∈ V(k m . To wit, if node o ′ m can provide static object to node i ′ m along the path (o ′ m , v ′ m , · · · , i ′ m ) in the pipeline, we can select the static source v to create the replica and route it to node i along the rest of the path in the actual network, and vice versa. (iii) The cross-layer edges from layer m to m + 1 represent processing operations, i.e., the stage m live and static packets pushed through these edges are processed into stage m + 1 live packets in the actual network. Fig. 4 illustrates the ALG model using an example of delivering the AR service φ (as shown in Fig. 2) over a 4-node network. In the actual network, the stage m = 1 live packet, arriving at the source node s, and the static object, replicated at the static source v, are transmitted to node p (along the blue and green paths), where they also get processed. The produced stage m + 1 = 2 packet is then transmitted to the destination node d (along the red path). In the ALG model: the highlighted links in different pipelines indicate the transmission path of each packet, 1 ) = {v, d} to create the replica, and (p 1 , p 2 ) and (p ′ 1 , p 2 ) indicates selecting node p to process the packets.
Formally, given the actual network G and the database placement x, the ALG of service φ, denoted by G (φ) = (V (φ) , E (φ) ), is given by in which (with L/S in the subscripts denoting live/static) When there are multiple live and static inputs, it is flexible to incorporate more pipelines into each layer.
In particular, the proposed ALG model reduces to the layered graph [17] when the static object is not relevant (in which case all static pipelines are eliminated).

Remark 6.
We note that there are multiple edges in the ALG associated with the same actual network infrastructure.
for ∀ m all correspond to link (i, j), and the operation on any edge consumes the link's communication resource.

Flow in the ALG
Denote by f ı ≥ 0 the network flow associated with edge (ı, ) ∈ E (φ) in the ALG, defined as the average packet rate traversing the edge (in packets per slot). In particular: • f imim+1 and f i ′ m im+1 denote the processing rates of the stage m live and static streams at node i ∈ V.
The flows must satisfy the following constraints: i.e., for stage m live stream, the total outgoing flow rate of transmitted and processed packets is equal to the total incoming flow rate of received packets, and those produced by processing. Note that processing the input stage m − 1 live stream at a rate of f im−1im by function m − 1 produces stage m live stream at a rate of ξ (ii) Static flow conservation: i.e., for stage m static stream, the total outgoing rate of transmitted and processed packets is equal to the total incoming rate of received packets, and those produced by m ), i.e., nodes that are not static sources.
(iii) Data merging: i.e., the processing rates of static and live streams at each node i are associated by the merging ratio ζ (φ) m , since processing each stage m input live packet requires ζ (φ) m stage m static objects.

Policy Space
We consider a general policy space for data-intensive service delivery under fixed database placement, encompassing joint packet processing, routing, and replication operations. To be specific, upon receiving a request, the network controller makes joint decisions on (i) routing paths and processing locations for live data streams, together with (ii) cache selection and distribution paths for associated data objects. In addition, each node and link need to decide which packets to schedule for processing and transmission at each time slot.

Decision Variables
An admissible policy thus consists of two actions.
Route Selection: For each received request, choose a set of edges in the ALG and the associated flow f satisfying (5) - (7), and the decisions follow that: (i) Cache selection, i.e., selecting the static source to create each static object k Transmission path for each packet (live or static) is composed of the edges with non-zero rates in the corresponding pipeline. While each static packet remembers its own path, note that the initial live packet gets associated with a route that aggregates paths for live packets of all stages. For example, in Fig. 4, the stage 1 live packet gets associated with the route including both blue and red edges. (iii) Processing location selection is indicated by the processing rates f imim+1 and f i ′ m im+1 , and the live and static packets are guaranteed to meet at the same node i due to (7).
Packet Scheduling: At each time slot, each node i and link (i, j) schedule some packets in the local processing and transmission queues for operation, and the incurred resource consumption shall not exceed the corresponding capacities C i and C ij . We recall that the processing queue only holds paired live and static packets.

Efficient Policy Space
In this section, we define an efficient policy space, which requires each data packet to follow acyclic paths for delivery, without compromising the performance (e.g., throughput, delay, resource consumption).
More concretely, each request gets associated with an efficient route (ER) σ in the ALG, defined as: • σ includes a set of processing locations, denoted by θ (m) ∈ V : 1 ≤ m ≤ M φ − 1 , corresponding to the following processing edges in the ALG where function m is executed at node θ (m) , and we define θ (0) = s and θ (M φ ) = d.
• σ includes acyclic transmission paths for each packet, and the paths for stage m live and static packets are denoted by: In the efficient policy space, for each client c, the set of all possible ERs, denoted by F c (x), is finite, and the route selection decision can be represented by where a (c,σ) (t) ≥ 0 denotes the number of requests raised by client c at time t that get associated with σ for delivery, which satisfies Note however that F c (x) includes an exponential number of ERs, i.e., |F c (x)| = Ω(|V| M φ −1 ).

Network Stability Region
In this section, we characterize the network stability regions, which measure the throughput performance of the edge cloud to support data-intensive service delivery. Definition 1. The network stability region is defined as the set of all arrival vectors λ, such that there exists an admissible policy to stabilize the actual queues, i.e., and R ij (t) denote the backlogs of the processing, waiting queues of node i, and the transmission queue of link (i, j) at time t.
Let Λ(x) and Λ be the network stability regions under fixed database placement and when allowing dynamic replacement, characterized in the following. Theorem 1. For any fixed database placement x ∈ X , an arrival vector λ is interior to the stability region Λ(x) if and only if for each client c, there exist probability values such that for each node i and link (i, j): denote the processing and transmission resource loads imposed on node i and link (i, j) if a request of client c is delivered by ER σ, given by: .

(12)
Proof: The proof for necessity is given in Appendix A, and we show the sufficiency by designing an admissible policy DI-DCNC in the subsequent section, and proving that it can support any arrival vector λ ∈ Λ(x).
In Theorem 1: (i) The sum operation in (11) results from multiple ALG edges sharing a common node/link (see also Remark 6). (ii) The probability values P c (σ) define a randomized policy for route selection, operating as follows: at each time slot, select the ER σ ∈ F c (x) to deliver the requests of client c with probability (w.p.) P c (σ). (iii) The result remains valid under the general assumption of Markov-modulated arrivals, in which case the stability region is defined with respect to time average arrival rate and for each database placement x ∈ X and client c, such that for each node i and link (i, j): given by (11).
Proof: See Appendix D. In the above proposition, P(x) denotes the distribution of caching vector x over time, which results from the employed replacement policy; P c,x (σ) plays an equivalent role as P c (σ) in Theorem 1, i.e., the probability values specifying the route selection policy under placement x.
Comparing Theorem 1 and Proposition 1, we find that allowing database replacement is promising to enlarge the stability region. To wit, setting P(x) = 1 {x=x0} in Proposition 1 leads to the same characterization as Theorem 1 with x = x 0 . The result is intuitive assuming that "each node can complete arbitrary database replacement immediately", since database placement x can be adjusted at each time slot based on the received requests, to optimize the service delivery performance. In Proposition 3, we will show that the result remains valid under restricted transmission rate for database replacement, in line with footnote 2. Remark 7. We note that Proposition 1 is derived under the admission control policy of "selecting the ER for each request upon arrival" (see Section 2.3.1), an assumption not necessarily optimal for throughput performance when allowing database replacement, because one can choose to serve the requests when observing a preferable database placement (not upon arrival).

MULTI-PIPELINE FLOW CONTROL
In this section, we present the proposed algorithm, referred to as data-intensive dynamic cloud network control (DI-DCNC), which coordinates routing decisions (including processing decisions by ALG) for the live and static pipelines, as well as traffic scheduling, under fixed database placement. We first introduce a single-hop virtual system (in Section 4.1) to derive packet routing decisions (in Section 4.2). Then we present the packet scheduling policy, and summarize the actions taken in the actual network (in Section 4.3).

Precedence Constraint
In line with [15], [17], we establish a virtual network, where the precedence constraint (that imposes a packet to be transmitted hop-by-hop along its route) is relaxed by allowing a packet upon route selection to be immediately inserted into the virtual queues associated with all links in the route. The virtual queue measures the processing/transmission resource load at each node/link in the virtual system, which is interpreted as the anticipated resource load at the corresponding network location in the actual network.
For example, suppose that a packet gets associated with the route (i 1 , i 2 , i 3 ), then it immediately impacts the queuing states of link (i 1 , i 2 ) and (i 2 , i 3 ) in the virtual system, as opposed to the actual network, where it cannot enter the queue for link (i 2 , i 3 ) before crossing (i 1 , i 2 ).
We emphasize that the virtual system is only used for route selection and not relevant to packet scheduling.

Virtual Queues
Denote byQ i (t) andQ ij (t) the virtual queues for node i ∈ V and link (i, j) ∈ E.
The queuing dynamics are given by: where C i and C ij are interpreted as the amount of processing/transmission resources that are "served" at time t; a i (t) andã ij (t) are "additional" resource loads imposed on the node/link by newly arriving packets. Recall that each request gets associated with a route for delivery upon arrival, which immediately impacts the queuing states of all links in the route, and thus: given by (11).

Lyapunov Drift Control
Next, we leverage Lyapunov drift control theory to derive a policy that stabilizes the normalized virtual queues: which have equivalent stability properties as the virtual queues (due to the linear scaling) and can be interpreted as queuing delays in the virtual system. Define the Lyapunov function as L(t) Q(t) 2 /2, and the Lyapunov drift ∆(Q(t)) L(t + 1) − L(t). After some standard manipulations, we derive (in Appendix B.1) the following upper bound of ∆(Q(t)): where B is a constant, and O (c,σ) (t) is referred to as the weight of ER σ, given by: in which we plug in (11), and with w given by (12). The proposed algorithm is designed to minimize the upper bound (16), or equivalently,

Route Selection
Given the linear structure of (19), the optimal route selection decision is given by: where i.e., all requests of client c arriving at time t are delivered by the min-ER, i.e., the ER with the minimum weight, and the remaining problem is to find the min-ER among the exponential number of ERs in F c (x).
To this end, we create a weighted ALG where each edge (ı, ) in the ALG is assigned the weightw (c) ı (t) given by (18), under which the weight of the ER σ (17b) equals to the sum of individual edge weights. In the rest of this section, we propose a dynamic programming algorithm to find the min-ER based on the weighted ALG. Define two variables: is the minimum weight to deliver a stage m live packet to node i, optimized over all previous packet processing/routing/replication decisions.

•
The processing location matrix P of size (M φ − 1) × |V|, where P (m, i) is the optimal processing location of function m, in order to deliver a stage m + 1 live packet to node i.
The ultimate goal is to find W (M φ , d) and the associated ER σ ⋆ , and the proposed approach is to derive the entries of matrix W row-by-row, or layer-by-layer in the ALG. To be specific, suppose row m of matrix W , i.e., {W (m, j) : j ∈ V}, is given, then we can derive each element on row m + 1, e.g., W (m + 1, i), in two steps: First, assuming that function m is executed at node j, we optimize the cache selection and routing decisions to minimize the weight, i.e., where SP(ı, ) and SP(ı, ) denote the shortest path (SP) from node ı to  in the ALG and the resulting weight. As depicted in Fig. 5, the four terms represent: (i) the minweight to deliver a stage m live packet to node j, (ii) the min-weight to route the stage m static object to j, (iii) the processing load, and (iv) the min-weight to route the produced stage m + 1 live packet to node i, respectively. Second, optimize the processing location decision to minimize the overall weight, i.e., Repeating the above procedure, we can derive all entries of W and P , and the min-ER can be found via the following back-tracing procedure. Starting from destination d, the optimal processing location of function M φ − 1, θ (M φ −1) , can be found by looking up the entry (M φ − 1, d) of matrix P . The remaining problem is to find the optimal decisions to: deliver a stage M φ − 1 live packet to node θ (M φ −1) , which has the same structure as the original problem, i.e., deliver a stage Algorithm 1 Dynamic Programming to Find the min-ER Input:w(t); Output: min-ER σ ⋆ , optimal weight W ⋆ (x).

Optimal Actual Network Decisions
Next, we present control decisions in the actual network.
We adopt the route selection decisions made in the virtual network in Section 4.2. In addition, we adopt extended nearest-to-origin (ENTO) policy [17] for packet scheduling: At each time slot t, for each node/link, give priority to the packets which have crossed the smallest number of edges in the ALG in the corresponding processing/transmission queue.
We recall that the processing queue only holds paired live and static packets, and the number of crossed hops of a packet pair is equal to that of the live packet component. The unpaired packets in the waiting queue are not qualified for processing.
To sum up, the proposed DI-DCNC algorithm is described in Algorithm 2. For each client c, all requests arriving at time t are delivered by the min-ER found by Algorithm 1.

3:
Each link transmits packets and each node processes packet-pairs according to ENTO. 4: Update the virtual queues by (14). 5: end for

Throughput
Under any fixed database placement, DI-DCNC is throughput optimal, as described in the following theorem.

Theorem 2.
For any fixed database placement x ∈ X and arrival rate λ interior to the network stability region Λ(x), all actual queues are rate-stable under DI-DCNC.
Proof: See Appendix B.

Complexity
We can take advantage of the following facts to simplify the calculation of (22) when implementing Algorithm 1: where SP 0 (i, j) denotes the SP distance in the weighted graph which has the same topology as the actual network, with the weight of each edge (i, j) ∈ E given by Q ij (t)/C ij . In addition, we note that Therefore, we can implement Algorithm 1 as follows, and analyze the complexity of each step: Therefore, the overall complexity of Algorithm 1 is O(|V| 3 + M φ |V| 2 |C|), with |C| denoting the number of clients (because the requests of each client are delivered along the same ER in each time slot).

Discussions on Delay Performance
As observed in the numerical experiments (in Section 7), the designed DI-DCNC algorithm can achieve superior delay performance. However, we note that it is not delay optimal, due to the following reasons: (i) It focuses on queuing delay and neglects the hopdistance of the selected path, which is the dominant component in low-congestion regimes. (ii) The actual service delay should be taken as the maximum over the concurrent live and static pipelines, while the ER weight (17b) depicts the aggregate delay (i.e., the sum of them). (iii) The actual queuing delay is impacted by the packet scheduling policy, which does not equal the queuing delay in the simplified virtual system. (iv) The live and static packets are scheduled separately, lacking an incentive mechanism that jointly treats packet scheduling in all pipelines.
To address the above issues, a promising approach is to keep track of each packet's lifetime [38], [39] and make lifetime-driven decisions, which is left for future work.

MAX-THROUGHPUT DATABASE PLACEMENT
The second part of this paper tackles the joint 3C resource orchestration problem, with this section focusing on the setting of fixed database placement (and next section designing dynamic database replacement policies).

Problem Formulation
We aim to design a database placement policy to maximize the throughput, jointly optimized with flow control (i.e., processing/routing) decisions.

Variables
We define two variables, representing the database placement and flow control decisions, respectively: ı denotes the live flow rate of client c on edge (ı, ) ∈ E (φ) in the ALG, and f ′(k) ij the static flow rate of database k static objects on link (i, j) ∈ E in the actual network.

Constraints
We impose two classes of constraints on the variables.
(i) Capacity constraints limit the multi-dimensional (processing/transmission/storage) network resource usage: the incurred resource consumption shall not to exceed the corresponding capacities, i.e., the processing rate at each node i ∈ V and the transmission rate over each link (i, j) ∈ E must satisfy c,m as well as the storage constraint (2) at each node i ∈ V: (ii) Service chaining constraints impose the relationship between input and output flows as they traverse network nodes and undergo service function processing. For live flow, the conservation law is given by: (26) and for the destination node: which, compared with (5), includes additional terms representing boundary conditions, i.e., λ (c) in (26), and (27). For the static flows (of database k), the conservation law can be summarized as follows: with the processing rate at node i given by The static flow conservation (28) can be described as follows.
For each node i that is not a static source, i.e., x i,k = 0, the static flow of database k must satisfy the flow conservation constraint, i.e., and (28) is true. For each static source i, in which case Note that (30) does not necessarily hold at the static sources, because they can perform in-network packet replication: an operation known to violate the flow conservation law [18]. In addition, (28) is not a linear constraint (in the optimization variables), due to the cross terms of x and f ′ .

Objective
We assume that the arrival rates of all clients' requests, {λ (c) : ∀ c}, are governed by a popularity distribution. To be specific, the arrival rates are given by and we employ λ to measure the throughput performance. This objective is employed targeting better fairness performance, compared to another widely used metric of "sum flow rate" that favors clients with lighter resource requirement (since a higher throughput can be achieved by serving such clients provided the same network resource).

Remark 8.
If the actual popularity distribution is unknown, we use a uniform distribution {p (c) = 1/|C| : ∀ c} by default. Besides, other than representing the popularity distribution, the values of p (c) can be designed for admission control, customer prioritization, etc..
Proof: See Appendix E. In general, the MILP problem (35) is still NP-hard, which suffers from high complexity to find the exact solution. However, there are many software toolboxes designed to deal with general MILP problems and can find approximate solutions of improving accuracy with time, and we use the widely adopted intlinprog in MATLAB to implement the proposed design. Furthermore, the derived MILP formulation (35) can serve as a good starting point for future studies for approximation algorithm design.

Performance Analysis
In the following, we present an equivalent characterization of the network stability region under fixed database placement x.

Proposition 2.
For any fixed database placement x ∈ X , an arrival vector λ is interior to the stability region Λ(x) if and only if there exist flow variables f, f ′ 0 satisfying (25) - (29).
Proof: In Appendix C, we show that the sets of λ described in this proposition and Theorem 1 are equal, completing the proof. Furthermore, the result also applies to Markov-modulated arrivals, as Theorem 1 does.
By Proposition 2, we claim that the proposed database placement policy can lead to maximum throughput.

DATABASE REPLACEMENT POLICIES
In this section, we show the benefits of database replacement under restricted transmission rate (see footnote 2), which is referred to as replacement rate, and develop replacement policies to deal with time-varying service demand statistics.

Existence of Low-Rate Replacement
In Section 3.3, we illustrate the benefits of database replacement assuming "arbitrary" and "immediate" database replacement, which can impose extremely high requirement for transmission resources. In the following proposition, we show that the same throughput performance can be achieved under arbitrarily low transmission rates. Proof: See Appendix D.2.2. A key ingredient of the designed reference policy to reduce the transmission resource requirement is the time frame structure. To be specific, we consider a two-timescale system, where processing and transmission decisions are made on a per time slot basis, and database replacement decisions are made on a per time frame basis, with each frame including T consecutive slots. The replacement is launched at the beginning of each frame, and must be completed at the end of the frame. While the policy remains throughput-optimal regardless of T , the required replacement rate can be arbitrarily close to zero by pushing T → ∞, with a tradeoff in the queue backlog (and thus the delay performance).
In the rest of the section, we adopt the time frame structure and design two heuristic database replacement policies, based on estimated popularity distribution and database score, respectively. We note that the proposed design is flexible with incorporating advanced prediction techniques, which plays the same role as estimation, but can enhance the timeliness of the quantities. 4  Fig. 6. The (i.e., red, blue, and green) min-ERs to deliver the AR service (as shown in Fig. 2) over the network, assuming that node 1, 2, and 3 are selected as the static source, respectively.

Rate-Based Replacement
The first policy is a natural extension to the max-throughput database placement policy described in Section 5. To handle time-varying demand statistics, we calculate the empirical popularity distribution over each frame T , i.e., based on which an MILP problem (35) can be formulated, whose solution instructs the database replacement at all network nodes. While straightforward, this policy exhibits three limitations. First, it neglects the existing network loads, which can lead to sub-optimal solution. Second, the new database placement is designed independent with the current placement, neglecting the incurred replacement rate. Finally, it requires solving the MILP problem in an online manner, which can reduce the accuracy of the approximate solution.

Score-Based Replacement
The second policy is motivated by the derived "min-ER" rule for route selection, giving rise to a metric, referred to as (database) score, to evaluate the benefit for each node i to cache a given database. Definition 2 (Score). For each instance, i.e., an arrival packet ψ and given network states (queuing states, database placement), the score of database k at node i is the difference of the min-ER weights assuming node i does not cache the database, and the opposite, given by where W ⋆ (x) is the min-ER weight given by Algorithm 1, with x − (i, k) and x + (i, k) denoting the caching vectors equal to x, except for 0 and 1 in the entry of x i,k .
For a given database k, at the static source node, the score is the increment of the min-ER weight if it does not cache database k; otherwise, the score is the reduction of the min-ER weight if the node caches database k. As illustrated in Fig. 6: denote by W 1 , W 2 , and W 3 the weights of the red, blue, and green ERs, respectively, with W 3 < W 1 < W 2 , and we note that node 1 is selected as the static source in the actual network (since node 3 does not cache the database, and node 2 incurs a higher weight). The database ... Fig. 7. The studied edge cloud, including edge servers (node 1 to 9) and a cloud data-center (node 10). The black and blue edges represent links for user request delivery and database replacement, respectively.
score at each node is derived as follows. Node 1: if it does not cache database k, node 2 will be selected, leading to a greater weight of W 2 , and v 1,k = W 2 − W 1 . Node 2: if it does not cache database k, the cache selection decision does not change, leading to the same weight of W 1 , and v 2,k = W 1 − W 1 = 0. Node 3: if it caches database k, node 3 will be selected as the static source, leading to a reduced weight of W 3 , and v 3,k = W 1 − W 3 . We note that the definition for score (i) assumes unchanged caching policy at the other network nodes, and (ii) requires finding min-ERs under different placements, which can lead to different processing decisions. In addition, (37) is the score for a single instance, and the sum score of all instances within a time frame, is a proper metric to evaluate the overall database score, i.e., Given the obtained database scores, we formulate the following optimization problem to decide the database placement at each node i ∈ V: i.e., finding the admissible placement to maximize the total score. The above problem, known as 0/1 knapsack problem, admits dynamic programming solution with pseudopolynomial complexity O(|K|S i ) [40], and we denote its optimal value and solution by V ⋆ i and x ⋆ i . Finally, we find the node with the largest total score, i.e., i ⋆ = arg max i V ⋆ i , and only replace its databases according to x ⋆ i ⋆ . We refer to the update rule as asynchronous update, which is in line with the definition of score assuming unchanged databases at the other network nodes.
There are three factors that can impact the performance of this policy. First, the proposed score metric focuses on each individual node (for tractability), and cannot capture the interaction between network nodes. Second, we use the observed the queuing states to calculate the score, which are also impacted by the database placement. Finally, the asynchronous update can be less efficient for database replacement and lead to slower adaption.

Experiment Setup
Consider a grid MEC network composed of 9 edge servers and a cloud data-center, connected by wired links, as shown in Fig. 7. Each edge server is equipped with 4 processors of frequency 2.5 GHz, and the transmission capacity of each wired link between them is 1 Gbps. The cloud datacenter is equipped with 8 identical processors, and the transmission capacity of each backhaul link (for service delivery) is 20 Mbps. The length of each time slot is 1 ms. There are 4 clients requesting different services, each including 2 functions, with parameters shown in Table 2. The size of each packet is 1 kb, and the arrivals are modeled by i.i.d. Poisson processes with λ Mbps.
There are 8 databases, and each of them has the same size of F = 1 Gb, and the storage capacities are in number of databases. The cloud data-center stores all databases.
We employ two benchmark algorithms for comparison: 5 • Static-to-live (S2L), which makes individual routing decisions for live data [17], and selects the nearest static sources to create objects for the processing locations along shortest paths (in weighted ALG).
• Live-to-static (L2S), which brings live data to the nearest (in weighted ALG) static source for processing. 5. Both S2L and L2S do not consider joint control of multi-pipelines: they focus on the load to transmit either live data, or static objects.

Network Stability Region
First, we study the network stability regions attained by the algorithms, and depict the average delay under different arrival rates (which is set to ∞ if the network is not stable).
As shown in Fig. 8a, DI-DCNC attains good delay performance over a wide range of arrival rates; when λ crosses a critical point (λ 1 ≈ 1.05 Gbps), at which point the average delay blows up, indicative of the stability region boundary. Similar behaviors are observed from S2L and L2S, and we find that DI-DCNC outperforms them in terms of the achieved throughput: 1.05 Gbps (DI-DCNC) > 920 Mbps (L2S) > 660 Mbps (S2L). Therefore, compared to S2L and L2S, DI-DCNC can better exploit network resources to improve the throughput. We clarify that the performance of S2L improves when increasing the transmission resources, and can outperform L2S under some configurations [1].
We also notice that the delay attained by DI-DCNC is very similar and not lower than both benchmarks in lowcongestion regimes. As discussed in Section 4.4.3, DI-DCNC is designed to reduce the aggregate queuing delay of both live and static data pipelines; such objective -while closely related to (especially in high-congestion regimes) -is not exactly equivalent to the actual service delay, which (i) depends on the maximum delay between the two concurrent pipelines, and (ii) depends also on the hop-distance of the path, neglected by DI-DCNC.

Resource Occupation
Next, we compare the resource occupation of the algorithms. Assume that the available processing/transmission capacities at each node/link are α 1 and α 2 (in percentage) of corresponding maximum budgets, respectively, and we define the feasible region as the collection of (α 1 , α 2 ) pairs under which the delay requirement is fulfilled. Assume λ = 500 Mbps and average delay requirement = 30 ms.    Since a lower latency can be attained with more resources, i.e., (α 1 , α 2 ) → (1, 1), the feasible regions are to the upper-right of the border lines. 6 As we can observe, DI-DCNC can save the most network resources. In particular, when α 1 = α 2 = α, the resource saving ratios, i.e., 1 − α, of the algorithms are: 50% (DI-DCNC) > 43% (S2L) > 24% (L2S). Another observation is: S2L is transmissionconstrained, compared to its sensitivity to processing capacity. To wit: in the horizontal direction, it can achieve a maximum saving ratio of around 70% (when α 2 = 1), which is comparable to DI-DCNC; while the maximum saving is 25% for transmission resources (when α 1 = 1), and there is a large gap between the attained performance and that of DI-DCNC (≈ 50%). The reason is that S2L ignores the transmission load of static objects, leading to additional transmission resource consumption. In contrast, L2S is processing-constrained, because only the processing resources at static sources are available for use.

Joint 3C Resource Orchestration
Then, we evaluate the proposed database placement and replacement policies, using DI-DCNC for flow control.

Fixed Placement
First, we focus on the setting of fixed database placement. We assume each edge server can cache S databases, and employ two random policies as benchmarks: • Random placement: each edge server caches S different databases, that are jointly selected to maximize the database diversity in all edge servers. 7 • Random selection: each edge server randomly selects S different databases to cache. 6. We note that the feasible region achieved by S2L is not convex. 7. The cached databases at all edge servers are selected as follows. Generate a random permutation of sequence {1, · · · , |K|}, repeat it for ⌈|V|S/|K|⌉ times, and denote the resulting sequence by D and its ith element by D i . Then, databases D (i−1)S+1 , · · · , D iS are cached at edge server i. Note that they are different databases because every subsequence in D with length S ≤ |K| does not include repeated value. Similar performance metrics, i.e., network stability region and resource occupation, are used to evaluate the policies, and the results are summarized in Fig. 9.
(i) Network Stability Region: In Fig. 9a, we present the stability region attained by the proposed placement policy, together with the optimal throughput derived from the MILP (35) (for the random policies with given placement x, the MILP problem reduces to linear programming).
For each policy, the attained throughput grows with the storage resource, and the proposed policy outperforms the random benchmarks, especially with limited storage resources. For example, when S = 1, the proposed policy achieves the best performance (≈ 1.59 Gbps), which is 37% better than random placement and far beyond random selection. The result validates the effects of "where to cache the databases", in addition to "which databases to cache", on the throughput performance. Finally, the stability regions collected in the experiments agree with the results derived from MILP, validating Proposition 2.
(ii) Resource Occupation: Next, we study the tradeoff between multi-dimensional (processing, transmission and storage) network resources, assuming λ = 1 Gbps, average delay requirement = 30 ms, and α 1 = α 2 = α. For each random benchmark, we select a representative placement that attains a throughput performance closest to the corresponding mean value (as shown in Fig. 9a).
As depicted in Fig. 9b, with more storage resources at the edge servers, a larger saving ratio of processing and transmission resources can be attained. In particular, the performances of the three policies converge when each node has sufficient space to cache all databases (i.e., S = |K|). When the storage resource is limited (e.g., S = 1), the proposed design can achieve a processing/transmission resource saving ratio (69%) close to the optimal value (around 67%), outperforming the two random benchmarks.

Replacement Policies
Finally, we evaluate the proposed database replacement policies. The arrivals are modeled by Markov-modulated process, i.e., the arrival rate follows a Markov process (described in the following), and the arrivals at each time slot is a Poisson variable. Popularity distribution at each time  slot is a permutation of the Zipf distribution with γ = 1 [35], with the initial order generated randomly; at each time slot, w.p. 10 −6 , we randomly select a number ϕ ∈ {1, 2, 3}, and exchanges the popularity ranking of the ϕ-th and (ϕ + 1)-th most popular services, i.e., their arrival rates. 8 Each edge server, except node i = 4, 5, 6, is allowed to cache S = 1 database, 9 and the database placement is given by the proposed max-throughput policy assuming uniform popularity distribution. The two proposed replacement policies are evaluated, and for fair comparisons, we set equal running time for the two policies (to calculate the estimated quantities and solve corresponding problems).
The results are shown in Fig. 10. Fig. 10a plots the throughput performance of the two replacement policies, both of which effectively boost the throughput performance (≈ 1 Gbps) compared to fixed placement (≈ 0.5 Gbps), despite the slightly worse delay performance in lowcongestion regimes (e.g., λ ≤ 400 Mbps). Fig. 10b demonstrates the effects of (time) frame size on the throughput performance and replacement rate requirements of the two policies. With growing frame size, the frequency of database replacement reduces, leading to sub-optimal throughput, with reduced replacement rate requirement. 10 Comparing the two proposed policies, we find that: rate-based policy can achieve better throughput, which is also less sensitive to the frame size (note that the blue-solid curve is more flat); while score-based policy achieves a much lower cost, which updates the placement based on current network states and in an asynchronous fashion.

CONCLUSIONS
We investigated the problem of joint 3C control for the online delivery of data-intensive services, in which each 8. Under this setting, the expected time for the popularity distribution to change is 10 6 ms ≈ 15 min; in addition, the time average arrival rate for all services are equal (i.e., uniform popularity).
9. Under this setting, the total storage resources at the edge servers are 6 and cannot support caching all the databases (since |K| = 8), which is a common scenario in practical systems. 10. The selection of frame size controls the tradeoff between the accuracy and timeliness of the estimate. The tradeoffs can be observed from the score-based policy (selecting the frame size as 5 ms achieves maximum throughput), but is negligible in the rate-based policy. service function can include multiple input streams. We first characterized the network stability regions based on the proposed ALG model, which incorporates multiple pipelines to deal with corresponding inputs. We then addressed two problems: (i) multi-pipeline flow control, in which we derive a throughput-optimal control policy DI-DCNC to coordinate processing, routing and cache selection decisions for multiple pipelines, and (ii) joint 3C resource orchestration, in which we designed a max-throughput database placement policy that jointly optimizes 3C decisions, as well as the rate-based and score-based policies for database replacement. Via numerical experiments, we demonstrated the superior performance of multiple pipeline coordination and integrated 3C design in delivering next-generation dataintensive real-time stream-processing services.

APPENDIX A NECESSITY OF ROUTE-BASED CHARACTERIZATION
Consider an arrival process a(t) = {a (c) (t) : ∀ c} and the policy able to support it, i.e., keeping the actual queues stable. Let A (c,σ) (t) be the amount of requests of client c that are successfully delivered via ER σ by time t.
By the conservation of packets: where Y (c) (t) is the amount of live packets associated with client c and staying in the network by time t. Divide it by t, let t → ∞, and note the following facts: because the queues are stable, and the arrival process is i.i.d.
(the relationship is the definition of λ (c) if the arrival is modeled by Markov-modulated process, i.e., time average arrival rate). In addition, define and (40) becomes On the other hand, the total resource consumption at each interface e (each interface e can be a node i ∈ V or a link (i, j) ∈ E, which uses the available processing/transmission resources to handle the packets) cannot exceed the corresponding capacity: Divide it by t, let t → ∞: which is (10), concluding the proof.

APPENDIX B THROUGHPUT-OPTIMALITY OF DI-DCNC
We will prove the theorem in two steps, by showing (i) the stability of the virtual queues under the virtual routing decisions (20), and (ii) the stability of the actual queues under DI-DCNC (which incorporates ENTO scheduling).

B.1 Stability of Virtual Queues
Suppose the arrival vector λ satisfies (10), i.e., there exists probability values P c (σ) such that for each interface e: or equivalently: there exists ǫ ≥ 0, such that for ∀ e (note that ǫ = 0 satisfies the condition). Define a reference policy * operating as follows: at each time slot, select the ER σ to deliver the requests of client c w.p. P (σ) c . Denote the associated route selection decision by a * (c,σ) (t), and the additional resource load imposed on interface e is given by (in the virtual system): and thus: On the other hand, the virtual queue drift can be derived as follows. Take square of (14): with Therefore, and the overall normalized drift is bounded by with B = e∈V ∪ E B e /C 2 e , and inequality (a) is due to the proposed route selection decision minimizing the bound.
B.1.1 I.I.D. Arrival Take expectation of (53), and we obtain: In inequality (b), we use the fact that the decisions made by * are independent with the current queuing status, and thus expectation multiplies. In fact, (54) implies that the virtual queues are rate-stable [14, Section 3.1.4].

B.1.2 Markov-Modulated Arrival
Under Markov-modulated arrival process, (54) is violated becauseã * e (t) and Q e (t) are dependent (since both of them depend on the arrival in previous time slot, i.e.,ã * e (t − 1)), and we employ the multi-slot drift technique [14,Section 4.9] to show the stability of the queues. Lemma 1. The multi-slot drift of interval [t, t+T −1] ensures that: Proof: For each interface e, we can verify: 57) in which we use the fact that C e −ã e (t) ≤ √ 2B e . Iterating the queuing dynamics, we obtain: for any s ≥ t, and furthermore Divide the result by C 2 e and substitute it into the multi-slot drift, i.e., the sum of one-slot drifts (53), and we obtain: which is (55). Assume the state space (of the underlying Markov process) has a state "0" that we designate as a "renewal" state. Let sequence {t r : r ≥ 0} represent the recurrence times to state 0, and T r = t r+1 − t r . By renewal theory, we know that T r are i.i.d. random variables (and we denote its first and second moment by E {T } and E T 2 , respectively), and Take (conditional) expectation of (55), use the above result, and we can obtain (63), where we plug in (47) to derive (c). Then take expectation with respect to Q(t r ), and the result implies that the virtual queues are rate stable [14,Theorem 4.12].

B.2 Stability of Actual Queues
We will show that the total backlog of actual queues, i.e., is rate stable, where denote the backlogs of waiting queues and processing/ transmission queues.

B.2.1 An Equivalent Problem
We first derive an equivalent problem in this section. Note that the waiting queue R ′ (t) can be bounded by a linear function of the processing/transmission queue R(t), i.e., where M max = max φ M φ , and Z max = max φ Z φ in which Z φ denotes largest ratio of the sizes of any two packets associated with service φ. The above inequality is valid because: for any packet staying in the waiting queue R ′ (t), its associate must be in transit and thus collected in some processing/transmission queue, i.e., a component of R(t).
In the coefficient, factor M max results from multi-step processing, i.e., there can be multiple packets associated with a given request staying in the waiting queue, and the number is bounded by M φ − 1 (in which case M φ − 1 static objects wait for one in-transit live packet) and thus M max ; factor Z max accounts for the difference in the data packet size of the waiting and in-transit packets. Substitute it into (64), and R tot (t) is also bounded by a linear function of R(t), which implies that prove that R tot (t) and R(t) have the same stability property.
Furthermore, we define the processing/transmission resource load process at each network location, i.e., where ψ denotes a packet in the processing queue R i (t), and r ψ the corresponding workload. Due to the linear relationship between R(t) andR(t), the remaining problem is to show thatR(t) is rate stable.

B.2.2 Stability of R(t)
We note that this part of proof is an extension to [15, Appendix D] (dealing with the simplified communication network setting). Denote byR (κ) (t) the resource load incurred by all hop κ packets (i.e., a packet that is κ hops away from its source in the ALG),R e (t) the resource load at interface e, andR For any interface e, and time t 0 and t, denote by A e (t 0 , t) the additional resource load imposed on, and S e (t 0 , t) the resource served at, interface e during [t 0 , t]; then, where o(t) is a non-decreasing function, satisfying which is proved in [17]. Furthermore, letã (κ) e (t 0 , t) be the additional resource load, imposed by exogenously arriving requests during [t 0 , t], such that link e is its κ-th hop in the assigned route. Note that because A e (t 0 , t) includes packets already in the network before time t 0 . Then, we show the Proposition:R (κ) (t) ≤ B (κ) (t) where B (κ) (t) is a non-decreasing function, satisfying lim t→∞ B (κ) (t)/t = 0. Assume empty queues at time 0.
Base case: Let t 0 be the largest time when there is no hop 0 packets waiting for operation at interface e. Theñ and thus and by assumption, the Proposition holds.
is a non-decreasing function, satisfying lim t→∞ B (j) (t)/t = 0 for j = 0, · · · , κ − 1. Let t 0 be the largest time when there is no hop κ packets waiting for operation at interface e.
First, we focus on the resource load incurred by hop κ packets arriving at e during [t 0 , t], which are either (i) packets that were hop 0, · · · , κ − 1 at time slot t 0 , or (ii) exogenously arriving requests during [t 0 , t] that have e as its κ-th hop. Therefore, the resource load incurred by hop κ packets at interface e is bounded by: whereΞ max is a constant factor handling the scaling of (i) data size due to processing, and (ii) processing/transmission resource units (because the edges in the ALG can be processing/transmission edges), given bỹ Second, we consider the available resource to serve hop κ packets, which is denoted by S (κ) e (t 0 , t) and satisfies: where (75b) is the resource consumed by packets of a higher priority (i.e., hop 0, · · · , κ − 1 packets). By definition, the remaining resource load incurred by hop κ packets satisfies: and thusR in which Therefore, the Proposition holds for case κ. By induction,R (κ) (t) are stable for all κ, and so is the sum of them, i.e.,R(t), concluding the proof.

APPENDIX C FLOW-BASED CHARACTERIZATION
We will show that an arrival vector λ satisfies (10) (referred to as route-based characterization) if and only if it satisfies (25) -(29) (referred to as flow-based characterization).
We will show that for each ER σ, the square bracket equals 0. For each node i m in the ALG, one of the following two cases must be true: 1) i m / ∈ σ: all terms are equal to 0, and (82) holds; 2) i m ∈ σ: the node must have exactly one incoming and one outgoing edge in the live data pipeline (i.e., one positive term and one negative), and by (12): m . Therefore, in any case, the square bracket equals to Ξ To sum up, (82) holds for each intermediate node in the ALG. The conservation of live flow at source and destination nodes, as well as static flows, can be verified in a similar way and thus is omitted.

C.2 Sufficiency
Next, we show that for any flow variables f, f ′ satisfying (25) - (29), there exists probability values associated with the possible ERs satisfying (10).

C.2.1 Path-Finding for Stage m Live Flow
We divide the problem by (i) live and static pipelines, and (ii) by different processing stages. In particular, we focus on the stage m ∈ {1, · · · , M } live flow of client c.
Define a graph, whose node and edge sets are given by: where V and E denotes the node and link sets of the actual network, and u and v can be interpreted as the super source and destination. In addition, each edge is assigned the following capacity: imjm . Take (u, v) as the source-destination pair, and the maxflow of the above graph is given by i∈V E ui , because: (i) {E ij } is a set of feasible flow variables satisfying flow conservation constraint (imposed by the linear programming formulation of the max-flow [37, Section 29.2]), and the resulting flow i∈V E ui is an achievable value; (ii) while the max-flow is bounded by the total capacity of outgoing links from the source, which equals to the same value.
By running some standard max-flow algorithms, we can find a set of paths (from u to v) achieving the maxflow, e.g., Edmonds-Karp algorithm, which finds the shortest augmented path [37,Section 26.2] in each iteration (and thus is acyclic). We denote a path found by the algorithm by p, with associated rate (i.e., bottleneck of the augmenting path in the algorithm) denoted by β (p) 1 ; besides, denote by p(src) and p(des) the first and last nodes other than u, v in path p, representing its source and destination.
We can find paths for static flows by the same procedure, except that we use the super static source o ′ m instead of the super source introduced above. A found path is denoted by q with an assigned rate of β (q) 2 .

C.2.2 Composition of Individual Paths
Next, we compose the separate paths into ERs and define the associated probability values for them.
First, we compose the paths of live and static flows of the same stage. For each node i, denote the set of all incoming live and static paths by: As illustrated in Fig. 11, we align the percentiles (i.e., cdfs) of the live and static paths, resulting in |σ  c } that equal to the length of corresponding segments.
It is clear that no additional resource loads are imposed on any network location, and thus the incurred resource consumption (which can be represented by {P (σ) c }) does not violate the capacity constraints (25), leading to (10).

D.1 Necessity
Consider an arrival process a(t) = {a (c) (t) : ∀ c} and the policy able to support it, i.e., keeping the actual queues stable. Fix a time interval [0, t − 1], and denote by x(τ ) the database placement at time τ , T (x) the set of time slots with database placement x, and a (c,σ) (τ ) the number of requests of client c emerging at time τ and successfully delivered by the end of the interval (i.e., time t − 1). Define and without loss of generality, we assume P(x) > 0 (otherwise, we can exclude x from X ). By the conservation of requests of client c emerging at time τ ∈ T (x): where Y (c,x) (t) is the amount of such packets staying in actual queues at time t. Divide it by |T (x)|, let t → ∞: a (c) (τ ) = λ (c) .

(88)
In addition, define and (87) becomes On the other hand, the total resource consumption (up to time t) at each interface e ∈ V ∪ E satisfies: which is (13), concluding the proof.

D.2 Sufficiency
Suppose the arrival vector λ satisfies (13), i.e., there exists probability values P(x), P c,x (σ) such that: for each interface e, and we will define a randomized route selection policy to keep the virtual queues stable. 11

D.2.1 Initial Design
We first assume that: "each node can complete arbitrary database replacement immediately", i.e., the caching vector x(t) ∈ X can be different at each time slot, and we define a reference policy * operating as follows: at each time slot, (i) select the database placement x w.p. P(x), (ii) select the ER σ to deliver the requests of client c w.p. P c,x (σ).
11. Then following the same procedure as presented in Appendix B.2, we can show that: under the policy combining the designed route selection policy and ENTO, the actual queues are rate-stable.
Following the procedure in Appendix B.1, the normalized virtual queue drift is given by: satisfying C e −ã e (t) ≤ 2B ′ e , and which implies that the virtual queue of each interface e is rate-stable [14, Section 3.1.4].

D.2.2 Low-Cost Replacement
In this section, we aim to design a policy in a realistic setting assuming restricted transmission rate for database replacement. Consider a two-timescale system, where processing and transmission decisions are made on a per time slot basis, and database replacement decisions are made on a per time frame basis, with each frame including T consecutive slots. Define a reference policy * operating as follows: (i) at the beginning of each frame, select the database placement x w.p. P(x), (ii) at each time slot, select the ER σ to deliver the requests of client c w.p. P c,x (σ).
Let sequence {rT : r ≥ 0} represent the starting time slots of the time frames. According to Lemma 1, the multislot drift of interval [rT, (r + 1)T − 1] is give by: Apply the telescope sum [14] for r ∈ [0, R − 1]: and therefore, for any point interior to the stability region, i.e., ǫ > 0, In addition, we note that: Therefore, the average virtual queue backlog over interval [0, t − 1], with t = RT + ∆t (0 ≤ ∆t < T ), is given by i.e., the virtual queues are mean rate stable.
On the other hand, policy * incurs a cost of To sum up, policy * achieves an [O(T ), O(1/T )] tradeoff between average (virtual) queue backlog and replacement rate. While the policy remains throughput-optimal regardless of T , the attained replacement rate can be arbitrarily close to zero by pushing T → ∞, with a tradeoff in the queue backlog (and thus the delay performance).

APPENDIX E EQUIVALENCE OF THE MILP FORMULATION
Fix the database placement x, and we will show that the remaining problems of (32) and (35) are equivalent. Suppose x i,k = 1, and we note that since the two terms on the left hand side are bounded by corresponding components of C max i,k (34), given that the flow variables satisfy the capacity constraints (25). Therefore, no additional constraints is imposed on the flow variables by (33), equivalent to (28). Suppose x i,k = 0, in which case (33) transforms to and it holds with equality for any solution satisfying (28). Reversely, consider any flow assignment satisfying (33) with inequality, i.e., the total incoming flow is strictly greater than the outgoing flow, which essentially results from the excessive static flow produced by the static sources. Then, we can reduce the incoming flow rate f ′(k) ji to make it an equality at node i, and repeat the same procedure for all neighbor nodes j ∈ δ − i impacted by the change, which terminates upon meeting the static sources j ∈ V(k (φ) m ).