Hardware transports such as RoCE deliver high performance with minimal host CPU, but are best suited to special-purpose deployments that limit their use, e.g., backend networks or Ethernet with Priority Flow Control (PFC). We introduce Falcon, the first hardware transport that supports multiple Upper Layer Protocols (ULPs) and heterogeneous application workloads in general-purpose Ethernet datacenter environments (with losses and without special switch support). Key design elements include: delay-based congestion control with multipath load balancing; a layered design with a simple request-response transaction interface for multi-ULP support; hardware-based retransmissions and error-handling for scalability; and a programmable engine for flexibility. The first Falcon hardware implementation delivers a peak performance of 200 Gbps, 120 Mops/sec, with near-optimal operation completion times that are up to 8x lower than CX-7 RoCE under network congestion, and up to 65% higher goodput under lossy conditions.

We present PRR (Protective ReRoute), a transport technique for shortening user-visible outages that complements routing repair. It can be added to any transport to provide benefits in multipath networks. PRR responds to flow connectivity failure signals, e.g., retransmission timeouts, by changing the FlowLabel on packets of the flow, which causes switches and hosts to choose a different network path that may avoid the outage. To enable it, we shifted our IPv6 network architecture to use the FlowLabel, so that hosts can change the paths of their flows without application involvement. PRR is deployed fleetwide at Google for TCP and Pony Express, where it has been protecting all production traffic for several years. It is also available to our Cloud customers. We find it highly effective for real outages. In a measurement study on our network backbones, adding PRR reduced the cumulative region-pair outage time for RPC traffic by 63--84%. This is the equivalent of adding 0.4--0.8 "nines" of availability.

We describe our experience with Fathom, a system for identifying the network performance bottlenecks of any service running in the Google fleet. Fathom passively samples RPCs, the principal unit of work for services. It segments the overall latency into host and network components with kernel and RPC stack instrumentation. It records these detailed latency metrics, along with detailed transport connection state, for every sampled RPC. This lets us determine if the completion is constrained by the client, network or server. To scale while enabling analysis, we also aggregate samples into distributions that retain multi-dimensional breakdowns. This provides us with a macroscopic view of individual services. Fathom runs globally in our datacenters for all production traffic, where it monitors billions of TCP connections 24x7. For five years Fathom has been our primary tool for troubleshooting service network issues and assessing network infrastructure changes. We present case studies to show how it has helped us improve our production services.

We present a new, host-based design for link load balancing and report the first experiences of link imbalance in datacenters. Our design, PLB (Protective Load Balancing), builds on transport protocols and ECMP/WCMP to reduce network hotspots. PLB randomly changes the paths of connections that experience congestion, preferring to repath after idle periods to minimize packet reordering. It repaths a connection by changing the IPv6 Flow Label on its packets, which switches include as part of ECMP/WCMP. Across hosts, this action drives down hotspots in the network, and lowers the latency of RPCs. PLB is used fleetwide at Google for TCP and Pony Express traffic. We could deploy it when other designs were infeasible because PLB requires only small transport modifications and switch configuration changes, and is backwards-compatible. It has produced excellent gains: the median utilization imbalance of highly-loaded ToR uplinks in Google datacenters fell by 60%, packet drops correspondingly fell by 33%, and the tail latency (99p) of small RPCs fell by 20%. PLB is also a general solution that works for settings from datacenters to backbone networks, as well as different transports.

We report on experiences with Swift congestion control in Google datacenters. Swift targets an end-to-end delay by using AIMD control, with pacing under extreme congestion. With accurate RTT measurement and care in reasoning about delay targets, we find this design is a foundation for excellent performance when network distances are well-known. Importantly, its simplicity helps us to meet operational challenges. Delay is easy to decompose into fabric and host components to separate concerns, and effortless to deploy and maintain as a congestion signal while the datacenter evolves. In large-scale testbed experiments, Swift delivers a tail latency of <50 mu s for short RPCs, with near-zero packet drops, while sustaining similar to 100Gbps throughput per server. This is a tail of <3x the minimal latency at a load close to 100%. In production use in many different clusters, Swift achieves consistently low tail completion times for short RPCs, while providing high throughput for long RPCs. It has loss rates that are at least 10x lower than a DCTCP protocol, and handles O(10k) incasts that sharply degrade with DCTCP.

Computer network congestion control algorithms control the sending rate for flows of data from sender network nodes to receiver network nodes. These algorithms attempt to utilize network bandwidth capacity efficiently, while keeping network data loss rates low, and allocating network capacity between different flows sharing the network in an approximately fair manner, or at least avoiding starvation of some flows. In addition, some congestion control algorithms attempt to keep network queues short, to reduce queuing delays and further reduce loss rates. This disclosure describes model-based congestion control, a technique that explicitly models the network conditions along the path(s) between senders and receivers. The algorithm updates the model using measurements obtained from the packets in the flow it is controlling. The algorithm uses those measurements as inputs to update the model and then uses that model to control its sending process. This model-based approach can allow the congestion control algorithm to achieve higher throughputs and/or lower delays and/or lower data packet loss rates than would be achievable by other techniques.

Network programmability has metamorphosed over the past twenty years from the controversial research vision of active networks, through PlanetLab, to the juggernaut of SDN and OpenFlow that has swept industry. Now PISA switches are emerging with support for protocol-independent reconfigurability. We reflect on how network architecture has evolved along a different path than we had foreseen to arrive at a place that is not so different than we and other researchers had hoped and imagined.

Web page loads are slow due to intrinsic inefficiencies in the page load process. Our study shows that the inefficiencies are attributable not only to the contents and structure of the Web pages (e.g., three-fourths of the CSS resources are not used during the initial page load) but also the way that pages are loaded (e.g., 15% of page load times are spent waiting for parsing-blocking resources to be loaded). To address these inefficiencies, this paper presents Shandian (which means lightening in Chinese) that restructures the page load process to speed up page loads. Shandian exercises control over what portions of the page gets communicated and in what order so that the initial page load is optimized. Unlike previous techniques, Shandian works on demand without requiring a training period, is compatible with existing latency-reducing techniques (e.g., caching and CDNs), supports security features that enforce same-origin policies, and does not impose additional privacy risks. Our evaluations show that Shandian reduces page load times by more than half for both mobile phones and desktops while incurring modest overheads to data usage.

column Share on MobileHub: No Programmer Effort for Power Efficiency with Sensor Hub Authors: Haichen Shen University of Washington University of WashingtonView Profile , David Wetherall University of Washington University of WashingtonView Profile , Aruna Balasubramanian Stony Brook University Stony Brook UniversityView Profile , Anthony LaMarca Intel IntelView Profile Authors Info & Claims GetMobile: Mobile Computing and CommunicationsVolume 19Issue 4October 2015 pp 9–12https://doi.org/10.1145/2904337.2904342Published:16 March 2016Publication History 0citation87DownloadsMetricsTotal Citations0Total Downloads87Last 12 Months2Last 6 weeks0 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my Alerts New Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

Cloud-based file synchronization services, such as Drop-box, are a worldwide resource for many millions of users. However, individual services often have tight resource limits, suffer from temporary outages or even shutdowns, and sometimes silently corrupt or leak user data. We design, implement, and evaluate MetaSync, a secure and reliable file synchronization service that uses multiple cloud synchronization services as untrusted storage providers. To make MetaSync work correctly, we devise a novel variant of Paxos that provides efficient and consistent updates on top of the unmodified APIs exported by existing services. Our system automatically redistributes files upon reconfiguration of providers. Our evaluation shows that MetaSync provides low update latency and high update throughput while being more trustworthy and available. MetaSync outperforms its underlying cloud services by 1.2-10×on three realistic workloads.

Datacenter transports aim to deliver low latency messaging together with high throughput. We show that simple packet delay, measured as round-trip times at hosts, is an effective congestion signal without the need for switch feedback. First, we show that advances in NIC hardware have made RTT measurement possible with microsecond accuracy, and that these RTTs are sufficient to estimate switch queueing. Then we describe how TIMELY can adjust transmission rates using RTT gradients to keep packet latency low while delivering high bandwidth. We implement our design in host software running over NICs with OS-bypass capabilities. We show using experiments with up to hundreds of machines on a Clos network topology that it provides excellent performance: turning on TIMELY for OS-bypass messaging over a fabric with PFC lowers 99 percentile tail latency by 9X while maintaining near line-rate throughput. Our system also outperforms DCTCP running in an optimized kernel, reducing tail latency by $13$X. To the best of our knowledge, TIMELY is the first delay-based congestion control protocol for use in the datacenter, and it achieves its results despite having an order of magnitude fewer RTT signals (due to NIC offload) than earlier delay-based schemes such as Vegas.

Datacenter transports aim to deliver low latency messaging together with high throughput. We show that simple packet delay, measured as round-trip times at hosts, is an effective congestion signal without the need for switch feedback. First, we show that advances in NIC hardware have made RTT measurement possible with microsecond accuracy, and that these RTTs are sufficient to estimate switch queueing. Then we describe how TIMELY can adjust transmission rates using RTT gradients to keep packet latency low while delivering high bandwidth. We implement our design in host software running over NICs with OS-bypass capabilities. We show using experiments with up to hundreds of machines on a Clos network topology that it provides excellent performance: turning on TIMELY for OS-bypass messaging over a fabric with PFC lowers 99 percentile tail latency by 9X while maintaining near line-rate throughput. Our system also outperforms DCTCP running in an optimized kernel, reducing tail latency by $13$X. To the best of our knowledge, TIMELY is the first delay-based congestion control protocol for use in the datacenter, and it achieves its results despite having an order of magnitude fewer RTT signals (due to NIC offload) than earlier delay-based schemes such as Vegas.

T oday’s smartphones provide a rich sensing platform that developers have used in tens of thousands of mobile applications. Many of these applications require continuous sensing for tasks ranging from simple step counting to more complex fall detection, sleep apnea diagnoses, dangerous driver monitoring and others. Unfortunately, continuous sensing applications are power-hungry. Interestingly, it is neither the sensors nor the computation that make these applications battery drainers. Instead, the main processor needs to be powered on frequently to collect sensor samples, in turn increasing the power consumption [12, 9, 13]. Hardware manufacturers recognize that supporting low-power continuous sensing is crucial. To this end, companies are embedding a low power microcontroller called a sensor hub in their smartphones [11, 10, 2]. Th e sensor hub continuously collects sensor data keeping the higher power main processor idle. In practice, however, sensor hubs fail to deliver on their power-effi ciency promise. Th e problem is in the diffi culty in programming them. For example, to leverage the sensor hub for a fall detection app, the developer not only needs to write the main application, but also needs to program the sensor hub to sense and notify the main application when a fall is detected. Two approaches have been used to make it easier for developers to program a sensor hub: APIs and hardware SDKs. In the API approach [4, 1], a set of important sensor inference functions are exported via high level APIs to the app developers. Th e problem is that the APIs only support a set of predefi ned events or activities such as step counting. Today, a fall detection application cannot use any of the existing APIs to leverage the sensor hub. It is possible that sensor hub APIs will stabilize, but this is unlikely to happen for many years. Consider how location APIs have evolved since the Java Location API (JSR 179) was introduced in 2003. Sensor hubs themselves have regularly been part of phones since 2011, but it is only in 2014 that a small set of sensor APIs are aligning around common functionality. In the meanwhile, ambitious sensing applications such as BeWell [3] cannot leverage the sensor hub for power effi ciency. In the hardware SDK approach, the developer is provided with specialized tools to directly access the sensor hub. For example, TI provides a proprietary TivaWare Sensor Library [5] to allow developers access to functionality not exposed by soft ware APIs. However, MobileHub: No Programmer Effort for Power Efficiency with Sensor Hub Haichen Shen and David Wetherall University of Washington Aruna Balasubramanian Stony Brook University Anthony LaMarca Intel

Always-on continuous sensing apps drain the battery quickly because they prevent the main processor from sleeping. Instead, sensor hub hardware, available in many smartphones today, can run continuous sensing at lower power while keeping the main processor idle. However, developers have to divide functionality between the main processor and the sensor hub. We implement MobileHub, a system that automatically rewrites applications to leverage the sensor hub without additional programming effort. MobileHub uses a combination of dynamic taint tracking and machine learning to learn when it is safe to leverage the sensor hub without affecting application semantics. We implement MobileHub in Android and prototype a sensor hub on a 8-bit AVR micro-controller. We experiment with 20 applications from Google Play. Our evaluation shows that MobileHub significantly reduces power consumption for continuous sensing apps.

Emerging wearable devices provide a new opportunity for mobile context-aware applications to use continuous audio/video sensing data as primitive inputs. Due to the high-datarate and compute-intensive nature of the inputs, it is important to design frameworks and applications to be efficient. We present the GlimpseData framework to collect and analyze data for studying continuous high-datarate mobile perception. As a case study, we show that we can use low-powered sensors as a filter to avoid sensing and processing video for face detection. Our relatively simple mechanism avoids processing roughly 60% of video frames while missing only 10% of frames with faces in them.

SPDY is increasingly being used as an enhancement to HTTP/1.1. To understand its impact on performance, we conduct a systematic study of Web page load time (PLT) under SPDY and compare it to HTTP. To identify the factors that affect PLT, we proceed from simple, synthetic pages to complete page loads based on the top 200 Alexa sites. We find that SPDY provides a significant improvement over HTTP when we ignore dependencies in the page load process and the effects of browser computation. Most SPDY benefits stem from the use of a single TCP connection, but the same feature is also detrimental under high packet loss. Unfortunately, the benefits can be easily overwhelmed by dependencies and computation, reducing the improvements with SPDY to 7% for our lower bandwidth and higher RTT scenarios. We also find that request prioritization is of little help, while server push has good potential; we present a push policy based on dependencies that gives comparable performance to mod_spdy while sending much less data.