Source-linked AI summary
EmuFog: Extensible and Scalable Emulation of Large-Scale Fog Computing Infrastructures
Ruben Mayer, Leon Graser, Harshit Gupta, Enrique Saurez, Umakishore Ramachandran
TL;DR
Fog research lacks accessible public infrastructure for repeatable, controllable testing of applications and policies. EmuFog provides an extensible framework for constructing Fog topologies and emulating real applications; its experiments show different latency responses on BRITE and CAIDA topologies.
Problem
Fog infrastructure diversity and limited public access make repeatable, controllable testing of applications and resource-management policies challenging.
Source: §I · p. 1, B. Test Environments for Fog Computing · p. 2Method
EmuFog extends MaxiNet with customizable Fog-topology generation and node placement, including a latency-based policy for placing Fog nodes.
Source: §I · p. 1, C. Topology Enhancement · p. 3Results
BRITE latency rises nonlinearly as threshold T increases, while latency on CAIDA topologies varies little across thresholds.
Source: 1) Edge Identification · p. 5, 2) Fog node placement · p. 5Takeaways & Limitations
EmuFog supports topology-specific Fog-node placement experiments, with placement latency responding differently across BRITE and CAIDA topologies.
Source: 1) Edge Identification · p. 5, 2) Fog node placement · p. 5
Abstract
from arXiv · showhide
The diversity of Fog Computing deployment models and the lack of publicly available Fog infrastructure makes the design of an efficient application or resource management policy a challenging task. Such research often requires a test framework that facilitates the experimental evaluation of an application or protocol design in a repeatable and controllable manner. In this paper, we present EmuFog---an extensible emulation framework tailored for Fog Computing scenarios---that enables the from-scratch design of Fog Computing infrastructures and the emulation of real applications and workloads. EmuFog enables researchers to design the network topology according to the use-case, embed Fog Computing nodes in the topology and run Docker-based applications on those nodes connected by an emulated network. Each of the sub-modules of EmuFog are easily extensible, although EmuFog provides a default implementation for each of them. The scalability and efficacy of EmuFog are evaluated both on synthetic and real-world network topologies.
I. INTRODUCTION
Fog architectures differ, so applications and resource policies need repeatable testing against their target infrastructure; accessible public Fog infrastructure is lacking. EmuFog addresses this gap with an extensible framework for designing Fog topologies and emulating real applications.
I. INTRODUCTION
- Different Fog architectures affect application design and performance, making infrastructure-aware testing of resource-management systems important.Testing should be repeatable and controllable so applications and protocols can be debugged and tuned before deployment.Source: §I · p. 1
- The lack of easily accessible public Fog infrastructure makes a test environment for application development and deployment necessary.Source: §I · p. 1
- EmuFog is an extensible Fog emulation framework built on MaxiNet, supporting repeatable, controllable experiments with real applications.The paper contrasts emulation with simulation and real-world testbeds.Source: §I · p. 1
- Users can generate or import a network topology, place Fog nodes according to policies and specified capabilities and workloads, then feed the result into MaxiNet.Topology generation and placement can be customized, with standard implementations also provided.Source: §I · p. 1
II. BACKGROUND
Fog Computing extends cloud resources toward users, with infrastructure spanning network domains. In this paper, “close to users” covers locations from the network core to its edge.
A. Fog Computing
- Fog Computing brings compute, storage, control, and networking services closer to users as an extension of Cloud Computing.Source: A. Fog Computing · p. 1
- Here, “close to users” means any point between data centers at the network core and users at its edge.Source: A. Fog Computing · p. 1
- Fog infrastructure spans multiple network domains that coordinate as an ecosystem for enhanced application delivery.Source: A. Fog Computing · p. 1
B. Test Environments for Fog Computing
Fog research needs repeatable, configurable tests that can run real applications, while general-purpose emulators make large-scale Fog-node placement burdensome. EmuFog builds on MaxiNet and targets scalable, workload-capable, extensible Fog emulation.
B. Test Environments for Fog Computing
- iFogSim [7] uses discrete-event simulation to measure latency, energy consumption, and network usage, while general-purpose emulators require manual Fog-node placement that is infeasible at large scale.The paper motivates a Fog-specific emulation framework to reduce the effort of experimentation.Source: B. Test Environments for Fog Computing · p. 2
- MaxiNet spans multiple machines and has emulated a 3,200-host datacenter network on 12 physical machines, so EmuFog uses it as its emulation foundation.EmuFog extends MaxiNet with native support for Fog Computing scenarios.Source: B. Test Environments for Fog Computing · p. 2
III. DESIGN AND IMPLEMENTATION
- The design and implementation section details EmuFog’s components, including algorithms for placing Fog nodes in imported network topologies.Source: §III · p. 2
A. Design Objectives
- EmuFog targets scalability for large network topologies, enabling developers to study large-scale Fog Computing scenarios.Source: A. Design Objectives · p. 2
- EmuFog lets developers package applications and run them with real workloads in the emulated environment to test Fog policies and applications at scale.Source: A. Design Objectives · p. 2
- EmuFog’s components can be replaced or extended with custom-built components suited to the emulated scenario or evaluated policies.Source: A. Design Objectives · p. 2
B. Workflow of Fog Computing Emulations
EmuFog’s workflow transforms generated or imported network topologies, adds Fog nodes, and deploys containerized applications for emulation. Users can customize the workflow and examine placement-policy implications.
B. Workflow of Fog Computing Emulations
- The workflow has four stages: topology generation, topology transformation, topology enhancement, and deployment and execution.Source: B. Workflow of Fog Computing Emulations · p. 2
- Topology enhancement identifies the network edge and places Fog nodes using a policy informed by node capabilities and expected edge clients.The enhanced topology is deployed with application components supplied as Docker containers on Fog nodes.Source: B. Workflow of Fog Computing Emulations · p. 2
- Flexible placements let developers test applications in different Fog environments and evaluate latency and cost implications for supporting clients.Source: B. Workflow of Fog Computing Emulations · p. 2
- Users can adapt each workflow step, while EmuFog supplies standard implementations for a broad range of emulation scenarios.Provided components include BRITE topology generation and adapters for BRITE and CAIDA topologies.Source: B. Workflow of Fog Computing Emulations · pp. 2–3, Figure 1 · p. 3
C. Topology Enhancement
EmuFog enhances network topologies with Fog nodes through extensible placement policies, including a latency-based policy that seeks to keep edge clients within a latency bound of their closest Fog node.
C. Topology Enhancement
- Because placement needs depend on operator strategy and geographic workload, EmuFog provides an extensible component for placing Fog nodes in the topology.Malandrino et al. discuss placement in terms of server utilization and application latency.Source: C. Topology Enhancement · p. 3
- EmuFog’s latency-based policy aims to bound latency between clients at the network edge and their closest Fog node, and users can extend it to consider metrics such as bandwidth.The paper describes edge identification and Fog-node placement algorithms as implementing this policy.Source: C. Topology Enhancement · p. 3
- Edge routers are client access points in an autonomous system; the approach assumes each client connects through one fixed edge router.The location of edge routers is important for placement policies that account for client-to-Fog latency.Source: 1) Identification of Edge Routers · p. 3
- The identification algorithm starts with all routers marked as edge routers, then marks inter-AS routers and high-degree routers as backbone routers.Routers connecting different autonomous systems are treated as backbone routers; edge routers above the AS's average degree are also marked as backbone routers.Source: 1) Identification of Edge Routers · p. 3
- A BFS-based connection step links disconnected backbone partitions, adding routers along paths to connect them while seeking to minimize added inter-partition routers.The algorithm then expands from connected routers and adjusts parent relations to shorten routes to the backbone.Source: 1) Identification of Edge Routers · pp. 3–4
2) Placement of Fog Nodes:
Fog-node placement seeks to cover all edge routers within a latency threshold while accounting for node capacity and deployment cost. EmuFog uses a greedy process to select candidate locations and cover the remaining edge routers.
2) Placement of Fog Nodes:
- The placement algorithm selects Fog-node types and locations so every edge router is within the latency bound of its closest Fog node.The configuration specifies each node type’s client capacity and deployment cost, as well as average client occupancy per edge router.Source: 2) Placement of Fog Nodes · p. 4
- PLACEFOGNODES takes edge routers and threshold T as inputs, considering candidate routers within T of an edge router.Candidate costs are based on the Fog-node configuration needed to serve edge routers in range.Source: 2) Placement of Fog Nodes · p. 4
- The algorithm sorts candidates by deployment cost relative to coverage, selects the first, removes the edge routers it covers, and repeats until all are covered.Coverage is the number of edge routers within threshold T of a candidate router.Source: 2) Placement of Fog Nodes · p. 4
- For each candidate, the algorithm determines a cost-optimal Fog-node configuration capable of serving the routers within its threshold range.Candidate routers are drawn from locations within T of the currently uncovered edge routers.Source: 2) Placement of Fog Nodes · p. 4
IV. EVALUATION
The evaluation examines EmuFog’s edge-identification and Fog-node-placement performance and efficacy using synthetic and real-world Internet topologies.
IV. EVALUATION
- The experiments evaluate the performance and efficacy of edge identification and Fog-node placement in EmuFog.Source: §IV · p. 4
- The synthetic topology is generated with BRITE using the Albert–Barabási model.Source: §IV · p. 4
- The real-world topology is from CAIDA and was measured in 2014.Source: §IV · p. 4
A. Performance
Edge-identification latency rises linearly with BRITE topology size, while CAIDA results show a non-monotonic increase and greater deviation. The evaluation measures preprocessing latency across topology sizes and datasets.
A. Performance
- The tests use autonomous systems of 10, 100, 1,000, and 10,000 nodes, with five samples and five runs per size.BRITE systems have exactly n nodes; CAIDA systems are selected within ±5% of n.Source: A. Performance · pp. 4–5
- BRITE edge-identification latency rises linearly with AS size, while CAIDA latency increases non-monotonically with greater deviation.The authors suggest the CAIDA variation may relate to the difficulty and error-proneness of measuring Internet topology.Source: Figure 2 · p. 5, A. Performance · p. 5
- The evaluation measures latency for EmuFog’s two preprocessing steps: edge identification and Fog-node placement.Source: A. Performance · p. 5
- Edge identification has expected O(|V| + |E|) complexity, with bounded router degree implying growth linear in router count.Source: A. Performance · p. 5
1) Edge Identification:
The evaluated algorithm’s running time scales with router count in both datasets, while increasing the latency threshold affects latency differently across topology types.
1) Edge Identification:
- For both datasets, running time increases proportional to the number of routers.Source: 1) Edge Identification · p. 5
- In BRITE topologies, latency increases as the threshold T increases.Source: 1) Edge Identification · p. 5
- Latency does not rise linearly with T; once T exceeds the graph diameter, latency stops increasing because the candidate-node count no longer grows.This saturation is visible on smaller graphs at T = 8 and T = 200 ms.Source: 1) Edge Identification · p. 5
2) Fog node placement:
On CAIDA topologies, placement latency varies little across threshold settings; the authors suggest lower router degree may help explain the difference from BRITE.
2) Fog node placement:
- On CAIDA topologies, placement latency barely varies as the threshold T changes.Source: 2) Fog node placement · p. 5
- The authors suggest CAIDA routers’ lower degree than BRITE-generated routers may explain the comparatively stable latency.Source: 2) Fog node placement · p. 5
B. Visualization of Topology Enhancement
The visualization illustrates topology enhancement choices, while the conclusion reports that EmuFog’s algorithms scale with topology size and that the framework is efficacious. Future work includes mobility models and hierarchical Fog infrastructures.
B. Visualization of Topology Enhancement
- The visualization marks low-degree routers as edge routers and high-degree routers as backbone routers, with Fog-node placement changing with the latency bound.It shows two edge Fog nodes in Figure 3 (a) and one backbone Fog node in Figure 3 (b).Source: B. Visualization of Topology Enhancement · p. 5