February 26, 2013 1 Comment
Last week, I had the pleasure of sitting on a panel at the Broadband Breakfast Club in downtown Washington, DC. The panel was organized by BroadbandBreakfast.com, an policy and news organization that focuses on policy issues related to broadband service in the United States; the group meets about once a month. I was asked last fall to sit on a panel on measuring broadband performance, due to our ongoing work on BISmark, but I was unable to make it last fall, so I found myself on a panel on data caps in wired and wireless networks.
I participated on the panel with the following other panelists: Serena Viswanathan, an attorney from the Federal Trade Commission; Patrick Lucey from the New America Foundation; and Roger Entner, the founder of Recon Analytics. The panel discussed a variety of topics surrounding data caps in broadband networks, but the high level question that the panel circled around was: Do data caps (and tiered pricing) yield positive outcomes for the consumer?
We had an interesting discussion. Roger Entner espoused the opinion that data caps really only affect the worst offenders, and that applications on mobile devices now make it much easier for users to manage their data caps. Therefore, data caps shouldn’t be regarded as oppressive, but rather are simply a way for Internet service providers and mobile carriers to recoup costs for the most aggressive users. Patrick Lucey, who recently wrote an article for the New America Foundation on data caps, stated a counterpoint that echoed his recent article, suggesting that data caps were essentially a profit generator for ISPs, and consumers are effectively captured because they have no real choice for providers.
I spent some time explaining the tool that Marshini Chetty and my students have built on top of BISmark called uCap (longer paper here). Briefly, uCap is a tool that allows home network users to determine the devices in their home that consume the most data. It also allows users to see what domains they are visiting that consume the most bandwidth. It does not, however, tell the user which applications or people are using the most bandwidth (more on that below). Below is a screenshot of uCap that shows device usage over time. My students have also built a similar tool for mobile devices called MySpeedTest, which tells users which applications are consuming the most data on their phones. A screenshot of the MySpeedTest panel that shows how different applications consume usage is shown below.
|uCap Screenshot Showing Device Usage Over Time
||MySpeedTest Showing Mobile Application Usage|
I used these two example applications to argue that usage caps per se are not necessarily a bad thing if the user has ways to manage these usage caps. In fact, we have repeatedly seen evidence that tiered pricing (or usage caps) can actually improve both ISP profit and make consumers better off, if the consumer understands how different applications consume their usage cap and has ways to manage the usage of those applications. Indeed, our past research has shown how tiered pricing can improve market efficiency, because the price of connectivity more closely reflects the cost to the provider of carrying specific data. Further, we’ve seen examples where consumers have actually been worse off when regulators have stepped in to prevent tiered pricing, such as the events in summer 2011 when KPN customers all experienced a price increase for connectivity because KPN was prevented from introducing two tiers of service.
The problem isn’t so much that tiered pricing is bad—it is that users don’t understand it, and they currently don’t have good tools to help them understand it. In the panel, I informally polled the room—ostensibly filled with broadband experts—about whether they could tell me off the top of their heads how much data a 2-hour high-definition Netflix movie would consume against their usage cap. Only two or three hands went up in a room of 50 people. I also confessed that before installing uCap and watching my usage in conjunction with specific applications, I had no idea how much data different applications consumed, or whether I was a so-called “heavy user” (it turns out I am not). My own experience—and Marshini Chetty’s ongoing work—has shown that people are really bad at estimating how much of their data cap applications consume. One interesting observation in Marshini’s work is that people conflate the time that they spend on a site with the amount of data it must consume (“I spend most of my time on Facebook, therefore, it must consume most of my data cap.”).
If we are going to move towards pervasive data caps or tiered pricing models, then users need better tools to understand how applications consume data caps and to manage how different applications consume those caps. I see two possibilities for better applications going forward:
- Better visibility. We need applications like uCap and MySpeedTest to help users understand how different applications consume their data cap. Helping users get a better handle on how different applications consume data is the first step towards making tiered pricing something that users can cope with. In addition to the applications that show usage directly, we might also consider other forms of visibility, such as information that helps users estimate a total cost of ownership for running a mobile application (e.g., the free application might actually cost the user more in the long run, if downloading the advertisements to support the free application eats into the user’s data cap). We also need better ways of fingerprinting devices; applications like uCap still force users to identify devices (note the obscure MAC addresses in the dashboard above for devices on my network that I didn’t bother to manually identify). Solving these problems requires both deep domain knowledge about networking and intuition and expertise in human factors and interface design.
- Better control. This area deserves much more attention. uCap offers some nice first steps towards giving users control because it helps users control how much data a particular device can send. But, shouldn’t we be solving this problem in other ways, as well? For example, we might imagine exposing an SDK to application developers that helps them write applications that are more cognizant of data constraints—for example, by deferring updates when a user is near his or her cap, or deferring downloads until “off peak” times or when a user is on a WiFi network. There are interesting potential developments in both applications and operating systems that could make tiered pricing and demand-side management more palatable, much like appliances in our homes are now being engineered to adapt to variable electricity pricing.
Finally, Patrick made a point that even if users could understand and control usage caps, they often don’t have any reasonable alternatives if they decide they don’t like their current ISP’s policies. So, while some of the technological developments we discussed may make a user’s life easier, these improvements are, in some sense, a red herring if a user cannot have some amount of choice over their Internet service provider. This issue of consumer choice (or lack thereof) does appear to be the elephant in the room for many of the policy discussions surrounding data caps, tiered pricing, and network neutrality. Yet, until the issues of choice are solved, improving both visibility and control in the technologies that we develop can allow both users and ISPs to be better off in a realm where tiered pricing and data caps exist—a realm which, I would argue, is not only inevitable but also potentially beneficial for both ISPs and consumers.