Jitu Padhye

Measurement and estimation of network QoS among peer Xbox 360 game players

The research community has proposed several techniques for estimating the quality of network paths in terms of delay and capacity. However, few techniques have been studied in the context of large deployed applications. Network gaming is an application that is extremely sensitive to network path quality [1,2,3]. Yet, the quality of network paths among players of large, wide-area games and techniques for estimating it have not received much attention from the research community.

CrystalNet: Faithfully Emulating Large Production Networks

Network reliability is critical for large clouds and online service providers like Microsoft. Our network is large, heterogeneous, complex and undergoes constant churns. In such an environment even small issues triggered by device failures, buggy device software, configuration errors, unproven management tools and unavoidable human errors can quickly cause large outages. A promising way to minimize such network outages is to proactively validate all network operations in a high-fidelity network emulator, before they are carried out in production. To this end, we present CrystalNet, a cloud-scale, high-fidelity network emulator. It runs real network device firmwares in a network of containers and virtual machines, loaded with production configurations. Network engineers can use the same management tools and methods to interact with the emulated network as they do with a production network. CrystalNet can handle heterogeneous device firmwares and can scale to emulate thousands of network devices in a matter of minutes. To reduce resource consumption, it carefully selects a boundary of emulations, while ensuring correctness of propagation of network changes. Microsofts network engineers use CrystalNet on a daily basis to test planned network operations. Our experience shows that CrystalNet enables operators to detect many issues that could trigger significant outages.

FreeFlow: High Performance Container Networking

With the tremendous popularity gained by container technology, many applications are being containerized: splitting into numerous containers connected by networks. However, current container networking solutions have either bad performance or poor portability, which undermines the advantages of containerization. In this paper, we propose FreeFlow, a container networking solution which achieves both high performance and good portability. FreeFlow is designed according to the observation that strict isolations are unnecessary among containers trusting each other, and it can significantly boost the communication quality of containers by compromising isolation a little bit. Specifically, we enable containers on the same physical machine to communicate via shared-memory and the ones on different physical machines communicate via high performance networking options, e.g. RDMA and DPDK. Naively wrapping up all the solutions together will result in poor potability of containers and huge complexity in application development. Instead, FreeFlow leverages a network abstraction which supports all common network APIs and a centralized network orchestrator which decides how to deliver data transparently to applications in the containers.

How to the Smash Next Billion Mobile App Bugs

With users increasingly dependent on their phones, tablets, and wearables, the mobile app ecosystem is more important today than ever before. Creating and distributing apps has never been more accessible. Even single developers can now reach global audiences. But mobile apps must cope with extremely varied and dynamic operating conditions due to factors like diverse device characteristics, wireless network heterogeneity, and varied user behavior. App developers and operators of app marketplaces both lack testing tools that can effectively account for such diversity and, as a result, app failures and performance bugs (like excessive energy consumption) are commonly found today. To address this challenge to mobile app development, we have developed key techniques for scalable automated mobile app testing within two prototype services --- VanarSena and Caiipa. In this paper, we describe our vision for SMASH, a unified cloud-based mobile app testing service that combines the strengths of both previous systems to tackle the complexities presently faced by testers of mobile apps.

Hyperloop: group-based NIC-offloading to accelerate replicated transactions in multi-tenant storage systems

Storage systems in data centers are an important component of large-scale online services. They typically perform replicated transactional operations for high data availability and integrity. Today, however, such operations suffer from high tail latency even with recent kernel bypass and storage optimizations, and thus affect the predictability of end-to-end performance of these services. We observe that the root cause of the problem is the involvement of the CPU, a precious commodity in multi-tenant settings, in the critical path of replicated transactions. In this paper, we present HyperLoop, a new framework that removes CPU from the critical path of replicated transactions in storage systems by offloading them to commodity RDMA NICs, with non-volatile memory as the storage medium. To achieve this, we develop new and general NIC offloading primitives that can perform memory operations on all nodes in a replication group while guaranteeing ACID properties without CPU involvement. We demonstrate that popular storage applications can be easily optimized using our primitives. Our evaluation results with microbenchmarks and application benchmarks show that HyperLoop can reduce 99th percentile latency ≈ 800X with close to 0% CPU consumption on replicas.

Closing the Network Diagnostics Gap with Vigil

Closing the Network Diagnostics Gap with Vigil Behnaz Arzani, Selim Ciraci, Luiz Chamon, Yibo Zhu, Hongqiang Liu, Jitu Padhye, Geoff Outhred, Boon Thau Loo Vigil started with an ambitious goal: For every TCP retransmission in our data centers, we wanted to pinpoint the network link that caused the packet drop that triggered the retransmission with negligible diagnostic overhead or changes to the networking infrastructure. This goal may sound like an overkill—after all, TCP is supposed to be able to deal with a few packet losses. Packet losses might occur due to simple congestion instead of network equipment failures. Even network failures might be transient. Above all, there is a danger of drowning in a sea of data without generating any actionable intelligence.