Balakrishnan Chandrasekaran

The Internet at the Speed of Light

For many Internet services, reducing latency improves the user experience and increases revenue for the service provider. While in principle latencies could nearly match the speed of light, we find that infrastructural inefficiencies and protocol overheads cause todays Internet to be much slower than this bound: typically by more than one, and often, by more than two orders of magnitude. Bridging this large gap would not only add value to todays Internet applications, but could also open the door to exciting new applications. Thus, we propose a grand challenge for the networking research community: a speed-of-light Internet. To inform this research agenda, we investigate the causes of latency inflation in the Internet across the network stack. We also discuss a few broad avenues for latency improvement.

Tolerating SDN Application Failures with LegoSDN

Despite Software Defined Networks (SDN) proven benefits, there remains significant reluctance in adopting it. Among the issues that hamper SDNs adoption two stand out: reliability and fault tolerance. At the heart of these issues is a set of fate-sharing relationships: The first between the SDN-Apps and controllers, where-in the crash of the former induces a crash of the latter, and thereby affecting availability; and, the second between the SDN-App and the network, where-in a byzantine failure e.g., black-holes and network-loops, induces a failure in the network, and thereby affecting network availability. The principal position of this paper is that availability is of utmost concern -- second only to security. To this end, we present a re-design of the controller architecture centering around a set of abstractions to eliminate these fate-sharing relationships, and make the controllers and network resilient to SDN-App failures. We illustrate how these abstractions can be used to improve the reliability of an SDN environment, thus eliminating one of the barriers to SDNs adoption.

Back-Office Web Traffic on The Internet

Although traffic between Web servers and Web browsers is readily apparent to many knowledgeable end users, fewer are aware of the extent of server-to-server Web traffic carried over the public Internet. We refer to the former class of traffic as front-office Internet Web traffic and the latter as back-office Internet Web traffic (or just front-office and back-office traffic, for short). Back-office traffic, which may or may not be triggered by end-user activity, is essential for todays Web as it supports a number of popular but complex Web services including large-scale content delivery, social networking, indexing, searching, advertising, and proxy services. This paper takes a first look at back-office traffic, measuring it from various vantage points, including from within ISPs, IXPs, and CDNs. We describe techniques for identifying back-office traffic based on the roles that this traffic plays in the Web ecosystem. Our measurements show that back-office traffic accounts for a significant fraction not only of core Internet traffic, but also of Web transactions in the terms of requests and responses. Finally, we discuss the implications and opportunities that the presence of back-office traffic presents for the evolution of the Internet ecosystem.

Isolating and Tolerating SDN Application Failures with LegoSDN

Despite software-defined networkings proven benefits, there remains a significant reluctance in adopting it. Among the issues that hamper SDNs adoption, two issues stand out: reliability and fault tolerance. At the heart of these issues is a set of fate-sharing relationships: the first between the SDN control applications and controllers, wherein the crash of the former induces a crash of the latter, thereby affecting the controllers availability; and, the second between the SDN-Apps and the network, wherein the failure of the former violates network safety, e.g., network-loops, or network availability, e.g., black holes. In this paper, we argue for a redesign of the controller architecture centering around a set of abstractions to eliminate these fate-sharing relationships and thus improve the controllers availability. We present a prototype implementation of a framework, called LegoSDN, that embodies our abstractions, and we demonstrate the benefits of our abstractions by evaluating LegoSDN on an emulated network with five real SDN-Apps. Our evaluations show that LegoSDN can recover failed SDN-Apps 3x faster than controller reboots while simultaneously preventing policy violations.

A server-to-server view of the internet

While the performance characteristics of access networks and end-user-to-server paths are well-studied, measuring the performance of the Internets core remains, largely, an uncharted territory. With more content being moved closer to the end-user, server-to-server paths have increased in length and have a significant role in dictating the quality of services offered by content and service providers. In this paper, we present a large-scale study of the effects of routing changes and congestion on the end-to-end latencies of server-to-server paths in the core of the Internet. We exploit the distributed platform of a large content delivery network, composed of thousands of servers around the globe, to assess the performance characteristics of the Internets core. We conduct measurement campaigns between thousands of server pairs, in both forward and reverse directions, and analyze the performance characteristics of server-to-server paths over both long durations (months) and short durations (hours). Our analyses show that there is a large variation in the frequency of routing changes. While routing changes typically have marginal or no impact on the end-to-end round-trip times (RTTs), 20% of them impact IPv4 (IPv6) paths by at least 26 ms (31 ms). We highlight how dual-stack servers can be utilized to reduce server-to-server latencies by up to 50 ms. Our results indicate that significant daily oscillations in end-to-end RTTs of server-to-server paths is not the norm, but does occur, and, in most cases, contributes about a 20 ms increase in server-to-server path latencies.

A Universal Approach to Data Center Network Design

This paper proposes an approach to the design of large-scale general-purpose data center networks based on the notions of volume and area universality introduced by Leiserson in the 1980s in the context of VLSI design. In particular, we suggest that the principle goal of the network designer should be to build a single network that is provably competitive, for any application, with any network that can be built for the same amount of money. After describing our approach, we survey the technology choices available to network designers today, and examine several existing commercial data center networks. In the most recent of these networks resources are allocated roughly as we suggest in this paper.

Why is the internet so slow

In principle, a network can transfer data at nearly the speed of light. Today’s Internet, however, is much slower: our measurements show that latencies are typically more than one, and often more than two orders of magnitude larger than the lower bound implied by the speed of light. Closing this gap would not only add value to today’s Internet applications, but might also open the door to exciting new applications. Thus, we propose a grand challenge for the networking research community: building a speed-of-light Internet. To help inform research towards this goal, we investigate, through large-scale measurements, the causes of latency inflation in the Internet across the network stack. Our analysis reveals an under-explored problem: the Internet’s infrastructural inefficiencies. We find that while protocol overheads, which have dominated the community’s attention, are indeed important, reducing latency inflation at the lowest layers will be critical for building a speed-of-light Internet. In fact, eliminating this infrastructural latency inflation, without any other changes in the protocol stack, could speed up small object fetches by more than a factor of three.

Reducing Latency Through Page-aware Management of Web Objects by Content Delivery Networks

As popular web sites turn to content delivery networks (CDNs) for full-site delivery, there is an opportunity to improve the end-user experience by optimizing the delivery of entire web pages, rather than just individual objects. In particular, this paper explores page-structure-aware strategies for placing objects in CDN cache hierarchies. The key idea is that the objects in a web page that have the largest impact on page latency should be served out of the closest or fastest caches in the hierarchy. We present schemes for identifying these objects and develop mechanisms to ensure that they are served with higher priority by the CDN, while balancing traditional CDN concerns such as optimizing the delivery of popular objects and minimizing bandwidth costs. To establish a baseline for evaluating improvements in page latencies, we collect and analyze publicly visible HTTP headers that reveal the distribution of objects among the various levels of a major CDNs cache hierarchy. Through extensive experiments on 83 real-world web pages, we show that latency reductions of over 100 ms can be obtained for 30% of the popular pages, with even larger reductions for the less popular pages. Using anonymized server logs provided by the CDN, we show the feasibility of reducing capacity and staleness misses of critical objects by 60% with minimal increase in overall miss rates, and bandwidth overheads of under 0.02%.

Sounding the Bell for Improving Internet (of Things) Security

The fragility of the Internet of Things (iot) ecosystem poses serious threats to Internet security, and the proliferation of iot devices only exacerbates this situation by providing vulnerable end-points to be exploited and used as attack sources. While industry and academia are working hard on designing innovative solutions to detect, mitigate and thwart massive botnet-based ddos attacks, the space of solutions appears disjoint and fragmented. The lack of cooperation between the iot device manufacturers, network operators, content providers, end users, and other players precipitates in point solutions which offer at best a veneer of security. In this paper we alert the community to the security challenges posed by the fragile iot ecosystem, discuss the space of solutions, and present the need for a distributed, concerted effort, e.g., among end users, ISPs, and CDNs, to improve Internet security. We do not claim to solve the problem, but offer design guidelines and discuss the key implementation challenges to inform the debates on iot security.

Delorean: Using Time Travel to Avoid Bugs and Failures in SDN Applications

Bugs are endemic in software and SDN applications (SDNApps) are no exception. SDN controllers are fragile: crashes induced by bugs in SDN-Apps can, in the worst case, cripple the entire SDN stack [2,9]. Crashes of SDN-Apps result in service outages, which is simply a euphemism for loss of revenue. Businesses can lose, for instance, thousands of dollars per minute because of outages [1, 6–8]. We aim, hence, to minimize outages by tolerating SDN-App crashes, even in case of deterministic faults. Although the SDN community has made progress in terms of designing better (or more robust) SDN-Apps, and in weeding out bugs through sophisticated testing methods, the question of “How do you devise an online technique to safely and systematically circumvent a bug that manifests even in a welldesigned and well-tested SDN-App running in a production environment?” remains, largely, underexplored. LegoSDN [2] tackles the problem of SDN-App crashes head-on, offering a framework to rollback the effects of a crashed SDN-App and transform the crash-inducing input to handle deterministic faults. The system, however, blindly regards the last input as crash-inducing and treats SDN-Apps as black boxes. Orthogonal attempts to employ Paxos-style replication, e.g., Ravana [3] and Onix [4], lack support for tolerating deterministic faults. We treat failures as first-class citizens and, in the event of an SDN-App failure, propose Delorean to provide a quick, safe, online recovery of the SDN-App. At a high-level, the recovery comprises a rollback of both control-plane and dataplane changes, and a transformation of the crash-inducing input—modification of an input event to one or more semantically equivalent but syntactically different input event(s)— to handle even deterministic faults. Delorean employs symbolic execution (SE) to gain insight into the application logic. Through static analysis, Delorean discovers a set of possible code paths (i.e., path through the