Reliable consistent communication over millimeter-wave (mmWave) channels is a challenging problem due to their sensitivity to blocking of Line of Sight connections. Even though mmWave is a key building block in 5G and future generation cellular networks, making solutions to this problem space important. Our aim is to use predictive control to manage and simultaneously use multiple available mmWave paths to achieve reliable consistent communication (i.e. steady transmission rate with low delay) with a multipath proxy. To this end we investigate transient solutions of Markov Modulated Fluid Queue models (MMFQ), apt because the mmWave blocking has been modeled with Markovian models. We propose a combination of models that can be solved using newly proposed matrix analytic techniques in a timely enough manner for use in real-time control. This gives us a prediction of either proxy queue distributions or probabilities of reaching proxy buffer levels over a short time horizon, enabling the proxy to make preemptive path decisions to maintain a desired Quality of Service. A proof of concept simulation study demonstrates the efficacy of our proposed MMFQ-based predictive approach over either static or purely reactive control approaches.

Abstract—Most Internet hosts today support multiple access technologies and network interfaces. Multipath transport protocols, like MPTCP, are being deployed (e.g., in smartphones), allowing transparent simultaneous use of multiple links. Besides providing increased resilience to link failures, multipath trans- ports may better exploit available (aggregate) capacity across all interfaces. The safest way to ensure fairness is to assume that any subflows of a multipath end-to-end connection may share bottleneck links, but knowledge of non-shared bottlenecks could allow multipath senders to exploit more capacity without being unfair to other flows. The problem of reliably detecting the existence of (non)-shared bottlenecks is not trivial and is compounded by the fact that bottlenecks may change due to traffic dynamics. In this paper we focus on practical methods to reliably group flows that share, possibly dynamic, bottlenecks online and in a passive manner (i.e., without injecting measurement traffic). We introduce a novel dynamic clustering algorithm that we apply to update our previous shared bottleneck flow grouping (SBFG) method standardized by the IETF, based on delay statistics. We also adapt an offline SBFG method based on wavelet filters to enable it for online operation. These SBFG methods are evaluated by a simple testbed, rigorous simulation and real-world Internet experiments in a testbed comprised of multihomed hosts. Our results suggest that there is no clear winner, and selection of the “best” SBFG method will have to consider tradeoffs regarding accuracy, lag, and application requirements.

Abstract—5G mmWave technology promises capacities 10 to 100 times that of 4G. However, mmWave links are very sensitive to having direct line of sight between sender and receiver, with dramatically fluctuating capacities due to transient blocking and shadow fading, which can substantially degrade TCP performance. TCP-splitting proxies (SPEPs) are often used to improve TCP performance over wireless links. We investigate current operator SPEPs (used in 4G LTE networks) under mmWave-like dynamics using the MONROE testbed. We introduce a mmWave emulation model for an urban canyon scenario, and use it to evaluate how current operational SPEPs impact the performance. Our results from experiments including four operators and three countries, indicate that SPEPs will be even more important for 5G mmWave than they are in LTE. Current 4G SPEPs provide significant, though not optimal, benefits under mmWave-like conditions, allowing them to be utilized as the network transitions to 5G technology.

This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. This mechanism relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed

The sockets Applications Programming Interface (API) has become the standard way that applications access the transport services offered by the Internet Protocol stack. This paper presents NEAT, a user-space library that can provide an alternate transport API. NEAT allows applications to request the service they need using a new design that is agnostic to the specific choice of transport protocol underneath. This not only allows applications to take advantage of common protocol machinery, but also eases introduction of new network mechanisms and transport protocols. The paper describes the components of the NEAT library and illustrates the important benefits that can be gained from this new approach. NEAT is a software platform for developing advanced network applications that was designed in accordance with the standardization efforts on Transport Services (TAPS) in the Internet Engineering Task Force (IETF), but its features exceed the envisioned functionality of a TAPS system.

Latency is increasingly becoming a performance bottleneck for Internet Protocol (IP) networks, but historically networks have been designed with aims of maximizing throughput and utilization. This article offers a broad survey of techniques aimed at tackling latency in the literature up to August 2014, and their merits. A goal of this work is to be able to quantify and compare the merits of the different Internet latency reducing techniques, contrasting their gains in delay reduction versus the pain required to implement and deploy them. We found that classifying techniques according to the sources of delay they alleviate provided the best insight into the following issues: 1) the structural arrangement of a network, such as placement of servers and suboptimal routes, can contribute significantly to latency; 2) each interaction between communicating endpoints adds a Round Trip Time (RTT) to latency, especially significant for short flows; 3) in addition to base propagation delay, several sources of delay accumulate along transmission paths, today intermittently dominated by queuing delays; 4) it takes time to sense and use available capacity, with overuse inflicting latency on other flows sharing the capacity; and 5) within end systems delay sources include operating system buffering, head-of-line blocking, and hardware interaction. No single source of delay dominates in all cases, and many of these sources are spasmodic and highly variable. Solutions addressing these sources often both reduce the overall latency and make it more predictable.