Creating Repeatable Computer Science and Networking Experiments on Shared, Public Testbeds

Edwards, Sarah; Li, Xuan; Riga, Niky

doi:10.1145/2723872.2723884

Cited by 12 publications

(11 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The separation of functions and isolation of the system under test from the system that performs the tests make this environment suitable for the testing process as described by Edwards. 17…”

Section: Architecture and Componentsmentioning

confidence: 99%

Impact of etcd deployment on Kubernetes, Istio, and application performance

et al. 2020

View full text Add to dashboard Cite

Summary This experience article describes lessons learned as we conducted experiments in a Kubernetes‐based environment, the most notable of which was that the performance of both the Kubernetes control plane and the deployed application depends strongly and in unexpected ways on the performance of the etcd database. The article contains (a) detailed descriptions of how networking with and without Istio works in Kubernetes, based on the Flannel Container Networking Interface (CNI) provider in VXLAN mode with IP Virtual Server (IPVS)‐backed Kubernetes Services, (b) a comprehensive discussion about how to conduct load and performance testing using a closed‐loop workload generator, and (c) an open source experiment framework useful for executing experiments in a shared cloud environment and exploring the resulting data. It also shows that statistical analysis may reveal the data resulting from such experiments to be misleading even when careful preparations are made, and that nondeterministic behavior stemming from etcd can affect both the platform as a whole and the deployed application. Finally, it is demonstrated that using high‐performance backing storage for etcd can reduce the occurrence of such nondeterministic behaviors by a statistically significant (P < .05) margin. The implication of this experience article is that systems researchers studying the performance of applications deployed on Kubernetes cannot simply consider their specific application to be under test. Instead, the particularities of the underlying Kubernetes and cloud platform must be taken into account, in particular because their performance can impact that of etcd.

show abstract

Section: Architecture and Componentsmentioning

confidence: 99%

Impact of etcd deployment on Kubernetes, Istio, and application performance

et al. 2020

View full text Add to dashboard Cite

show abstract

“…Espresso needs to interoperate with the rest of the Internet and the peer networks, supporting all standard Internet protocols, such as BGP and IPv4/IPv6. Previous SDN deployments [11,21] were internal and only had to interoperate with a controlled number of vendors and/or software. (3) Reliability.…”

Section: Background and Requirementsmentioning

confidence: 99%

“…Recently, several large-scale SDN deployments [11,21,29] have been discussed in the literature. These deployments only had to interoperate with a controlled number of vendors and/or software.…”

Section: Related Workmentioning

confidence: 99%

Taking the Edge off with Espresso

Yap

Motiwala

Rahe

et al. 2017

Proceedings of the Conference of the ACM Special Interest Group on Data Communication

132

View full text Add to dashboard Cite

We present the design of Espresso, Google's SDN-based Internet peering edge routing infrastructure. This architecture grew out of a need to exponentially scale the Internet edge cost-effectively and to enable application-aware routing at Internet-peering scale. Espresso utilizes commodity switches and host-based routing/packet processing to implement a novel fine-grained traffic engineering capability. Overall, Espresso provides Google a scalable peering edge that is programmable, reliable, and integrated with global traffic systems. Espresso also greatly accelerated deployment of new networking features at our peering edge. Espresso has been in production for two years and serves over 22% of Google's total traffic to the Internet.

show abstract

“…I have been a collaborator on a number of projects during my PhD studies at University of Missouri -Kansas City, and they resulted in the following publications [15,29,42,69,70,79,94,110,111], and these contributions are described briefly in the following subsections.…”

Section: Additional Collaboration and Projectsmentioning

confidence: 99%

“…By collaborating with the GENI Project Office and based on our experience on using GENI testbed, we contributed a case study in [42]. In the presented case study, we showed how to conduct experiments systematically on a publicly shared testbed.…”

Section: Systematic Experimental Design On a Shared Testbedmentioning

confidence: 99%

Dynamic virtual network restoration with optimal standby virtual router selection

Medhi

2016

NOMS 2016 - 2016 IEEE/IFIP Network Operations and Management Symposium

Self Cite

View full text Add to dashboard Cite

Network virtualization technologies allow service providers to request partitioned, QoS guaranteed and fault-tolerant virtual networks provisioned by the substrate network provider (i.e., physical infrastructure provider). A virtualized networking environment (VNE) has common features such as partition, flexibility, etc., but fault-tolerance requires additional efforts to provide survivability against failures on either virtual networks or the substrate network.Two common survivability paradigms are protection (proactive) and restoration (reactive). In the protection scheme, the substrate network provider (SNP) allocates redundant resources (e.g., nodes, paths, bandwidths, etc) to protect against potential failures in the VNE. In the restoration scheme, the SNP dynamically allocates resources to restore the networks, and it usually occurs after the failure is detected.iii In this dissertation, we design a restoration scheme that can be dynamically implemented in a centralized manner by an SNP to achieve survivability against node failures in the VNE. The proposed restoration scheme is designed to be integrated with a protection scheme, where the SNP allocates spare virtual routers (VRs) as standbys for the virtual networks (VN) and they are ready to serve in the restoration scheme after a node failure has been identified. These standby virtual routers (S-VR) are reserved as a sharedbackup for any single node failure, and during the restoration procedure, one of the S-VR will be selected to replace the failed VR. In this work, we present an optimal S-VR selection approach to simultaneously restore multiple VNs affected by failed VRs, where these VRs may be affected by failures within themselves or at their substrate host (i.e., power outage, hardware failures, maintenance, etc.). Furthermore, the restoration scheme is embedded into a dynamic reconfiguration scheme (DRS), so that the affected VNs can be dynamically restored by a centralized virtual network manager (VNM).We first introduce a dynamic reconfiguration scheme (DRS) against node failures in a VNE, and then present an experimental study by implementing this DRS over a realistic VNE using GpENI testbed. For this experimental study, we ran the DRS to restore one VN with a single-VR failure, and the results showed that with a proper S-VR selection, the performance of the affected VN could be well restored. Next, we proposed an Mixed-Integer Linear Programming (MILP) model with dual-goals to optimally select S-VRs to restore all VNs affected by VR failures while load balancing. We also present a iv heuristic algorithm based on the model. By considering a number of factors, we present numerical studies to show how the optimal selection is affected. The results show that the proposed heuristic's performance is close to the optimization model when there were sufficient standby virtual routers for each virtual network and the substrate nodes have the capability to support multiple standby virtual routers to be in service simultaneously.Finally, we presen...

show abstract

Creating Repeatable Computer Science and Networking Experiments on Shared, Public Testbeds

Cited by 12 publications

References 18 publications

Impact of etcd deployment on Kubernetes, Istio, and application performance

Impact of etcd deployment on Kubernetes, Istio, and application performance

Taking the Edge off with Espresso

Dynamic virtual network restoration with optimal standby virtual router selection

Contact Info

Product

Resources

About