# Efficient Data Delivery Scheme for Large-Scale Microservices in Distributed Cloud Environment
## 4 Simulation Scenarios and Results  
This section delineates the evaluation scenarios of the proposed model and validates the results to support data delivery for microservice-based IoT applications. A discrete event simulation framework, SimPy [33], based on standard Python, was used to employ the pub/sub system. For the pub/sub broker locations, approximately 3000 coordinates of the Starbucks store (longitude and latitude) from [34] were used as a coordinate pool in the evaluation scenarios during the experimental analysis. Using these coordinates for broker clustering it was assumed that, depending on how far apart the brokers were located, the RTT (Round-trip time) delay between them was a random variable with a mean proportional to their distance. A uniform distribution of RTTs between pub/sub clients and cloud brokers was assumed, with the mean delay being the average delay determined from the broker's coordinate pool. Table 1 lists the other common parameter settings for our simulation scenarios. The run time for each simulation was 15 time units (TU), of which five TUs were saved for the bootstrap operations at the beginning and only tallied messages for the remaining 10 TUs.  
Other related schemes were implemented and run with similar simulation setups to obtain performance results and compare with the proposed system, called ECBC_Proposal. Specifically, a cloud-centric publish/subscribe model, known as PSCoreCloud, to which pub/sub brokers are situated in the Core Cloud, was implemented to directly serve message delivery for pub/sub clients [24]. An Edge-Cloud pub/sub broker system inspired by [PERSON] et al. [25], called PubSubCoord-like, was designed as well. In this system, edge brokers handle data delivery for nearby pub/sub customers. These brokers use the cloud broker routing service to connect all the topic channels. Furthermore, similar setups run in a previous work [35], called PSECTO, were compared with the proposed one. For comparison, three crucial metrics are discussed to assess the mentioned schemes.  
* Average Delivery Latency (ADL): This value is determined according to the end-to-end message delivery delay for each scenario on all tested subject channels from producers/publishers to consumers/subscribers.
* Average Forwarding Traffic (AFT): The data packets of the channels must be forwarded to one another by pub/sub brokers to connect joint topic channels. The AFT is calculated as the fraction of forwarded packets relative to the total number of packets delivered by brokers. This value aids in determining how effectively brokers in the system are able to bridge topics.
* Node Degree (ND): The number of connections between brokers required for data sharing on shared subject channels is known as a broker's node degree. This value reflects the effort put in by brokers to maintain topic overla  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Parameter** & **Value** \\ \hline RTT between edge-edge, edge-cloud brokers & Proportional to their distance \\ RTT between cloud brokers & Distributed uniformly between U[1, 2] ms \\ RTT between clients and edge brokers & Distributed uniformly between U[1, 4] ms \\ Number of clients per event channel per broker & 1 publisher, 10 subscribers \\ Edge Broker’s port rate & \(10^{8}\) bit per second \\ Cloud Broker’s port rate & \(10^{9}\) bit per second \\ Packet size & 64 bytes \\ Subscription distribution & Zipf \\ Simulation duration & 15 time units per setting \\ \hline \hline \end{tabular}
\end{table}
Table 1: Common parameter settings for evaluation scenarios.