Aaron Schulman

Bartendr: a practical approach to energy-aware cellular data scheduling

Cellular radios consume more power and suffer reduced data rate when the signal is weak. According to our measurements, the communication energy per bit can be as much as 6x higher when the signal is weak than when it is strong. To realize energy savings, applications must preferentially communicate when the signal is strong, either by deferring non-urgent communication or by advancing anticipated communication to coincide with periods of strong signal. Allowing applications to perform such scheduling requires predicting signal strength, so that opportunities for energy-efficient communication can be anticipated. Furthermore, such prediction must be performed at little energy cost. In this paper, we make several contributions towards a practical system for energy-aware cellular data scheduling called Bartendr. First, we establish, via measurements, the relationship between signal strength and power consumption. Second, we show that location alone is not sufficient to predict signal strength and motivate the use of tracks to enable effective prediction. Finally, we develop energy-aware scheduling algorithms for different workloads - syncing and streaming - and evaluate these via simulation driven by traces obtained during actual drives, demonstrating energy savings of up to 60%. Our experiments have been performed on four cellular networks across two large metropolitan areas, one in India and the other in the U.S.

Pingin' in the rain

Residential Internet connections are susceptible to weather-caused outages: Lightning and wind cause local power failures, direct lightning strikes destroy equipment, and water in the atmosphere degrades satellite links. Outages caused by severe events such as fires and undersea cable cuts are often reported upon by operators and studied by researchers. In contrast, outages cause by ordinary weather are typically limited in scope, and because of their small scale, there has not been comparable effort to understand how weather affects everyday last-mile Internet connectivity. We design and deploy a measurement tool called ThunderPing that measures the connectivity of residential Inter- net hosts before, during, and after forecast periods of severe weather. ThunderPing uses weather alerts from the US National Weather Service to choose a set of residential host addresses to ping from several vantage points on the Internet. We then process this ping data to determine when hosts lose connectivity, completely or partially, and categorize whether these failures occur during periods of severe weather or when the skies are clear. In our preliminary results, we find that compared to clear weather, failures are four times as likely during thunderstorms and two times as likely during rain. We also find that the duration of weather induced outages is relatively small for a satellite provider we focused on.

On the fidelity of 802.11 packet traces

Packet traces from 802.11 wireless networks are incomplete both fundamentally, because antennas do not pick up every transmission, and practically, because the hardware and software of collection may be under provisioned. One strategy toward improving the completeness of a trace of wireless network traffic is to deploy several monitors; these are likely to capture (and miss) different packets. Merging these traces into a single, coherent view requires inferring access point (AP) and client behavior; these inferences introduce errors. In this paper, we present methods to evaluate the fidelity of merged and independent wireless network traces. We show that wireless traces contain sufficient information to measure their completeness and clock accuracy. Specifically, packet sequence numbers indicate when packets have been dropped, and AP beacon intervals help determine the accuracy of packet timestamps. We also show that trace completeness and clock accuracy can vary based on load. We apply these metrics to evaluate fidelity in two ways: (1) to visualize the completeness of different 802.11 traces, which we show with several traces available on CRAWDAD and (2) to estimate the uncertainty in the time measurements made by the individual monitors.

An End-to-End Measurement of Certificate Revocation in the Web's PKI

Critical to the security of any public key infrastructure (PKI) is the ability to revoke previously issued certificates. While the overall SSL ecosystem is well-studied, the frequency with which certificates are revoked and the circumstances under which clients (e.g., browsers) check whether certificates are revoked are still not well-understood. In this paper, we take a close look at certificate revocations in the Webs PKI. Using 74 full IPv4 HTTPS scans, we find that a surprisingly large fraction (8%) of the certificates served have been revoked, and that obtaining certificate revocation information can often be expensive in terms of latency and bandwidth for clients. We then study the revocation checking behavior of 30 different combinations of web browsers and operating systems; we find that browsers often do not bother to check whether certificates are revoked (including mobile browsers, which uniformly never check). We also examine the CRLSet infrastructure built into Google Chrome for disseminating revocations; we find that CRLSet only covers 0.35% of all revocations. Overall, our results paint a bleak picture of the ability to effectively revoke certificates today.

RevCast: Fast, Private Certificate Revocation over FM Radio

The ability to revoke certificates is a fundamental feature of a public key infrastructure. However, certificate revocation systems are generally regarded as ineffective and potentially insecure: Some browsers bundle revocation updates with more general software updates, and may go hours, days, or indefinitely between updates; moreover, some operating systems make it difficult for users to demand recent revocation data. This paper argues that this sad state of affairs is an inexorable consequence of relying on unicast communication to distribute revocation information. We present RevCast, a broadcast system that disseminates revocation data in a timely and private manner. RevCast is not emulated broadcast over traditional Internet links, but rather a separate metropolitan-area wireless broadcast link; specifically, we have designed RevCast to operate over existing FM radio, although the principles apply to alternative implementations. We present the design, implementation, and initial deployment of RevCast on a 3 kW commercial radio station using the FM RDS protocol. With the use of two types of receivers (an RDS-to-LAN bridge that we have prototyped and an RDS-enabled smartphone), we show that, even at a low bitrate, RevCast is able to deliver complete and timely revocation information, anonymously, even for receivers who do not receive all packets all the time.

Timeouts: Beware Surprisingly High Delay

Active probing techniques, such as ping, have been used to detect outages. When a previously responsive end host fails to respond to a probe, studies sometimes attempt to confirm the outage by retrying the ping or attempt to identify the location of the outage by using other tools such as traceroute. The latent problem, however, is, how long should one wait for a response to the ping? Too short a timeout risks confusing congestion or other delay with an outage. Too long a timeout may slow the process and prevent observing and diagnosing short-duration events, depending on the experiments design. We believe that conventional timeouts for active probes are underestimates, and analyze data collected by Heidemann et al. in 2006--2015. We find that 5% of pings from 5% of addresses take more than 5 seconds. Put another way, for 5% of the responsive IP addresses probed by Heidemann, a false 5% loss rate would be inferred if using a timeout of 5 seconds. To arrive at this observation, we filtered artifacts of the data that could occur with too-long a timeout, including responses to probes sent to broadcast addresses. We also analyze ICMP data collected by Zmap in 2015 to find that around 5% of all responsive addresses observe a greater than one second round-trip time consistently. Further, the prevalence of high round trip time has been increasing and it is often associated with the first ping, perhaps due to negotiating a wireless connection. In addition, we find that the Autonomous Systems with the most high-latency addresses are typically cellular. This paper describes our analysis process and results that should encourage researchers to set longer timeouts when needed and report on timeout settings in the description of future measurements.