## Appendix B GP-LLC Algorithm Specification  
In this paper, we have compared our E2-D4 QN agent with a greedy policy lowest-latency and lowest-cost (GP-LLC) SFC deployment agent. Algorithm 11 describes the behavior of the GP-LLC agent. Note that the lowest-latency and lowest-cost (LLC) criterion can be seen as a procedure that, given a set of candidate hosting nodes, \(N_{H}^{k}\) chooses the correct hosting node to deploy the current VNF request \(\hat{f}_{r}^{k}\) of a SFC request \(r\). Such a procedure is at the core of the GP-LLC algorithm, while the outer part of the algorithm is responsible for choosing the hosting nodes that form the candidate set according to a QoS maximization criterion. The LLC criterion woks as follows. Given a set of candidate hosting nodes and a VNF request, the LLC criterion will divide the candidate nodes in subsets considering the cloud provider they come from. It will then chose the hosting node corresponding to the route that will generate less transportation delay, i.e., the fastest route, from the cheapest cloud-provider candidate node subset.  
The outer part of the algorithm acts instead as follows. Every time that a VNF request \(\hat{f}_{r}^{k}\) needs to be processed, the GP-LLC agent monitors the network conditions. The agent identifies the hosting nodes that are currently not in overload conditions, \(\hat{N}_{H}\), the ones that currently have a resource provision that is less than the maximum for all the resource types \(\hat{N}_{H}\), and the hosting nodes that currently have a \(f_{k}\) ingesting the content from the same content provider requested by \(\hat{f}_{r}^{k}\), \(N_{l}^{k}\) (lines 2-4). Notice that \(\hat{N}_{H}\) is the set of nodes whose resource provision can still be augmented by the VNO. Notice also that choosing a node from \(N_{l}^{k}\) to assign \(\hat{f}_{r}^{k}\), implies not to incur in a Cache MISS event and consequently warrants the acceptance of \(r\). If \(\hat{N}_{H}\cap\hat{N}_{H}\) is not an empty set, the agent assigns \(\hat{f}_{r}^{k}\) to a node in such a set following the LLC criterion. However, if \(\hat{N}_{H}\cap\hat{N}_{H}\) is an empty set, then if at least \(\hat{N}_{H}\) is not empty, then a node from \(\hat{N}_{H}\) will be chosen using the LLC criterion. If on the other hand, \(\hat{N}_{H}\) is empty, then a node from \(\hat{N}_{H}\) will be chosen with the LLC criterion.  
Finally, if both \(\hat{N}_{H}\) and \(\hat{N}_{H}\) are empty sets, then a random hosting node will be chosen for hosting \(\hat{f}_{r}^{k}\) (lines 5-16). Choosing a random node in the last case instead of using the LLC criterion from the whole hosting node will prevent bias in the assignation policy to cheap nodes with fast routes. Making such a random choice will then result in an increment in the overall load balance among the hosting nodes.  
Notice that, whenever possible, GP-LLC will evict overloading nodes with assignation actions and will always choose the best actions in terms of QoS. Moreover, given a set of candidate nodes respecting such a greedy QoS-preserving criterion, the inner LLC criterion will tend to optimize hosting costs and data-transmission delays. Notice also that GP-LLC does not take into account data-transportation costs for VNF SFC deployment.  
```
1:for\(f_{r}^{k}\in r\)do
2: Get the non-overloaded hosting nodes set \(\hat{N}_{H}\)
3: Get the still-scalable hosting nodes set \(\hat{N}_{H}\)
4: Get the set of hosting nodes that currently have a \(f^{k}\) ingesting \(l_{r}\) on \(N_{l}^{k}\)
5:if\(|\hat{N}_{H}|>0\)then
6:if\(|\hat{N}_{H}\cap\hat{N}_{H}|>0\)then
7: use the LLC criterion to chose \(f_{r}^{k}\) from \(\hat{N}_{H}\cap\hat{N}_{H}\)
8:else
9: use the LLC criterion to chose \(f_{r}^{k}\) from \(\hat{N}_{H}\)
10:endif
11:else
12: if\(|\hat{N}_{H}|>0\)then
13: use the LLC criterion to chose \(f_{r}^{k}\) from \(\hat{N}_{H}\)
14:else
15: choose a random node \(f_{r}^{k}\) from \(|\hat{N}_{H}|\)
16:endif
17:endif
18:endfor
```  
**Algorithm A1** GP-LLC VNF Assignation procedure.