From Cloud to Edge: A First Look at Public Edge Platforms

Study design

• The study combines crowdsourced measurements from 158 participants in 41 Chinese cities, controlled gaming and streaming experiments, and three months of NEP VM traces.Performance is compared with AliCloud; workload comparison uses Azure’s 2019 dataset because few cloud providers release workload traces.Source: §1 · pp. 1–2

Study scope

• The NEP–Azure workload comparison is not perfectly apples-to-apples because Azure data is mainly from the U.S. market and was collected in a different period.The authors say they draw conclusions conservatively, only when disparities are likely attributable to inherent cloud–edge differences.Source: §1 · p. 2

Latency

• NEP median RTTs are 10.5ms/34.2ms/11.7ms on WiFi/LTE/5G, 1.89×/1.42×/1.35× lower than the nearest AliCloud DC, respectively.Reduced jitter is about 5×, but NEP still cannot or barely meets delay-critical application requirements; the nearest server is a median eight hops away.Source: §1 · p. 2

Network throughput

• Throughput improves only when last-mile capacity is high enough, such as >200Mbps on 5G downlink; WiFi and LTE remain bottlenecked by the wireless hop.The introduction describes throughput as not a primary current advantage, while noting this may change if 5G shifts the bottleneck to the wired Internet.Source: §1 · p. 2

Application QoE

• Nearby NEP gaming backends reduce response delay to 91ms versus 145ms in remote clouds, while live-streaming gains are modest and delay remains 400ms without a jitter buffer.The authors attribute streaming limits partly to content processing or computation rather than the network, and suggest hardware and system-software improvements.Source: §1 · p. 2

Edge VM characteristics

• NEP VMs have higher median allocations than Azure—8 versus 1 CPUs and 32GBs versus 4GBs of memory—but mean CPU usage is 6× lower.The authors suggest over-provisioning may reflect delay-critical, temporally variable workloads and difficulty forecasting demands across locations.Source: §1 · p. 2

Resource usage, balancing, and prediction

• NEP resource usage varies up to 14× across servers at one site, 731× across sites in one province, and 3× across VMs hosting the same app.NEP workloads show stronger seasonality and are easier to predict than Azure workloads, which the authors see as an opportunity for finer-grained resource management.Source: §1 · p. 2

Monetary cost

• NEP deployments cost about 45% less on average than AliCloud, with network cost reductions up to 98%, but some hardware-heavy or variable-traffic apps may not benefit.NEP charges slightly more for hardware resources and uses coarse-grained billing, which can disadvantage those application types.Source: §1 · p. 2

2 THE NEP EDGE PLATFORM

• NEP distributes smaller sites across many locations, primarily hosts IaaS VMs, and allocates VMs by coarse geography before customers route end-user traffic to nearby sites.A site contains servers that host VMs; NEP’s sites are far more numerous than cloud platforms’ sites, while individual sites are smaller.Source: §2 · p. 3

2.1 Measurement Methodology

• The study collects active edge-performance measurements and passive VM-activity traces to characterize the platform.The performance dataset uses benchmark tools and experiments; the workload dataset logs VM activities.Source: §2.1 · p. 3

2.1.1 Edge Performance Data Collection.

• Performance measurements cover latency, throughput, and application QoE, using crowdsourcing for network metrics and controlled experiments for application tests.The study uses traceroute and iPerf3 alongside cloud-gaming and live-streaming applications, with measurements across users, networks, and locations.Source: §2.1.1 · pp. 3–4

2.1.2 Edge Workloads Data Collection.

• The NEP workload dataset records VM placement and customer/system metadata, resource capacities, one-minute CPU usage, and five-minute bandwidth usage.Its VM activity traces cover June 1 to September 1, 2020.Source: §2.1.2 · p. 4

2.2 Selecting cloud workloads for comparison

• The study compares NEP workloads with the 2019 Azure dataset, while excluding other datasets for differences in workload type, duration, representativeness, access, or scale.The AliCloud trace covers containers rather than VMs and only eight days; the Google and GWA-T-12 datasets are also excluded for stated limitations.Source: §2.2 · p. 4

2.3 Ethics

• Performance-data collection received institutional ethics approval and participant consent, while workload collection was approved by NEP customers and anonymized customer IDs.Source: §2.3 · p. 4

3.1 End-to-end Network Latency

• Nearest-edge median RTTs were 10.5ms (WiFi), 34.2ms (LTE), and 10.4ms (5G), beating nearest cloud by 1.89×, 1.42×, and 1.35×, with lower jitter.Nearest-edge RTT CVs were 1.1%, 2.3%, and 0.7% for WiFi/LTE/5G; the nearest cloud had 5.8×, 3.9×, and 5.7× higher median CV. Benefits varied by user location, with average RTT falling from 34.97ms to 22.37ms for users not co-located with either provider, and from 47.06ms to 18.45ms for users co-located only with NEP.Source: Figure 2 · p. 5, §3.1 · p. 5
• Nearest edge paths use 5–12 hops versus clouds’ 10–16, but last-mile hops remain a delay bottleneck despite NEP’s dense inter-site network.Each site has 1/3/11 nearby sites within 5ms/10ms/20ms RTT on average; the first three hops account for 98% of nearest-edge 5G RTT.Source: §3.1 · pp. 5–6, Figure 3 · p. 6, Figure 4 · p. 6

3.2 End-to-end Network Throughput

• Distance scarcely affected throughput at ≤100Mbps, but correlation exceeded 0.7 for 5G downlink and wired access; throughput is not a primary current edge incentive.Benefits require high last-mile capacity and applications generating over 200Mbps, plus similarly high VM bandwidth, which can be prohibitively expensive for developers.Source: Figure 5 · p. 6, §3.2 · pp. 6–7

3.3.1 Cloud Gaming.

• With WiFi and nearby VMs, cloud gaming achieved under 100ms response delay; remote cloud VMs added up to 60ms.The nearest edge’s propagation delay was 11.4ms and frame transmission took under 10ms, while server-side game execution and rendering contributed around 70ms; most CPU cores were under 10% utilized.Source: Figure 6 · p. 7, §3.3.1 · pp. 7–8

3.3 Application Performance (QoE)

• Application QoE gains were uneven: nearby edge improved gaming response, while live streaming saw modest delay reduction and remained limited by non-network processing.The streaming breakdown attributes delay to image capture, rendering, encoding/decoding, and software as well as network transmission.Source: §3.3.1 · p. 7, §3.3.2 · p. 8

3.3.2 Live Streaming.

• Edge reduced streaming delay by at most 24%, while lowering resolution cut about 67ms (26%) and WiFi transcoding added about 400ms (2×).Even without jitter buffering or transcoding, streaming delay remained about 400ms; a 2MB jitter buffer raised it as high as 2 seconds and made edge/cloud differences trivial.Source: Figure 7 · p. 8, §3.3.2 · p. 8

4.1 Applications and VM Subscription

• NEP VMs have median CPU and memory allocations of 8 cores and 32GB, versus 1 core and 4GB on Azure.NEP’s customers are mostly network-intensive and delay-critical; business-oriented, delay-critical applications are a possible reason for larger subscriptions, which may cause resource fragmentation and hinder server sale ratios.Source: §4.1 · pp. 8–9
• More than 9.6% of NEP apps deploy at least 50 VMs, versus 6.1% on Azure; NEP’s largest app has almost 1,000 VMs.The authors suggest delay sensitivity and Azure’s larger share of small businesses or individual users as possible explanations for the deployment difference.Source: §4.1 · p. 9, Figure 9 · p. 9

4.2 Overall Resource Usage

• 74% of NEP VMs average below 10% CPU utilization, versus 47% on Azure; edge VMs also have higher median CPU-usage variation, 0.48 versus 0.24.The authors associate low utilization with over-provisioning and greater variation with interactive applications; the NEP CPU sales rate is nearly twice the memory sales rate, and sales rates vary across sites.Source: §4.2 · p. 9, §4.1 · p. 9, Figure 10 · p. 9

4.3 Resource Load Balance

• NEP resource use is highly skewed: bandwidth differs up to 19.8× across servers in a site and 731× across sites; P95 Max CPU differs 8.7× across sites.The authors link the skew to changing VM usage, newly added sites and subscriptions, and separately controlled VM allocation and user-request scheduling.Source: §4.3 · p. 10, Figure 13 · p. 10, Figure 11 · p. 10
• 16.3% of NEP apps have a cross-VM mean-CPU usage gap above 50×, compared with 0.1% on Azure.One VM in the illustrated app exceeds 80% CPU for more than 33% of the time, while some others stay below 30%; Azure placement data is unavailable for this comparison.Source: §4.3 · pp. 10–11, Figure 12 · p. 10

4.4 VM Usage Prediction

• Holt-Winters predicts maximal CPU usage with 2.4% error on NEP workloads versus 8.5% on Azure workloads.Edge VMs have stronger mean seasonality, 0.42 versus 0.26, which the authors identify as a possible reason for better predictability.Source: §4.4 · p. 11, Figure 14 · p. 11

4.5 Monetary Cost of Edge Apps

• NEP network billing is cheaper but less elastic than cloud billing: it charges daily peak bandwidth, while AliCloud charges peak bandwidth by the minute.NEP’s network unit price is up to 13× cheaper depending on location; high bandwidth variance can make daily-peak billing less favorable for some apps.Source: §4.5 · pp. 11–12
• NEP reduces average cost by 45% against vCloud-1 and 43% against vCloud-2, with savings up to 85% and 84%, respectively.Network resource averages 76% of cost and can reach 96%; NEP reduces network bandwidth cost by up to 90%, while hardware costs are 3%–20% higher than AliCloud for each app.Source: Table 6 · p. 11, §4.5 · p. 12

Killer apps for NEP-like edges

• For NEP, reduced network cost is currently a key incentive for moving applications from cloud, making video-related applications major customers.Network latency and throughput also improve to some extent, but practical factors can diminish application-level QoE; better edge hardware and software stacks could serve computation-heavy applications such as AR/VR and autonomous driving.Source: §5 · p. 12

Sites as an integrated cluster

• Limited resources per edge site and dense deployment make cross-site coordination necessary, while migration can affect delay and application QoS.The authors discuss treating sites as an integrated cluster and note that migration has been explored but remains challenging because of migration delay and QoS impacts.Source: §5 · p. 12

Decomposing edge services

• More elastic paradigms such as microservices and serverless may support flexible resource management and fine-grained billing, but cold starts can miss ultra-low-delay requirements.Source: §5 · p. 12

Cross-sites traffic scheduling

• Cross-site traffic scheduling must balance application QoE with load, but provider-side scheduling may lack application-specific information and customer-side scheduling is often ineffective.Workload prediction also poses a challenge: moving a VM between sites can change its usage pattern and make predictions based on past usage invalid shortly afterward.Source: §5 · p. 12

Dataset representativeness

• NEP and Azure workload traces come from different countries and collection times, so the authors draw conclusions conservatively.Source: §6 · p. 12

Experimental settings

• The latency study used ICMP ping rather than TCP, which the authors say may be less representative because providers can prioritize ICMP differently from regular TCP/UDP traffic.Source: §6 · p. 13
• The two implemented edge applications may not fully reflect commercial applications, and the authors plan to benchmark more apps and deployment configurations.Source: §6 · p. 13
• The user study had a limited number of participating endpoints, which the authors plan to increase.Source: §6 · p. 13

NEP as an early adopter

• NEP is an early-stage platform, and its deployment density, customer diversity, and VM elasticity do not all match the authors’ conception of ideal edge computing.The authors describe NEP as a leading platform and frame their measurements as a baseline for future study.Source: §6 · p. 13

Commercial edge/cloud platforms

• NEP is presented as a general-purpose, multi-tenant edge platform, whereas Facebook and Google edge infrastructure is described in terms of content delivery.AWS Local Zones and Azure Edge Zone are noted as earlier-stage platforms without comprehensive measurements in the paper’s account.Source: §7 · p. 13

Measurements of edge/cloud platforms

• Prior WAN and geo-distributed datacenter studies focused on cloud; the authors describe their work as the first to quantify network and application performance on a denser real edge platform.Source: §7 · p. 13
• The authors report no prior workload characterization of edge platforms and distinguish their multi-tenant, VM-based NEP workloads from first-party, container-based cloud workload studies.Source: §7 · p. 13

• The study comprehensively measures a commercial, multi-tenant edge platform, examining performance perceived by end users and workloads experienced by the operator.Source: §8 · p. 13
• The measurements reveal critical differences between cloud and edge platforms.Source: §8 · p. 13
• The findings lead to implications for designing future edge platforms and edge-based applications.Source: §8 · p. 13

• The comparison covers monthly costs for NEP and two cloud platforms, with edge bandwidth prices varying by city and operator.Source: A PRICING MODEL COMPARISON · p. 16, Table 7 · p. 17
• NEP bills bandwidth using the month’s fourth-highest daily peak, whereas cloud platforms charge by average usage per minute or second.Source: A PRICING MODEL COMPARISON · p. 16
• NEP combines network traffic from VMs at the same site for billing.Source: A PRICING MODEL COMPARISON · p. 16