Harsha V. Madhyastha

Understanding the latency benefits of multi-cloud webservice deployments

Zhe Wu, Harsha V. Madhyastha
Appears in: 
CCR April 2013

To minimize user-perceived latencies, webservices are often deployed across multiple geographically distributed data centers. The premise of our work is that webservices deployed across multiple cloud infrastructure services can serve users from more data centers than that possible when using a single cloud service, and hence, offer lower latencies to users.

Public Review By: 
Katerina Argyraki

One of the benefits of hosting a web service in the cloud is closer proximity to the end-user: as a cloud typically consists of multiple datacenters, located in different places, a webservice provider can serve each client from the physically-closest datacenter, hence reduce user-perceived latency. This paper now tells us that hosting a web service in multiple clouds can further improve this benefit: by switching from a single-cloud to a multi-cloud deployment, 20-50% of IP prefixes would reduce their latency to the closest datacenter by more than 20%. These numbers are based on measurements from 265 PlanetLab nodes spanning multiple countries and all continents (with the exception of Africa). The authors report two reasons for this improvement: (i) cloud provider A may have a datacenter in a particular region, whereas cloud provider B does not; (ii) the routing toward cloud provider A's datacenter in a particular region may be significantly worse than the routing toward cloud provider B's datacenter in the same region. Whether these findings push webservice providers toward multicloud deployments or motivate ISPs to improve their routing, the reviewers agree that they are useful and, to some extent, unexpected. Moreover, the reviewers welcome more work on how to deal with latency fluctuations and how to improve quality of service in regions that are poorly served by all cloud providers.

A Generic Language for Application-Specific Flow Sampling

Harsha V. Madhyastha and Balachander Krishnamurthy
Appears in: 
CCR April 2008

Flow records gathered by routers provide valuable coarse-granularity traffic information for several measurement-related network applications. However, due to high volumes of traffic, flow records need to be sampled before they are gathered. Current techniques for producing sampled flow records are either focused on selecting flows from which statistical estimates of traffic volume can be inferred, or have simplistic models for applications. Such sampled flow records are not suitable for many applications with more specific needs, such as ones that make decisions across flows.

Public Review By: 
Chadi Barakat

The monitoring of Internet traffic has several applications as anomaly detection, traffic classification, accounting and traffic engineering. These applications have different requirements in terms of the volume of information to be analyzed. Some of them are satisfied with a simple summation of the payload sizes of all or a subset of packets while others require a deep analysis of headers and payloads to detect if there is something going wrong. This is the main reason for which traffic monitoring applications resist differently to any generic application-unaware traffic sampling deployed in routers to reduce the volume of the collected traffic. The purpose of the present paper is that instead of generically sampling the traffic, resort to an application-specific sampling where the application specifies its requirements in a certain language format, then a sampler uses these requirements to only keep from the traffic the flow records that are of interest to the application. A generic language has been developed in this paper to this end and it was applied and validated on three applications: Snort, Bro and BLINC. The experimental results show that with this language, one is able to keep from a traffic trace almost the same volume of information relevant to these three applications.
The originality of this paper is in the generality of the proposed language and its ability to specify the needs of several traffic monitoring applications. This language could on one hand reduce the volume of collected traffic and on another hand ease the life of application developers. In the present work, the advantage of the application-specific sampling has been validated on flow records. A validation on packet records could highlight more features of the proposed solution. And a remaining open issue is certainly how one can leverage such adaptive application-aware sampling to reduce the overhead on routers both in the core of the network and at the edge.

Syndicate content