My colleague Alison Powell and I have just published an article that explores this discrepancy. “Net Neutrality Discourses: Comparing Advocacy and Regulatory Arguments in the US and the UK,” published in the forthcoming issue of The Information Society, develops a comparative analysis of US and UK net neutrality debates with an eye toward identifying the arguments for and against regulation, how those arguments differ between the countries, and what the implications of those differences are for the Internet. Drawing on mass media, advocacy, and regulatory discourses, we found that local regulatory precedents as well as cultural factors contribute to both agenda-setting and framing of net neutrality. The differences between national discourses provide a way to understand both the structural differences between regulatory cultures and the substantive differences between policy interpretations, both of which must be reconciled for the Internet to continue to thrive as a global medium.

• BT
• O2
• Sky
• TalkTalk
• Virgin: Links to each package’s KFI here and a sample KFI here.

BT offers essentially five broadband service plans: BT Total Broadband Options 1, 2 and 3 (which are DSL plans) and BT Infinity Options 1 and 2 (which are fiber plans). Customers on all plans are subject to the 300GB “atypical user” cap, which causes their connection speeds to be reduced when they hit the monthly cap. Customers on all plans are also subject to BT’s network management policy, causing P2P traffic speeds to be reduced every evening and weekend. Finally, customers on Total Broadband Options 1 and 2 and Infinity Option 1 have additional monthly caps (10GB, 40GB, and 40GB, respectively). Customers who surpass those monthly volume limits are charged £5 per 5GB of overage.

So while eliminating the 300GB cap (the details of which were never made wholly transparent in the first place) may be a welcome move, the caps that can cause customers to be charged overage fees (as AT&T’s caps reportedly will do) are all still in place, and no customers can avoid having their P2P traffic throttled every day of the week. Compare that to AT&T’s offerings — with volume caps that will apparently be an order of magnitude higher than BT’s in some cases and where individual applications are not singled out for throttling — and the contrast starts to seem a little less stark.

Traffic management provides one place to start on both of these endeavors. Since the FCC made its original Internet policy principles “subject to reasonable network management” in 2005, the issue of whether traffic management practices that discriminate between different applications, types of applications, or applications protocols are acceptable has been central to the Internet neutrality debate both in the US and abroad. More than a year ago, the Canadian telecom regulator, the CRTC, issued its own framework for evaluating ISPs’ traffic management practices. The framework expresses preferences for technical traffic management practices that:

• address the need and achieve the purpose and effect in question, and nothing else;
• result in discrimination or preference as little as reasonably possible;
• minimize any harm to a secondary ISP, end-user, or any other person; and
• achieve a purpose that cannot be achieved through network investment or economic approaches (e.g., pricing) alone.

This framework presents a strong preference for non-discriminatory traffic management, but stops short of disallowing discrimination altogether. Perhaps as a result, more than a year after the framework’s adoption, a substantial number of the largest Canadian ISPs, including Bell Canada (whose traffic management aimed at peer-to-peer applications originally spurred the CRTC to action), continue to state in their traffic management policies that they discriminate against particular applications or applications protocols. For those of us hoping for a better (i.e., less- or non-discriminatory) result in the US, how does the FCC’s new definition of reasonable network management compare? Take a look:

A network management practice is reasonable if it is appropriate and tailored to achieving a legitimate network management purpose, taking into account the particular network architecture and technology of the broadband Internet access service. (FCC Order para. 82)

The Commission goes on to clarify a number of points about this definition. While traffic management practices need to be “tailored,” they need not be “the most narrowly tailored practice theoretically available” (perhaps stopping a bit shy of the CRTC’s requirement that a practice may address “nothing else” other than its singular purpose). The FCC also explains that its evaluation of the reasonableness of traffic management practices will be based on the same principles it will use to evaluate potential violations of its broader “no unreasonable discrimination” rule (laid out in an earlier section of the order), specifically calling out the principles of “transparency, end-user control, and use- (or application-)agnostic treatment.” With particular relevance to discrimination, the use-agnostic treatment principle states the FCC’s presumption that “differential treatment of traffic that does not discriminate among specific uses of the network or classes of uses is likely reasonable.” Thus, as a baseline, it seems that traffic management practices that are blind to application types or protocols are likely to be deemed reasonable.

Although it is not explicitly listed as a “principle” that will guide the Commission’s evaluations of traffic management practices, the order does raise concerns about discriminatory practices (in general) that harm ISPs’ actual or potential competitors, end users, or free speech. If such concerns were to factor into traffic management evaluations, they would be not unlike the third prong of the CRTC’s framework, and they may close the door on traffic management that, for example, targets peer-to-peer file-sharing (which could potentially be construed as causing any of the harms listed).

In sum, the CRTC goes a bit further in its explicit language about narrowness and harm while the FCC is more explicit about its presumption of reasonableness for non-discriminatory practices. The impact of the FCC order on traffic management is of course not solely dependent on the text of the rules; if case adjudications begin to materialize, we will gain even more insight as to the future of non-discriminatory traffic management. Case adjudication may well have contributed to the current state of affairs in Canada — the fact that the CRTC allowed Bell Canada to continue its discriminatory practices at the same time it adopted the traffic management framework may well have sent a signal to other Canadian ISPs about which practices would be considered reasonable. In any event, drilling down on the FCC order provides meaningful guidance about how traffic management may evolve in the US. While a handful of deeper dives on this and other aspects of the rules have appeared, more are certainly in order.

As the dispute has unfolded, opinions have proliferated as to which company is in the wrong and who is exerting market power over whom. Without knowing all of the commercial details, it is difficult to interpret each company’s claims. But a vague picture of the situation is beginning to emerge.

Comcast has been a transit customer of Level 3 for a number of years (“transit” and other relevant terms are defined below). With 17 million subscribers, recently upgraded residential broadband capacity, and one of the Internet’s largest shares of inter-domain traffic, the size of Comcast’s network has allowed it to peer with many other large networks, but it still requires some transit to provide access to the full Internet, which is why it buys access from Level 3, Tata, Global Crossing, and perhaps other transit providers.

At times, Comcast has sought to peer with certain networks, and those networks have refused, as often happens in the process of negotiating such arrangements. Some observers have claimed that when networks refuse to peer with Comcast, Comcast routes their traffic over its Tata transit connection, which Comcast purposefully runs in a congested state so as to induce those networks to become peers.

Comcast has also been charging content delivery networks (CDNs) like Akamai and Limelight to interconnect (and, in some cases, to colocate their CDN servers in Comcast’s facilities). This provides better performance for the CDN content since it need not traverse transit links to reach Comcast’s users. It is unclear whether Verizon, AT&T, and other residential ISPs charge CDN companies similar rates to what Comcast charges for interconnection (Level 3 claims that Comcast’s charges are higher ). But Comcast is certainly not alone in charging fees to CDNs. Verizon, for example, charges CDNs for direct interconnection at regional hubs under its Partner Port Program.

Netflix, which by one account has been driving 20% of downstream Internet traffic in North America at peak times, recently shifted a substantial portion of its content from Akamai to Level 3 (although it retains commercial relationships with both Akamai and Limelight). This has led many observers to speculate as follows: after sealing the deal with Netflix, Level 3 informed Comcast that its interconnecting traffic would be increasing by more than a factor of two; realizing that this increase would be caused by Netflix content hosted on Level 3’s CDN, Comcast informed Level 3 that it would be charging Level 3 as a CDN. Level 3, which may have won Netflix’s business by, among other things, charging Netflix a lower price than competitors could afford on the assumption that it would not be paying Comcast to deliver Netflix traffic to Comcast’s subscribers, was angered by this and decided to make the dispute public and call for regulatory intervention.

Level 3’s claim is that Comcast’s actions violate net neutrality. It is difficult to see how Comcast’s demands could be construed as discriminating against particular content, applications, or services on the wire or in the routing infrastructure (especially if Comcast’s claim that Level 3 never mentioned Netflix during their negotiations is true ). The arrangement between the two companies seems to be based on quantities of traffic, not traffic content. So it is unlikely that this dispute raises net neutrality concerns of the sort that the FCC has been grappling with over the past several years. But whether Comcast designs its CDN pricing structure based on what traffic it thinks the interconnecting CDNs are hosting is certainly a valid question. Netflix was competing with Comcast’s TV and video-on-demand services before it moved some of its business from Akamai to Level 3. There was no public dispute about discrimination at that time, but that does not mean it was not occurring.

Might there be other reasons for regulatory intervention (even, as Level 3 has suggested, in the context of the Comcast-NBC Universal merger review)? Learning more of the facts would be a useful first step and one that regulators are uniquely positioned to help with. How much was Comcast paying Level 3 under the transit agreement? Were the two networks exchanging peering traffic on a settlement-free basis? How much do Comcast’s competitors charge for CDN interconnection? Were Comcast’s demands unreasonable by comparison? Does Comcast purposefully run its Tata link congested so as to convince networks to enter into peering relationships?

The answers to these questions are needed before passing judgment about who is in the wrong and who should be paying whom. The Comcast customer base creates significant demand for online content, including movie and TV streams from Netflix. By offering its service, Netflix creates significantly increased demand for the content it distributes. In accordance with the long-standing Internet model where every end user pays his own way, Netflix and customers of Comcast are both already paying their respective providers, Level 3 and Comcast, for Internet access. But when it comes to which of those providers should bear the brunt of the cost of the increased traffic demand, it is not immediately clear whether that cost should fall entirely on one side or the other, or be shared between the two.

That there is a cost associated with increased traffic demand should not be in doubt, however. Although the price of bandwidth is falling, the potential for increased demand created by services like Netflix streaming is massive. Comcast has indicated that Level 3 requested 27 additional ports as part of the negotiation, suggesting a 270 gigabit per second peak capacity requirement for the Netflix traffic. Such an increase added to current peak-hour traffic could easily come with a multi-million dollar price tag for backhaul capacity alone.

Who should bear this cost? The answer depends in part on one’s characterization of the competitiveness of the residential broadband market. Some observers have claimed that Comcast is able to strong-arm Level 3 into paying for interconnection because Comcast serves as the gatekeeper to all its own customers. But that is the case with every residential ISP – they all have terminating monopolies. Verizon, AT&T, and other ISPs are not having the same disputes with Level 3 (at least not in public), which means that there is something unique in the Comcast situation. It may well be the size of the Comcast network, which allows it to gain more favorable terms over comparatively smaller CDN businesses like that of Level 3. It may also be the case that, as the nation’s largest ISP, Comcast need not worry about losing customers if the performance of some services degrade while they sit behind the supposedly congested Tata link, whereas the other ISPs are in a more precarious position when it comes to customer retention. But that would indicate that there actually is residential ISP competition, not the opposite.

Shedding some additional light on the traditionally murky world of interconnection agreements would go a long way towards clarifying some of these ambiguities. But as regulators venture into this space, they should be cognizant of the global nature of these issues. The market for Internet interconnection has undergone rapid change in recent years and the dispute between Level 3 and Comcast is representative of the kinds of strains that have crept in to interconnection agreements among large network operators in countries all over the world. While previous policy issues surrounding broadband Internet openness may have been insulated from the Internet’s global dimension, venturing into the agreements that govern the network of networks will undoubtedly take the policy debate across national borders.

Glossary
(see Complexity of Internet Interconnections: Technology, Incentives and Implications for Policy for an excellent primer on these topics)

• Transit – An interconnection arrangement in which a smaller networks pays a larger networks for access to the rest of the Internet.

• Peering (also known as settlement-free peering) – An interconnection arrangement in which two similar-sized networks agree to exchange traffic only with each other for no fee. For agreements between very large networks, the peers are usually expected to keep the ratio of traffic flowing in each direction to around 2:1.

• Paid peering (also known as settlement-based peering) – Like peering, except one party pays the other, usually because the traffic ratio between the two networks is asymmetric.

• Tier 1 network – A networks that reaches the entire rest of the Internet solely through peering. The Tier 1 networks peer only with each other and do not pay any transit or paid peering fees. Examples include Level 3, Global Crossing and Sprint.

• Content delivery network (CDN) – A network that distributes content by locating it close to end users. Exactly how close the content is located to users depends on the interconnection arrangements between CDNs and residential ISPs. Some CDNs pay to interconnect with ISPs. Examples of CDNs include Akamai and Limelight.

Without knowing all of the commercial details, it’s hard to know what to make of Level 3’s recent claim that Comcast is threatening the openness of the Internet by requiring Level 3 to pay Comcast a fee to deliver Level 3 traffic to Comcast subscribers. But as the companies have traded arguments in both directions (see Comcast’s initial comments, Level 3’s response, and Comcast’s FCC ex parte), certain aspects of the spat are starting to become a little more clear. The companies had an existing peering arrangement, which Comcast is seeking to renegotiate in light of increased traffic volume coming from Level 3.  Level 3 would rather not pay for a peering connection that used to be settlement-free. While the renegotiation was clearly precipitated by Level 3’s new video streaming deal with Netflix, it’s difficult to see how Comcast’s demands could be construed as targeting particular content, application, or service. The arrangement between the two companies is clearly based on quantities of traffic, not traffic content. So it’s unlikely that this dispute raises net neutrality concerns of the sort that the FCC has been grappling with over the past several years.

This doesn’t mean there aren’t valid questions to be raised. Is Comcast demanding higher fees from Level 3 than it would from other content delivery networks with the same traffic levels? Does Level 3 have alternative ways of interconnecting with Comcast’s network (e.g., transit) that would allow Comcast customers to obtain the content hosted on Level 3’s CDN in the absence of a paid peering arrangement between the two companies? If there’s one sure outcome of this dispute, it will be increased attention to these and other interconnection-related questions within the policy community and among policymakers. The growth of online video is fueling dramatic changes in the Internet’s global topology (see last year’s Atlas Internet Observatory Report) that are putting strains on the traditional peering and transit arrangements that have supported end-to-end interconnection in the past. Engaging policy-minded folks from the US and around the world about how these changes will and should play out will benefit the Internet as a whole; trying to shoehorn the disagreement between Level 3 and Comcast into the current process of creating net neutrality rules will not.
 

Two weeks ago I had the opportunity to participate at the RTC (Real-Time Communications) Web Workshop, a gathering focused on addressing what technical standards work is necessary to make real-time communications a reality on the web. Engineers and standards veterans from Cisco, Skype, Google, Mozilla, and a number of other companies spent the day debating and discussing an exciting array of potential services and applications that the union of RTC and the web could make possible, including browser-to-browser calling (even between users of different services, like Skype and Google Talk), multi-user features like conferencing and screen sharing, and browser-to-phone or browser-to-VoIP-phone calling. So many applications that were once confined to desktop software have migrated to the web, and it was exciting to spend the day identifying what needs to happen for RTC applications to join their ranks.

Although the discussions were wide-ranging, they returned time and again to the topic of securing RTC against snooping and attack. To achieve reasonable call quality, RTC more or less requires two users to be able to communicate over a direct link between them. On the web, this would mean direct browser-to-browser communication, which is uncommon today and, if implemented without proper security mechanisms, has the potential to create new avenues for attackers. As with other sensitive web communications (like bank transactions and online purchases), the communications channels also need to be encrypted and the encryption keying material secured against attack. Workshop participants gave a number of thoughtful talks about how to address these and other security challenges, and there was general agreement in the room that security risks in many deployment scenarios could be sufficiently mitigated using either existing or soon-to-be-developed mechanisms.

The discussions resulted in a sizable list of work items for technical standards bodies to consider pursuing and it was obvious that engineers in the room are already hard at work writing code to make RTC on the web come to fruition. But it struck me that their ability and incentive to do so would be drastically reduced if the FBI’s recent proposal to require communications applications to be wiretap-friendly became law. Although details of the FBI proposal remain vague, two of its core components would require communications providers to be able to decrypt encrypted messages and intercept peer-to-peer connections for law enforcement purposes. Having spent the day discussing precisely how to prevent such intrusions in RTC systems on the web, it seems unlikely that RTC applications providers would be willing to build the necessary back doors into new web-based products, especially given the fact that those back doors will undoubtedly be exploited by attackers. Given the choice between developing a new web-based application containing known vulnerabilities or not developing anything new, the latter seems far more likely.

Furthermore, introducing a mandate to retrofit existing services with wiretap capabilities would likely occupy time and engineering resources that are usually dedicated to product development and innovation. For applications developers like those at the RTC-Web workshop who have spent countless hours ensuring that the security of their products is air-tight, undoing all of that work so as to provide law enforcement access will be a sizable endeavor that will surely detract from new product development.

Bringing RTC to the web will no doubt provide a wealth of new and innovative ways for consumers and businesses to communicate in the future. But the specter of mandated eavesdropping capabilities calls all of that potential into question, not only for web-based communication, but for communications innovations of all kinds.