2013 IEEE Seventh International Symposium on Service-Oriented System Engineering
Proximity-aware Cloud Selection and Virtual
Machine Allocation in IaaS Cloud Platforms
Hangwei Qian
VMware, Inc.
Palo Alto, CA, USA
qianhangwei@gmail.com
Abstract—Cloud platforms deploy data centers geographically
distributed around the world and application providers select
cloud infrastructures and allocate virtual machines based on the
requirements of their applications. While existing works focused
on the comparison on cloud services, we argue that proximity
also plays a very important role when deciding in which cloud
infrastructures to deploy the applications. In this position paper,
we take into account the location of cloud infrastructures,
application clients and related applications, and the interaction
among application components as well as the deployment cost
and propose to build a system to automatically select the cloud
infrastructures for customers. Meanwhile, we also discuss some
issues and give suggestions when allocating the virtual machines
within cloud infrastructures.
I. I NTRODUCTION
Cloud computing has obtained tremendous attention in
recent years and is pushing the IT industry into a new era.
According to Gartner, the worldwide market will be worth
$176.8 billion by 2015 [34]. One promise of cloud computing
is that cloud providers (CPs) deploy multiple cloud infras-
tructures (data centers, or DCs) distributed geographically
around the world so that applications are able to reach the
global footprints according to their business demands, known
as infrastructure as a service (IaaS). For example, Amazon
deploys data centers at North America, Europe and Asia [24].
Nowadays, many IaaS cloud providers exist in the industry,
such as Amazon, Google, Microsoft, RackSpace, to name a
few, and more would expect to emerge in the future. Given
the large number of data centers, how can customers (to
avoid the ambiguity, we refer the application providers as the
customers of cloud providers, and the ones that send requests
to applications as the clients of the applications) decide which
ones to choose to deploy their applications? Existing works,
such as Cloudcmp [22, 23], focused on the comparison of
the cost and performance of the cloud services to guide the
selection of the cloud infrastructures. Complementary to these
works, in this position paper, we outline a system which
automatically select the cloud infrastructures for customers so
that they can get rid of the complex selection task completely.
In order to be able to select the best cloud infrastructures
automatically, many challenges exist. First and foremost, we
should try to reduce the cost of application deployment as
much as possible. Different cloud providers have different
billing models. We should make the selection decision accord-
978-0-7695-4944-6/12 $26.00 © 2012 IEEE
DOI 10.1109/SOSE.2013.54
Qian Lv
Western Digital, Inc.
Irvine, CA, USA
lvqian.ncsu@gmail.com
ing to both the various billing models and the characteristics
of the applications. For example, storage-intensive and CPU-
intensive applications would have different preferences under
different billing models.
Also, we need to make sure that the performance of the
applications is able to meet the quality of service (QoS)
requirement. Multiple elements would affect the performance
of the applications, such as the capacity of the servers, storage
systems and networks of the cloud infrastructures. One im-
portant aspect that did not receive much attention but actually
would impact the performance significantly is the proximity.
When Internet clients access the applications deployed in the
cloud infrastructures, the network latency and bandwidth play
very an important role in the client-perceived QoS. According
to [30], there is strong inverse correlation between distance
and bandwidth. Thus, selecting the cloud infrastructures that
are close to clients can potentially reduce the network latency
and increase the available bandwidth during the interaction
between clients and servers significantly. Moreover, modern
applications often consist of multiple components geograph-
ically distributed around the world, making the selection of
cloud infrastructures more challenging.
Since the scale of the problem can be very large, we also
need to address the scalability problem. As mentioned above,
we need to consider multiple aspects in the selection of the
cloud infrastructures, making it a multi-objective optimization
problem. Given so many data centers and multiple application
components, we need to find efficient algorithms to make the
best decisions. More discussion is available at Section III-C.
Finally, our system also considers the virtual machine (VM)
allocation within a data center. After deciding which data
center to place a component, application providers still need to
consider other problems, such as what kind of virtual machines
to allocate and how many of them are needed so that they can
meet the performance requirements and minimize the cost,
etc. In this paper, we also discuss these issues and provide
suggestions for application providers.
In short, in the position paper, we introduces a system to
automatically select the cloud infrastructures and help allocate
virtual machines for customers, and make the the following
contributions:
• We discuss the challenges in the automatic selection of
cloud infrastructures and investigate preliminary solutions
403
 to these challenges.
• We take the location of cloud infrastructures, application
clients and related applications, as well as the interaction
of application components into account when selecting
the cloud infrastructures, which has not been done before
to our knowledge.
• We discuss issues and provide suggestions when allocat-
ing virtual machines within the cloud infrastructures.
II. P ROXIMITY
Qian et al. [30] found that generally the closer the two
communicating entities are, the less the network latency and
the higher the bandwidth are between them. This is because
requests travel less hops in the communication. Also, lower
round trip time between close entities allows more data to
be sent out during same period of time for TCP. In addition,
given the smaller number of hops between close entities, it is
less likely that congested links exist at the data routing path
assuming equal chance for each link to become overloaded.
When selecting the cloud infrastructures for an application,
we need to consider the location of cloud data centers, the
location of Internet clients of the applications, the relationship
of the components of the application as well as the location
of the related applications. In the following subsections, we
discuss them in details.
A. Data Center Distribution
As mentioned in section I, cloud providers often deploy
many data centers around the world, which can greatly meet
the requirements of distributed applications, such as stream
services (like Netflix, which has already utilized Amazon’s
cloud platform), content delivery networks (like Akamai) and
distributed database systems, etc. Knowing the data center
distribution of the cloud providers is a necessity for the success
of the cloud infrastructure selection.
We made a preliminary investigation of the data center
distribution of the main cloud providers through the search
on the Internet, which is shown in table I. Due to the limited
access of information, it can be considered as the low bound of
the data center distribution and is subject to change. From the
table, we can see that different cloud providers have different
policies to deploy their cloud infrastructures, and all the major
cloud platforms span multiple continents. Note that, for each of
cloud provider in the table, we have the references to the links
by which readers can get more information of data centers.
B. Client Distribution
Knowing where client requests are from enables application
providers to select cloud infrastructures that are close to their
clients. One question is, how can the application providers
know where the Internet clients come from? For applications
that exist already and are being transferred to cloud platforms,
application providers can mine the client information from
the application server logs, which contain not only the client
IP addresses, but also other important information, like how
frequently the clients access the applications. Alternatively,
404
client information can also be obtained from DNS logs. For
applications that are newly developed, it might be hard to
know the client distribution precisely. In this case, applica-
tion providers can make the estimation according to their
business relationships and characteristics of the applications
at their best effort. For example, the clients of California
state government web sites usually come from California.
Also, it is now relatively easier to migrate the applications
from one location to another with virtualized technology after
the precise client distribution information is available later
on. For example, applications can be wrapped up in Open
Virtualization Format (OVF) and transferred and deployed at
other cloud infrastructures
Another question is, how to organize the client information
effectively? Due to the huge number of Internet users, this is a
non-trivial task at all. We use clustering technique to solve the
problem and divide the Internet clients into client clusters, or
CCs. Within each client cluster, clients are close to each other,
and thus can be represented as a single entity. We can group
the clients into clusters based on the network-aware prefixes
[21], referred to as network-aware clustering. After knowing
the client IP addresses, we can extract their network-aware
prefix information from the Border Gateway Protocol (BGP)
tables and put the clients with the same prefix into the same
cluster. Note that, since this method needs to know the client IP
addresses, it can only be applied for existing applications that
have been deployed already and have the client information in
the logs.
Alternatively, we can cluster the Internet clients according
to the geographic locations, which we call regional clustering.
The benefit of this method is that it can be employed by
all the applications. For applications that have the client
information, we can extract their IP addresses and get their
location information from the GeoIP databases, such as [27].
For applications that do not have the client information yet,
application providers can provide geographic location informa-
tion based on estimation, such as from which cities, or states
the clients come from, etc.
In addition, it is necessary to know the distances between
the cloud infrastructures and the client clusters after obtaining
the location information of them. If we use the network-aware
clustering technique, then the distance would be the network
latency. We can simply allocate a dummy virtual machine
at each data center and get the network distances from each
data center to all the client clusters as well as the distances
among the data centers by ”ping” command. Since the distance
information is relatively very stable, this kind of measurement
can be conducted very infrequent, say, every month. Also,
the dummy virtual machines are only used for the simple
measurement, and do not have much resource consumption.
Thus this method is very cheap. There are also many existing
techniques for measuring or estimating the distance between
hosts and can also be applied in our system, like [15] and [17].
When using the regional clustering, the distance would be
the Euclidean distance between the entities. Note that, here
the Euclidean distance is used to approximate the network
 Cloud Provider Data Center Number Spanned State Number
Amazon [24] 15 15
Google [28] 36 27
Microsoft [3] 6 6
Rackspace [10] 8 8
AT&T [7] 37 24
Terremark [9, 14, 6] 43 26
Joyent [8] 4 4
TABLE I
DATA C ENTER D ISTRIBUTION
distance, which is applied in many real systems, such as
”Google Local” and ”Microsoft Live” [33].
C. Component Relationship
Modern applications usually consist of multiple components
interacting with each other. For example, it is common practice
that web applications have multi-tier architectures, including
web servers, application servers and back-end databases. At
each tier, there might be multiple replicas for high service
reliability and scalability. Furthermore, there are some highly
distributed applications that have many more components and
provide the services to Internet clients across the world. For
instances, content delivery networks (CDNs), such as Akamai
and Limelight, help deliver the content (such as videos and im-
ages) from the content providers to Internet clients. To ensure
the high bandwidth and low network latency of the service,
it is critical to bring the content close to the Internet clients,
necessitating the high distribution of the service components.
Other examples include multiplayer distributed online games
[4, 20], distributed database systems [5, 35], etc.
When deploying the applications in the cloud platforms,
it is very important to consider the proximity among the
application components. The interaction among the compo-
nents of applications plays an important role in the quality of
service of these applications. For example, the web servers
that receive client requests need to contact the application
servers which further need to access the back-end databases
before replying to the clients. In order to minimize the network
latency, it is better to place all the components in the same
location. However, the centralized deployment suffers from
the single point of failure. Cloud computing platforms are not
perfectly reliable. For example, many services are interrupted
by the failure of Amazon cloud platforms [12]. Furthermore,
some highly distributed applications, like the CDNs mentioned
above, requires the geographic distribution of the application
components across the world such that high bandwidth and
low network latency can be ensured. In addition, security
concern in the cloud platform may require that application
components are placed at different locations. When deploying
the applications in the cloud platforms, application providers
may prefer to host some components, such as the databases, at
the on-premises infrastructures so that they are still under their
own control for security reasons, and only put components
that are less security-sensitive at the cloud platforms. Also,
in the hybrid cloud, security-sensitive components usually run
405
Spanned Country Number Spanned Continent Number
8 3
12 4
3 3
4 3
11 4
17 4
2 2
at the private cloud and only computationally expensive and
less security-sensitive components are placed the at the public
cloud infrastructures.
In order to capture the relationship among the applica-
tion components, we can construct the interaction pattern
graph, G=(V,E), of the application. Each component has a
corresponding node in the graph G. When one application
component C1 interacts with another component C2, an edge
e(C1, C2) would be added between the C1 and C2. For each
edge, there would be a weight associated with it, which is the
volume of interactions between the two components in order
to serve a single client request. The bigger the weight is, the
more we need to pay attention to the proximity between the
corresponding components.
D. Related Applications
We also need to take into account of the location of the
related applications when selecting the cloud infrastructures
for an application. It is common that applications interact
with each other. For example, the financial systems need to
communicate with each other for many critical tasks, like
money transfer and credit card payments. Third-party geoIP
database services are often accessed by other applications
for IP and location information. Also, hospitals often share
patient information and need to communicate with each other.
It would be preferable to place the applications close to the
location of related applications to reduce the network latency
and increase the network bandwidth. The location information
of the related applications are relatively easy to obtain by
checking the behavior of each application components. Simi-
larly, we also need to consider the volume of communication
between the applications.
III. P ROXIMITY- AWARE C LOUD I NFRASTRUCTURE
S ELECTION
In this section, we discuss the selection of cloud infrastruc-
tures taking into account of both the price and proximity.
A. Environment
Each component of the application has its resource
requirement, which is represented by the vector <
CP U, M em, Disk, N etwork >. Assume there are M com-
ponents of the application, N cloud providers with overall W
data centers, L client clusters and R related applications. We
need to find a placement policy to deploy the M components
at the W data centers. Let P be the placement matrix of
 
  requirements for CPU, memory, network and storage. The
billing of different resources is also different for different
 cloud providers. For applications that are CPU-sensitive, like
data processing services, cloud infrastructures that charges less
on CPU (even though it may charge more on storage) are
   
 preferred. For network-sensitive applications, such as stream

services, it is better to choose the data centers that charge less

on network usages.

One thing that makes the problem more complex is that

some cloud providers offer infrastructures with better per-



formance than others. For example, according to [22], the
response time and throughput for an disk I/O operation is
different for different cloud providers. Thus, we can not simply
consider the price disregarding the quality of the cloud infras-

 
Fig. 1. System Graph
the components. If component COM Pi is deployed at the
data center DCj , then Pi,j = 1; otherwise, Pi,j = 0, for
i = 1, 2, ..., M, j = 1, 2, ..., W . Note that, some application
providers may prefer to deploy all the application components
at the data centers belonging to the same cloud provider,
which may provide extra benefit of better interconnection
among the data centers (some cloud providers, such as Google
and Microsoft, often have their own backbone networks to
interconnect their data centers [39].) In that case, an additional
constraint on the selected data centers can be applied. In this
paper, we assume that application components can be place at
any data center by default.
The interaction pattern graph of the application components
mentioned above is extended to also include the client clusters
and related applications, as shown in the system graph G=(V,E)
of figure 1 as an example. Each client cluster (only three, CC1,
CC2 and CC3 are shown in the figure) and related application
(like node F and G) also have a node in the graph, dubbed
client cluster node and application node respectively. An edge
is added from each client cluster to the component accessed
by the clients (like node A). Also, if a component visits a
related application, an edge is added between them, like the
edge e(B, F ). A value is associated with each edge, which
is the distance between the nodes. Note that, there is another
value on the edges between the components indicating the
volume of the interaction between the components, which is
not shown in the figure.
B. Objectives
When generating the placement policy matrix P , the system
tries to fulfill the following objectives:
Minimize the deployment cost. Different cloud providers
have different billing models. Even different cloud infrastruc-
tures belonging to the same cloud provider charge differently.
For example, according to [1], the Amazon data centers at
northern California charges $0.049 per hour for standard
reserved instances, while data centers at north Virginia charges
$0.039 per hour. Meanwhile, each application has the specific
406
tructures. In order to handle this problem, we normalize the
price over the performance quality of the cloud infrastructures.
Minimize the overall distances. In order to minimize the
overall network latency to enhance the quality of service
of applications, we should minimize the overall network
distances. It is more complicated than the classical K-Median
problem [11], as it not only needs to minimize the distances
from client clusters to the data centers that are selected to
deploy the application components, but also needs to minimize
the distances among the application components as well as the
distances between the components and the related applications.
C. Problem Hardness
It is a multi-objective optimization problem: deploying all
the components at the cheapest cloud infrastructure would
incur smallest cost, but might lead to larger user-perceived
response time, which would hurt the business. Noticing the
binary choice of each element in the placement matrix P , it
is a variation of the 0-1 integer linear programming problem,
which is NP-hard [2].
The complexity of this problem is O(W M ), which is
prohibitively expensive in computation. For example, suppose
there are 10 components of the application and 100 data
centers of all the cloud providers, there could be W M = 10010
placement policies. In order to deal with this problem, we give
each objective a weight indicating how important the objective
is, and then combine them into a single optimization problem
with one cost function. Meanwhile, in stead of checking each
possible placement policy, we propose a step-wise heuristic
algorithm in which we only decide the placement of one
component at a step. In this way, the complexity is reduced
to O(W.M ). We are still investigating this step-wise selection
algorithm, which is one of the main tasks in our ongoing work.
IV. L OCAL VM A LLOCATION
After knowing which data center to deploy each appli-
cation component, we need to allocate VMs at the se-
lected data centers for it. While this might seem straight-
forward in some sense, more issues should be considered
actually. For example, given the resource requirement <
CP U, M em, Disk, N etwork > of a component, we need
to decide how many VMs and what the size is of each
VM for the component. There can be multiple options. For
instance, one can allocate just a few or even a single VM
that can satisfy all the resource requirements, called ”Giant
VMs”, or allocate more VMs, each with smaller amount of
resources, called ”Tiny VMs”. The VMs would host replicas
of the component, which usually sit behind a load balancer
and form an application level cluster [29, 38]. In terms of
price, the ”Giant VMs” option is usually cheaper than the
”Tiny VMs” option, since ”Tiny VMs” have the minimum
memory requirement in order to work properly, incurring more
overall memory cost. Furthermore, more communications are
needed among the cluster replicas, which introduces more
network bandwidth consumption. However, ”Tiny VMs” is
more preferable in terms of reliability, since the failure of an
VM would not impact the availability of the component too
much compared with ”Giant VMs” option.
Another issue is the network configuration of the VMs.
Some data centers are connected with multiple ISPs to increase
the reliability of the network [39]. In these multi-homed data
centers, we need to decide from which ISP to allocate the
IP addresses for the VMs. Allocating IPs from the same ISP
for all the application components as much as possible can
potentially improve the network performance.
V. R ELATED W ORK
Several works on the comparing and selecting the cloud
services exist in the past years. The work in [22, 23] compared
the service performance of four major cloud providers to help
the customers choose cloud services. In [18], a conceptional
framework is proposed to compare the cloud services based
on the performance of virtual machines. Unlike their work, we
take the proximity into account and aim to build a system to
select the cloud infrastructures automatically for customers.
Also, authors in [31] introduced a mathematical formulation
and method of the cloud service selection based on multiple
abstract criteria. Different from it, our work intends to develop
a real system to automatically selection the infrastructures
in IaaS cloud platforms. In [16], an approach utilizing the
analytic hierarchy process is proposed to select the services
for software as a service cloud. Our work differentiate from
them in that we focus on the infrastructure as a service cloud,
in which the proximity should be considered explicitly, while
in software as a service cloud, only the overall service quality
needs to be considered. Finally, many work focus on the stor-
age services, like storage selection, security, storage backup
and deduplication etc., such as [32, 19, 13, 37]. Different from
them, this work considers the general applications.
In addition, to our knowledge, this work is the first one to
consider the interaction among application components and the
relationship with other applications when making the selection
of cloud services.
VI. C ONCLUSION AND F UTURE W ORK
In this position paper, we consider the deployment cost and
the location of cloud infrastructures, application clients, related
applications as well as the interaction among the application
407
components and propose to build a system to automatically
select the cloud infrastructures for customers.
In our ongoing work, we are developing heuristic algo-
rithms and implementing the system for extensive evaluation.
We would also consider to introduce tiered service model
[26, 25, 36] for the cloud provider, which classifies the service
into tiers and charge the service tiers at different prices.
R EFERENCES
[1] Amazon ec2 pricing. http://aws.amazon.com/ec2/pricing/.
[2] Integer programming. http://en.wikipedia.org/wiki/i
nteger programming.
[3] Microsft adds new data centers to Azure infrastruct
ure. http://www.datacenterdynamics.com/focus/arch
ive/2012/04/microsft-adds-new-data-centers-azure-
infrastructure.
[4] Daniel Bauer, Sean Rooney, and Paolo Scotton. Net-
work infrastructure for massively distributed games. In
NetGames. ACM, 2002.
[5] Philip A. Bernstein and Nathan Goodman. Concurrency
control in distributed database systems. In ACM Comput.
Surv. ACM, 1981.
[6] Asia Pacific Data Centers.
http://www.terremark.com/data-centers/asia-pacific.aspx.
[7] AT&T Data Centers. http://www.datacentermapping.com/
data-centers/provider/at&t.
[8] Joyent Data Centers. http://joyent.com/products/joyent-
cloud/data-centers.
[9] North America Data Centers.
http://www.terremark.com/data-centers/americas.aspx.
[10] Rackspace Global Data Centers.
http://www.rackspace.com/whyrackspace/network/
datacenters/.
[11] Moses Charikar, Sudipto Guha, Éva Tardos, and David B.
Shmoys. A constant-factor approximation algorithm for
the k-median problem. In STOC. ACM, 1999.
[12] Amazon EC2 data center fail-
ure affects Netflix Instagram.
http://www.electronista.com/articles/12/06/30/storms.in.n
orth.virginia.takes.out.amazon.data.center/.
[13] Fred Douglis, Deepti Bhardwaj, Hangwei Qian, and
Philip Shilane. Content-aware load balancing for dis-
tributed backup. In LISA. USENIX, 2011.
[14] Middle East Europe and Africa Data Centers.
http://www.terremark.com/data-centers/europe-middle-
east-africa.aspx.
[15] Paul Francis, Sugih Jamin, Cheng Jin, Yixin Jin, Danny
Raz, Yuval Shavitt, and Lixia Zhang. Idmaps: a global
internet host distance estimation service. In IEEE/ACM
Trans. Netw. IEEE Press, 2001.
[16] Manish Godse and Shrikant Mulik. An approach for se-
lecting software-as-a-service (saas) product. In CLOUD.
IEEE, 2009.
[17] Krishna P. Gummadi, Stefan Saroiu, and Steven D. Grib-
ble. King: estimating latency between arbitrary internet
end hosts. In IMW. ACM, 2002.
[18] Seung-Min Han, Mohammad Mehedi Hassan, Chang- Hsu. Characteristics of backup workloads in production
Woo Yoon, and Eui-Nam Huh. Efficient service recom- systems. In FAST. USENIX, 2012.
mendation system for cloud computing market. In ICIS. [38] W. Zhang, H. Qian, C.E. Wills, and M. Rabinovich. Agile
ACM, 2009. resource management in a virtualized data center. In
[19] Seny Kamara and Kristin Lauter. Cryptographic cloud ACM WOSP/SIPEW, 2010.
storage. In FC. Springer, 2010. [39] Zheng Zhang, Ming Zhang, Albert Greenberg, Y. Charlie
[20] Rajesh Krishna Balan, Maria Ebling, Paul Castro, and Hu, Ratul Mahajan, and Blaine Christian. Optimizing
Archan Misra. Matrix: adaptive middleware for dis- cost and performance in online service provider net-
tributed multiplayer games. In Middleware, 2005. works. In NSDI. USENIX, 2010.
[21] B. Krishnamurthy and J. Wang. On network-aware
clustering of web clients. In ACM SIGCOMM, 2000.
[22] Ang Li, Xiaowei Yang, Srikanth Kandula, and Ming
Zhang. Cloudcmp: comparing public cloud providers.
In IMC. ACM, 2010.
[23] Ang Li, Xiaowei Yang, Srikanth Kandula, and Ming
Zhang. Cloudcmp: shopping for a cloud made easy. In
HotCloud. USENIX, 2010.
[24] Where Amazons Data Centers Are Located.
http://www.datacenterknowledge.com/archives/2008/11/1
8/where-amazons-data-centers-are-located/.
[25] Qian Lv and George N. Rouskas. On Optimal Sizing of
Tiered Network Services. In INFOCOM. IEEE, 2008.
[26] Qian Lv and George N. Rouskas. An economic model
for pricing tiered network services. In ICC. IEEE, 2009.
[27] Maxmind. http://www.maxmind.com.
[28] Map of all Google data center locations.
http://royal.pingdom.com/2008/04/11/map-of-all-google-
data-center-locations/.
[29] Hangwei Qian, Elliot Miller, Wei Zhang, Michael Rabi-
novich, and Craig E. Wills. Agility in virtualized utility
computing. In VTDC, 2007.
[30] Hangwei Qian, Michael Rabinovich, and Zakaria Al-
Qudah. Bringing local dns servers close to their clients.
In GLOBECOM, 2011.
[31] Zia ur Rehman, Farookh K. Hussain, and Omar K.
Hussain. Towards multi-criteria cloud service selection.
In IMIS. IEEE, 2011.
[32] Arkaitz Ruiz-Alvarez and Marty Humphrey. An auto-
mated approach to cloud storage service selection. In
ScienceCloud. ACM, 2011.
[33] Hanan Samet, Jagan Sankaranarayanan, and Houman
Alborzi. Scalable network distance browsing in spatial
databases. In SIGMOD. ACM, 2008.
[34] Sizing the Public Cloud Services Market.
http://softwarestrategiesblog.com/2011/07/02/sizing-
the-public-cloud-services-market/.
[35] Alexander Thomson, Thaddeus Diamond, Shu-Chun
Weng, Kun Ren, Philip Shao, and Daniel J. Abadi.
Calvin: fast distributed transactions for partitioned
database systems. In SIGMOD. ACM, 2012.
[36] Vytautas Valancius, Cristian Lumezanu, Nick Feamster,
Ramesh Johari, and Vijay V. Vazirani. How many tiers?:
pricing in the internet transit market. In SIGCOMM.
ACM, 2011.
[37] Grant Wallace, Fred Douglis, Hangwei Qian, Philip Shi-
lane, Stephen Smaldone, Mark Chamness, and Windsor

408