Google’s QUIC protocol has become popular over the past few years and is being rapidly adopted as the transport protocol of choice by popular Internet services in their mobile applications. Considering this, it is crucial to understand the performance and implementation issues of integrating QUIC with mobile and wearable applications. In this paper, we conduct a comprehensive measurement analysis and comparison of QUIC with TCP on mobile and wearable platforms. Our experiments cover a wide range of environments, including different request sizes, traffic directions, and connectivity types. From our experiments, we found that the benefits of using QUIC instead of TCP to service HTTP requests are not uniform across different scenarios. We also found a bug in the current implementation of QUIC in Android’s Cronet library that prevents the applications from reverting back to using WiFi after a connection migration from LTE happens. Our experiences from this measurement study has lead us to propose a probabilistic framework, which we call Dynamic Transport Selection, that adaptively chooses the appropriate transport protocol for a given network environment. We implemented and evaluated this framework in Android and Wear OS devices and found that it improves the overall request completion performance of the application by as much as 41.76% when compared to using either QUIC or TCP alone

Cloud computing has become the de-facto paradigm for fulfilling the computing needs of a myriad of applications like streaming, e-commerce, data analytics, etc. While a significant amount of work exists on how cloud providers can improve the networking performance of their cloud platforms, very little has been done to explore how a cloud tenant can achieve the best performance for their applications. In this paper, we study how the choice of the TCP variant impacts the performance achieved by tenant applications. We present a generic measurementbased approach to identify the best TCP variant for any given application in a given cloud environment. Our approach is comprised of first measuring several performance metrics including throughput, latency, and loss in the given cloud platform for several TCP variants, and then identifying the best TCP variant based on three things: observations from the measurements, nature of the traffic of the given application, and application requirements such as high throughput or low latency. We study the effectiveness of our approach by implementing it in two large public clouds, Amazon's AWS and Google's GCP, and present our observations from several case studies using three common cloud applications, namely streaming, distributed input-output, and sort, and four common TCP variants, namely Cubic, New Reno, BBR, and DCTCP. From our observations, we found that just by changing the TCP variant that an application uses, the average throughput can be increased by up to 13.7% and the round trip time can be decreased by up to 5 times.

The switch fabrics of today's data centers carry traffic controlled by a variety of TCP congestion control algorithms. This leads us to ask: how does the coexistence of multiple variants of TCP on shared switch fabric impacts the performance achieved by different applications in data centers? To answer this question, we conducted an extensive set of experiments with coexisting TCP variants on Leaf-Spine and Fat-Tree switch fabrics. We executed common data center workloads, which include streaming, MapReduce, and storage workloads, using four commonly used TCP variants, namely BBR, DCTCP, CUBIC, and New Reno. We also extensively executed iPerf workloads using these 4 TCP variants to purely study the impact of the coexistence of TCP variants on each other's performance without incorporating the network behavior of the application layer. Our experiments resulted in a large set of network traces comprised of 160 billion packets (we will release these traces after publication of this work). We present comprehensive observations from these traces that have important implications in ensuring optimal utilization of data center switch fabric and in meeting the network performance needs of application layer workloads.

With the advent of the internet of things, the number of wireless devices and the amount of wireless data traffic is increasing at an unprecedented rate. By 2020, the number of connected devices per person is expected to exceed 6.58. Due to the ubiquitous availability of IEEE 802.11n/ac (i.e., WiFi) in most modern homes and enterprise environments, the majority of the new home and enterprise focused IoT devices that are entering the market use IEEE 802.11n/ac to connect to the internet. Our literature survey revealed that there are no prior measurement studies on the performance of IEEE 802.11n/ac's MAC in dense IoT environments. Thus, in this paper, we conduct a comprehensive measurement study of various aspects of IEEE 802.11n/ac's MAC using real IoT devices and realistic IoT workloads and present several useful observations that demonstrate the need to revise some of the key aspects of IEEE 802.11n/ac's MAC to make it suitable for dense IoT environments. This need for revisions stems from the fact that IEEE 802.11n/ac was primarily designed keeping conventional devices, such as laptops, smart phones, and servers in view. For such conventional devices, the amount of uplink traffic is significantly smaller compared to the amount of downlink traffic. Contrary to this, in dense IoT deployments, the amount of uplink traffic is significantly larger compared to the downlink traffic. We conducted our study on a real test bed comprising a large number of Raspberry Pis deployed in a real world environment and studied the impact of the density and type of IoT traffic on the throughput of the wireless system, bandwidth utilization of RTS and CTS frames, block acknowledgments, and frame aggregation sizes. We further studied the impact of TCP's congestion control mechanism on the performance of IEEE 802.11n/ac's MAC.

With the advent of the internet of things, the number of wireless devices and the amount of wireless data traffic is increasing at an unprecedented rate. By 2020, the number of connected devices per person is expected to exceed 6.58. Due to the ubiquitous availability of IEEE 802.11n/ac (i.e., WiFi) in most modern homes and enterprise environments, the majority of the new home and enterprise-focused IoT devices that are entering the market use IEEE 802.11n/ac to connect to the internet. Our literature survey revealed that there are no prior measurement studies on the performance of IEEE 802.11n/ac's MAC in dense IoT environments. Thus, in this paper, we conduct a comprehensive measurement study of various aspects of IEEE 802.11n/ac's MAC using real IoT devices and realistic IoT workloads and present several useful observations that demonstrate the need to revise some of the key aspects of IEEE 802.11n/ac's MAC to make it suitable for dense IoT environments. We conducted our study on a real testbed comprising a large number of Raspberry Pis deployed in a real-world environment and studied the impact of the density and type of IoT traffic on the throughput and frame aggregation sizes of the wireless system. We further studied the impact of TCP's congestion control mechanism on the performance of IEEE 802.11n/ac's MAC.

Most Internet of Things (IoT) applications require unique guarantees on various performance metrics (such as latency, CPU availability, power fairness, etc.) from the IoT infrastructure. A small deterioration in these performance metrics can cause serious violations of service level agreements. To ensure that the deployed IoT infrastructure delivers the guarantees on these metrics, the first step is to measure these metrics. We present IoTm, a framework for measuring IoT performance metrics, which include both IoT network's quality of service (QoS) metrics and IoT node's resource utilization (RU) metrics. IoTm has two key properties: 1) it is lightweight and thus amenable for implementation on resource constrained IoT nodes; and 2) it can perform measurements at fine-grained levels and not just at aggregate levels. IoTm is comprised of two components, a lightweight IoT node unit (INU), which resides in each of the IoT nodes, and a control and query unit (CQU), which resides in a logically centralized management server. The primary role of INU is to record appropriate information about the desired performance metrics in the IoT nodes. To record the information, INU leverages a generic data structure that we propose. CQU is responsible for identifying the metrics and the IoT nodes on which those metrics should be monitored to achieve a desired measurement objective. CQU also stores the copies of data structures that the INU sends to it for long term storage. Both INU and CQU further contain query processing engines, which operate on the information stored in the data structures to answer measurement queries. To demonstrate the use of our framework, we apply it to one RU metric (number of disk accesses), and one QoS metric (round trip latency), and evaluate its accuracy. We also analyze the feasibility of its implementation on IoT nodes in terms of memory requirement and computational complexity.