Content delivery networks must balance a number of trade-offs when deciding how to direct a client to a CDN server. Whereas DNS-based redirection requires a complex global traffic manager, anycast depends on BGP to direct a client to a CDN front-end. Anycast is simple to operate, scalable, and naturally resilient to DDoS attacks. This simplicity, however, comes at the cost of precise control of client redirection. We examine the performance implications of using anycast in a global, latency-sensitive, CDN. We analyze millions of client-side measurements from the Bing search service to capture anycast versus unicast performance to nearby front-ends. We find that anycast usually performs well despite the lack of precise control but that it directs roughly 20% of clients to a suboptimal front-end. We also show that the performance of these clients can be improved through a simple history-based prediction scheme.

For more than a decade, special purpose DNS [1] servers have been used to direct users to different IP addresses based on characteristics such as proximity, load balancing and failover. In this paper, we examine two of the mechanisms these special purpose DNS servers may use to control user traffic:-short time-to-lives (TTL) and time-splicing multiple responses. We find that although 2% of users are still using a stale DNS response after 15 minutes (despite a 20 second TTL), 90% of user requests will have switched to a new answer within 60 seconds. Further, when trying to direct users to two different locations in the ratio 90:10, we find time-splicing CNAME and A responses (corresponding to the two locations, respectively) is incompatible with a commonly deployed recursive resolver, and results in a ratio policy closer to 10:90. Overall we found that although DNS TTLs are not always respected, we are able manage load at a coarse granularity - provided time-spliced responses are of the same response type.

Recent trends in the networked services industry (e.g., CDN, VPN, VoIP, IPTV) see Internet Service Providers (ISPs) leveraging their existing network connectivity to provide an end-to-end solution. Consequently, new opportunities are available to monitor and improve the end-to-end service quality by leveraging the information from inside the network. We propose a new approach to detect and localize end-to-end service quality issues in such ISP-managed networked services by utilizing traffic data passively monitored at the ISP side, the ISP network topology, routing tables and geographic information. This paper presents the design of a generic service quality monitoring system “Argus”. Argus has been successfully deployed in a tier-1 ISP to monitor millions of users of its CDN service and assist operators to detect and localize end-to-end service quality issues. This operational experience demonstrates that Argus is effective in accurate, quick detection and localization of important service quality issues.

In this extended abstract we explore the architectural components of a Cloud Control Architecture with the aid of a number of cloud computing use cases. We specifically consider cloudbursting and follow-the-sun and focus on the mechanisms and user/provider interactions that would make these scenarios real. We are particularly concerned with the coordination of cloud and networking resources and mechanisms that would be applicable to cloud providers that are also network service providers.

Routing oscillation is highly detrimental. It can decrease performance and lead to a high level of update churn placing unnecessary workload on router the problem is distributed between many providers. However, iBGP --- the routing protocol used to distribute routes inside a single Autonomous System --- has also been shown to oscillate. Despite the fact that iBGP is configured by a single provider according to apparently straight forward rules, more than eight years of research has not solved the problem of iBGP oscillation. Various solutions have been proposed but they all lack critical features: either they are complicated to implement, restrict routing flexibility, or lack guarantees of stability. In this paper we propose a very simple adaptation to the BGP decision process. Despite its simplicity and negligible cost we prove algebraically that it prevents iBGP oscillation. We extend the idea to provide routing flexibility, such as respecting the MED attribute, without sacrificing network stability.

What does a childpsilas search of a large, complex cartoon for the eponymous character (Waldo) have to do with Internet routing? Network operators also search complex datasets, but Waldo is the least of their worries. Routing oscillation is a much greater concern. Networks can be designed to avoid routing oscillation, but the approaches so far proposed unnecessarily reduce the configuration flexibility. More importantly, apparently minor changes to a configuration can lead to instability. Verification of network stability is therefore an important task, but unlike the childpsilas search, this problem is NP hard. Until now, no practical method was available for large networks. In this paper, we present an efficient algorithm for proving stability of iBGP, or finding the potential oscillatory modes, and demonstrate its efficacy by applying it to the iBGP configuration of a large Tier-2 AS.