Computer
Sciences
Department
RouteBazaar: An Economic Framework for Flexible Routing
Holly Esquivel
Chitra Muthukrishnan
Feng Niu
Shuchi Chawla
Aditya Akella
Technical Report #1654
April 2009
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Guidelines and tips
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Computer Sciences Department - Computer Sciences Dept., Lecture notes of Network Design
University of Wisconsin - Madison. ABSTRACT ... visibility into network topology and routes, providing users ... Otherwise, we note that all non-monopolies.
Typology: Lecture notes
2022/2023
1 / 15
This page cannot be seen from the preview
Don't miss anything!
Related documents
Partial preview of the text
Download Computer Sciences Department - Computer Sciences Dept. and more Lecture notes Network Design in PDF only on Docsity!
Computer
Sciences
Department
RouteBazaar: An Economic Framework for Flexible Routing
Holly Esquivel
Chitra Muthukrishnan
Feng Niu
Shuchi Chawla
Aditya Akella
Technical Report
April 2009
RouteBazaar: An Economic Framework for Flexible Routing
Holly Esquivel, Chitra Muthukrishnan, Feng Niu, Shuchi Chawla, Aditya Akella
University of Wisconsin - Madison
ABSTRACT
The Internet’s routing protocol provides users a single end- to-end route that is not guaranteed to be available or to meet user requirements. Our paper addresses this rigidity using an economically grounded approach that appeals both to users and to service providers. We propose a framework called RouteBazaar in which service providers announce links con- necting different parts of the Internet, along with dynamically changing prices associated with using the links. All topology information is exposed to end-users. Users simply use routes that best match their cost-performance requirements. The ap- peal to users is that they can always obtain a route of their choice as long as they are willing to pay for it. The appeal to providers is that our framework offers them means for mon- etary gains as long as they are willing to offer greater visibil- ity into their topology and greater flexibility in user routes. We present both centralized and distributed versions of this framework. Both versions are designed to supplement, not supplant, BGP. We design a variety of algorithms to ensure robustness and stability of either framework. We study the framework using a simplified game-theoretic model and also conduct large scale simulations of its performance in practice using real and synthetic network topologies. We find that de- spite allowing flexibility to both users and service providers, our system operates at a stable and close-to-optimal state.
1. INTRODUCTION
The BGP routing protocol forms the backbone of the In- ternet today. It enables end-users to communicate with dif- ferent corners of the Internet and has played a key role in the growth of the network. Unfortunately, BGP suffers from key drawbacks that constrain the Internet and the applica- tions running on it in various ways [26, 3, 22, 10, 29]. A key constraint of BGP is that it offers end-users very limited visibility into network topology and routes, providing users exactly one policy-constrained path per destination. There is no guarantee that the single route that BGP provides will meet an end-user’s requirements. Most importantly, the route is not guaranteed to be available [3]. Approaches that have been proposed to address these chal- lenges and improve end-user experience, such as overlay rout- ing [27, 3] and multihoming [2, 4], are either undesirable in practice or inadequate [2]. The flexibility offered by over- lay routing to end-users has undesirable interactions with ISP policies and traffic engineering objectives. Multihoming can offer better performance than single BGP paths, but it still
cannot guarantee meeting users’ end-to-end requirements sat- isfactorily (e.g., routes are not guaranteed to be available). We argue that overcoming the rigidity in BGP—i.e., the poor visibility into routes and no flexibility in routing—requires an alternate, economically-grounded approach. We believe that service providers will be willing to expose greater amounts of information to users, and/or offer them greater flexibility in routing, as long as this leads to suitable monetary compen- sation. Equivalently, users who have the means will spend money to buy the additional visibility and flexibility as long as their requirements are guaranteed to be met. Our work asks whether it is possible to develop a flexible and robust economic framework to match the desires of users with those of service providers. A crucial requirement of the framework is that it attract participation from both users and service providers. There- fore, it should explicitly account for the local goals of both users and service providers, making robustness to selfish be- havior a first class design requirement. This offers flexibil- ity simultaneously to users and service providers, and fosters greater participation from both, without requiring any kind of global oversight. A secondary requirement is that the frame- work exist alongside BGP and other existing systems such as multihoming and overlay routing. This ensures that when- ever user and service provider requirements are misaligned, users can fall back to the existing mechanisms. We describe and study such a framework called Route- Bazaar. Providers participating in RouteBazaar announce (virtual) links connecting different locations of the Internet, along with the price associated with routing over them. Cru- cially, providers have the flexibility of dynamically altering the link prices so as to control quality of their links and, more importantly, to attract traffic and maximize their rev- enue. Users of RouteBazaar will have complete visibility into the links and paths offered by service providers via the system. Crucially, users will always be able to find a route over RouteBazaar to the destination of their choice that best meets their constraints as long as they have the willingness to pay for it. A user’s route in RouteBazaar could be com- posed of links from different providers (each with a diffe- rent price). Each user settles payments with each individual provider along the paths she uses. RouteBazaar encourages competition among service providers and makes it easy for newcomers to participate in our system. In particular, providers can use dynamic pricing as a tool to attract traffic from users who are not connected directly to
retically analyzed the economic aspects of bandwidth pricing under various models (see, e.g., [19, 1, 5, 24, 14]). Among these the model considered by Chawla and Roughgarden [14] is the most relevant to our setting. Chawla and Roughgarden analyze the price of anarchy of a bandwidth pricing game in which service providers pick prices to maximize their rev- enue and users pick paths to maximize their utilities. The price of anarchy is the worst gap between the performance of an equilibrium (stable state) in this game to the optimal per- formance that may be achieved through centralized control. They show that the price of anarchy for this bandwidth pric- ing game can be large when there is a large disparity between the values of different users and the network contains many “monopolistic” service providers. In Section 5 we expand on these results and show that under mild and natural assump- tions on the distribution of users’ values in the network, the price of anarchy improves considerably. Our simulations in Section 6 support these findings.
3. OVERVIEW OF RouteBazaar
We start by briefly stating the architectural features of our framework and comparing against BGP routing. (1) Separating route visibility from economics. Our sys- tem is designed to separate payment and economics from vis- ibility into network topology. Specifically, economic con- straints of service providers in our system should not limit users’ knowledge of, and their ability to potentially use, dif- ferent paths in the network. In BGP routing, providers imple- ment a variety of economics-driven import and export poli- cies on route announcements that filter out topology and route information before it reaches end-users. (2) Optimal routes for users who are willing to pay. Users of the system should be able to route to their corre- sponding destinations using our system as long as they have the means to pay for the route provided by our system. Thus, only a user’s willingness to pay determines whether or not she will find a route with our system. Today, end-networks who are willing to pay can afford to buy connectivity from one or more large ISPs with global reach. While such ISPs have greater reachability to various parts of the Internet, merely connecting to them does not guarantee that an end-to-end route will be available no matter how much a user pays. In order to accommodate user constraints well and to en- courage participation, we additionally require that the routes provided by our system be optimal from the user’s perspec- tive. In other words, there should be no cheaper route in the system that also meets the users constraints. (3) Service provider flexibility. In order to encourage par- ticipation from service providers, our system should similarly offer them flexibility as well. We require that service provider constraints be accommodated by letting them set prices for the services they offer any way they want in order to attract traffic and boost revenue. Because of the hop-by-hop nature of Internet routing, today, a service provider’s constraints are specified implicitly in the form of a collection of long-
term bi-lateral relationships with neighboring networks. The binding, bi-lateral nature of these contracts constrains service providers from offering a rich variety of flexibly-priced ser- vices to users who transit their networks. Our system allows service providers to vary prices for their services at finer time-scales. More importantly, the price im- posed by a service provider is charged to all traffic routed over its links, irrespective of where it originates. Users who route atop our system pay each on-path service provider for the services they used. Thus our framework allows a service provider to attract a user who may not be directly connected to it to route over its links and potentially boost its revenues further. In contrast, ISPs today can only charge customers who are directly connected to them. We present a high-level description of our RouteBazaar framework next. Design details and specific algorithms that we use to enable the above features are discussed in §4. Assumptions. Our description of the RouteBazaar frame- work in this section makes a few assumptions. The service offered by each service provider in our sys- tem is providing a route between two points in the Internet at some cost per unit bandwidth consumed on the path between the points. We use the term connectivity service providers or CSPs to describe the service providers. Each user of the system wishes to use the system to route to a specific destination. Someone wishing to route to multiple destinations could be represented by a collection of end-users each wishing to route to one of the destinations. Users may enter and leave the system at any time. But we assume that this happens at a very low rate. At any given time, some of the potential users of the sys- tem may be denied a route. This is because the system may be unable to provide routes with prices that match the user’s willingness to pay and other requirements of the user. We as- sume that all such users fall back to using default BGP routes. We assume that a source routing-based system such as Pathlet routing [17], MIRO [33] or NIRA [34] is available for users to route traffic along the paths specified by the sys- tem. The specific approach does not matter as long as it offers scalable support for source routing.
3.1 The RouteBazaar Framework
We now describe the two sets of participants in our frame- work, the service providers and users, and their behavior. Connectivity service providers: Our system is composed of multiple connectivity service providers (CSPs) that offer to connect different Internet locations. Each location is akin to a point-of-presence today and each link is a virtual connection of a fixed maximum capacity between the locations. Each CSP can own multiple virtual links of different capacities. Each CSP announces a price per unit bandwidth for the links it owns. The link could have different prices. We assume that the CSP link graph connects users to their destinations. Users: We envision the system to be used by medium to large end-networks, including enterprises (single or multi-
campus), universities, data centers, and even regional Inter- net service providers that wish to provide their customers ro- bust transit across the wide-area network. Each such user E wishes to purchase some amount of bandwidth between its own location and the location of some destination D. An user attaches some value per unit demand for its traf- fic. This reflects the user’s willingness to pay per unit traffic to the destination D. We model this using a demand-value vector, 〈B, V 〉E,D. An entry 〈bi, vi〉 in this vector indicates that the user E is willing to pay at least vi per unit traffic for bi units of traffic to the destination D. We assume that the users’ values are local to the users, and provided to our system as inputs. Depending on a user’s local requirements, the demand-value vectors to a destination may change slowly over time based, for example, on the time of the day or day of the week. CSP and user behavior: Each CSP participating in Route- Bazaar is revenue-maximizing in that it sets prices so that the net revenue derived from the collection of links owned is maximal. In particular, CSPs may change their link prices over time, especially when the current prices are deemed sub- optimal given the price choices of other CSPs in the system. We assume that the CSPs are unaware of the values of the users and cannot distinguish between the users. The only feedback available to them from the system is the amount of traffic willing to use their links at their current prices. A CSP’s revenue per link is the amount of user demand routed on the link times the price per unit demand. However, whenever the load on link exceeds it capacity, we assume that the CSP derives no revenue from the link. We assume that users select routes in a utility-maximizing fashion: given the prices of each CSP link, the routes em- ployed by a user are such that the user’s utility —the differ- ence between the value derived by the user and the price it pays—is maximized on a per destination basis. How a user uses the bandwidth provided by our system is purely based on local policies. A user may apply a local traffic classification algorithm and use its outcome to deter- mine which traffic to route using the bandwidth allocated to it by the system. The rest of the user’s traffic is routed in a best-effort manner using current BGP-based paths. We now present two flavors of RouteBazaar, one based on a centralized arbiter and the other completely distributed.
3.2 Centralized RouteBazaar Architecture
In the centralized variant of RouteBazaar, we assume the presence of a logically central, neutral arbiter service with whom both users and CSPs communicate. The arbiter service coordinates the actions and choices of users and CSPs and tries to accommodate their requirements and goals. The CSPs provide as input to the arbiter the list of links they own, the locations that the links connect, and the capac- ity of the links. Users provide as input their demands and the value per unit demand. Recall that we assume users to arrive or leave slowly over time. In our description of the central-
ized architecture below, and of the distributed architecture in the next subsection, we assume for simplicity that the set of users (and CSPs) remains fixed and does not change. We dis- cuss how to accommodate low-rate churn in Sections 4 and 6. The arbiter’s role is to simulate the behavior of both the users and the CSPs (as per the behavior outlined in §3.1 above) and find a stable state for the system that is acceptable to all parties. It runs the simulation until an equilibrium is reached. The arbiter determines the following:
- The prices that CSPs should charge for their links.
- Which users get to route their demand over the CSP net- work and those who must route using default BGP routes.
- For the former set of users in #2 above: a. The routes to the corresponding destinations over the CSP network that the users must use. b. The split-up of users’ demands across these routes. The arbiter communicates this information to the CSPs and users, who can then choose to follow or ignore the arbiter’s advice in picking their respective strategies. In order for the arbiter’s solution to be stable and accept- able to CSPs and users, it must form a Nash equilibrium [30]. At equilibrium the following properties are satisfied:
- No CSP has the incentive to unilaterally deviate from the current offered price in order to boost its revenue. Further- more, no CSP observes a load > 1 on its links.
- All users employ utility-maximizing paths and have no incentive to route over alternate paths. If there exists a path whose price is less than a user’s value per unit de- mand, then all of the user’s demand is routed using Route- Bazaar. If the price of the least-cost path equals the user’s value for the traffic, the user’s traffic may be split between RouteBazaar and regular BGP routes. Flexible global policies: A feature of the centralized ap- proach is that it allows the arbiter to impose flexible policies in order to try to ensure some global properties are satis- fied, while ensuring that the local, selfish goals of the vari- ous player (CSPs and users) are also honored. For instance, one set of policies could ensure that, at equilibrium, a certain minimum amount of demand from each geographic region is guaranteed routes over the CSP network, irrespective of the values of the users located at each geographic location. This introduces some level of fairness into the system. Another set of policies could ensure that the net value derived across all users who end up using the system is maximized. While this can ensure global optimality in terms of net value, this policy could result in unfairness. A final set of policies could enforce some combination of fairness and value-optimality.
3.3 Distributed RouteBazaar Architecture
At a high level, the distributed architecture works in roughly the same fashion as the centralized approach. As before, CSPs can adjust their prices to boost their revenue. Users select routes over the collection of CSPs to maximize their utility. However, there are three key aspects that differentiate the distributed and the centralized architectures.
Parameters: k, the number of different prices; N = k^2 ; α, the weighting parameter for EWMA. Variables: Randomness parameter ǫt = min(N/t log t, 1); for every potential price i, a revenue estimate πi. Initialization: For every price i, πi = 0. At every iteration t do:
- With probability ǫt, pick a price i uniformly at random and report it.
- Otherwise (i.e. with probability 1 − ǫt), pick the price i with the maxi- mum πi and report it.
- Let the revenue obtained at the current step be X. Update the revenue estimates for i as follows: πi = απi + (1 − α)X.
Figure 1: Algorithm epsilon-decreasing explore-exploit — Regret-minimizing learning algorithm for CSPs Parameters: k, the number of different prices; L = the capacity of the link times maximum price; randomness parameter ǫ = 0. 01 and weight δ = 0. 01. Variables: Weights wi and probabilities pi for every potential price i. W = P i wi, and^ pi^ =^ wi/W^. Initialization: For every price i, wi = 1 and pi = 1/k. W = k.
At every iteration do:
- With probability ǫ, pick a price i uniformly at random and report it.
- Otherwise (i.e. with probability 1 − ǫ), pick a price i randomly from the distribution p and report it.
- Let the revenue obtained at this step be X. Update wi as follows: wi = wieδX/LP^ where P = ǫ/k + (1 − ǫ)pi. Other weights stay the same.
- Update the probability vector p by setting pj = wj /W for every j, where W is the new sum of all the weights.
Figure 2: Algorithm Hedge-Bandit —Regret-minimizing learning algorithm for CSPs
give more weight to newer knowledge gained and less to his- torical data compared to a simple average. This is especially important in a dynamic environment where demands come and go, because a price that was attractive historically may become unattractive over time. The EWMA approach allows the algorithm to adapt quickly to such changes. We present this algorithm formally in Figure 1. The hedge-bandit algorithm also “explores” at every it- eration with an ǫt probability. However, in this algorithm ǫt continues to remain at a constant value and does not de- crease over time. The crucial difference between the two al- gorithms is in their “exploit” step. Instead of picking the best- in-history price at every exploit step, Hedge-bandit picks a price from a probability distribution that assigns high pro- bability to prices with high revenues and low probability to other prices. The probability associated with prices that con- sistently perform poorly decreases exponentially over time. Therefore, Hedge-bandit quickly converges to good prices while not entirely disregarding prices that perform moder- ately. This allows it to adapt quickly to changes in the system such as the arrival or departure of demands. We present this algorithm formally in Figure 2.
4.2 Distributed Architecture: User Behavior
As described earlier, the goal of every user is to maximize the utility it derives from routing its traffic – this is the differ- ence between the value it obtains from routing its traffic and
Parameters: Selfishness parameter ǫs; granularity parameter δ. Variables: H, a list of paths used in the previous iteration; L, a list of currently least-cost paths; fP , flow on path P ; r, the amount of flow to be redistributed at any iteration. Initialization: H = ∅. At every iteration t do:
- Construct L by finding all least-cost paths.
- Initialize r = 0. For every path P in H \ L, increment r by ǫsfP if fP ≥ δ and fP otherwise; Set fP = fP − r.
- Let ftot = P P ∈L max(fP^ , δ).^ For every path^ P^ in^ L, set^ fP^ = fP + r/ftot max(fP , δ).
Figure 3: Distributed flow-update algorithm for users
the price it pays to the CSPs. Therefore, every user distributes its traffic over least cost paths between its source and desti- nation, and uses the default BGP path for traffic with value less than the price on the least cost paths. In what follows, we use the term “user” to denote all traffic from some source to some destination with the same per-unit-flow value. In the basic version of the user algorithm, each user main- tains a list of the paths that it currently uses, as well as a list of currently least-cost paths. At every iteration the user removes all traffic from paths that are not currently least-cost, and spreads this traffic across least-cost paths in proportion to the traffic already carried by them. Additionally, the user treats the default BGP path as another available source-destination path in the system with price equal to the user’s per-unit-flow value. When the price on the least-cost path is smaller than the user’s value, it sends some fraction of its flow on the de- fault BGP path. This algorithm is described in Figure 3. We also study a smoother version of this flow-update algo- rithm with the goal of understanding whether slow updates to users’ flow lead to better convergence properties. Similar algorithms [8, 7] have been employed to solve flow problems in distributed settings and have been theoretically shown to have good convergence times. In our setting in particular, be- cause the system is dynamic, just like the CSPs, users may benefit from using historical data to determine good paths. In the smoother version, once again each user gradually moves its traffic from paths used in the previous iteration to those that currently charge the least price. In particular, each user removes an ǫs fraction of its flow from non-least-cost paths and distributes it over least-cost paths. The parameter ǫs characterizes user selfishness — ǫs = 1 corresponds to the basic “selfish” version where users al- ways only use least-cost paths, while ǫs < 1 corresponds to the “smooth” version where users give weight to historically good paths and occasionally route over non-least-cost paths. While on the one hand the smooth version is more robust to sudden random fluctuations in CSP prices, on the other hand, it may adversely affect performance because CSPs get slower feedback to their price changes. In §6 we study the impact of ǫs on the performance of the system.
4.3 Centralized Architecture
The goal of the central arbiter is to compute a “good”
max
X u
X P ∈Pu
vufP,u subject to X u
X P ∈Pu,P ∋e
fP,u ≤ ce ∀e X P ∈Pu
fP,u ≤ du ∀u
u : user with source su, destination du, value vu, demand du Pu : the set of all shortest paths for user u fP,u : the flow of user u on path P e : edges with capacities ce
Figure 4: Value maximizing LP for the central arbiter
equilibrium for the system. It does so through an iterative approach, by simulating CSP behavior and user behavior at each step. Specifically at each iteration it first picks prices for each CSP and then flow paths for each user, until some termination condition is met. We now elaborate on these two aspects of the centralized architecture. Simulating CSP behavior: The central arbiter simulates the system as a repeated game among the CSPs. In any repeated game if each player employs a regret minimizing learning algorithm for picking its strategy, then the game con- verges to a correlated equilibrium [18, 12]. That is, no player has incentive to deviate from its strategy if other players con- tinue to follow their strategies. The central arbiter therefore uses one of the two algorithms, epsilon-decreasing explore- exploit and hedge-bandit , described in § 4.1. Simulating user behavior: At every iteration given prices for the CSPs, the central arbiter simulates user behavior by routing the flow of each user along the least cost path. De- spite this constraint of following the best response, the arbiter has a lot of flexibility in routing flow because some source- destination pairs may have multiple least cost paths between them. Moreover, for some users the cost of the least cost path may be exactly equal to their value in which case routing their flow over this path or over the default BGP path brings equal utility to them. The arbiter may use this flexibility to imple- ment any desirable social objective. Here we focus on the objective of maximizing the total social value of the system. To achieve this objective, the arbiter solves the following max-value flow problem: It first determines for every user a list of all least cost paths between the corresponding source- destination pair. It then determines the amount of flow to be sent by the user along every such least cost path while honoring capacity constraints on edges and maximizing total value of the flow routed. This problem can be set up as a linear program (Fig 4) and solved using standard LP solvers. While the solution to the LP maximizes the value routed subject to capacity constraints, it may not follow best re- sponse for every user. This is because if for some user the cost of the least cost path is strictly less than the user’s value, it is in the best interest of the user to route its entire flow, while the LP may only route a fraction of the flow in order to satisfy capacity constraints. In order to rectify this, for every user with value strictly larger than the cost of the least cost
path, the arbiter finds an arbitrary least cost path and routes the entire remaining flow of the user along this path. We now elaborate on how the arbiter computes a list of all shortest paths for a user in order to set up the aforemen- tioned LP. The arbiter first computes all-pairs-shortest-path distances given the CSP prices. It then determines for every source, the set of edges that lies on some shortest path start- ing at that source. An edge (u → v) lies on a shortest path starting at source s if and only if dist(s, v) = dist(s, u) + price(u → v). The arbiter then runs a depth-first search (DFS) starting from the source and only following edges that lie on shortest paths. Every time it encounters the destination in this DFS, it outputs the current path from the source to the destination. This algorithm takes time proportional to the number of shortest paths between a source-destination pair. We find in our simulations that the number of distinct short- est paths between any source-destination pair is at least one order of magnitude smaller than the number of edges in the graph. Therefore this algorithm is efficient in practice. Termination condition: The arbiter could use a variety of tests to determine when to halt the simulation of the in- teraction between users and CSPs. In general, a good test is to check if the system is at a state where the total utility as perceived by both CSPs and users does not improve any further. The arbiter should also check for other conditions that the system should meet at equilibrium (§3.2). In our im- plementation of the arbiter, we check to see if in addition to the above conditions, over a certain large number I of itera- tions, the net utility in the system does not seem to improve or change significantly. Specifically, we check if the differ- ence between the 95th and the 5th percentile net utilities is less than a small fraction (say 5%) of the 95th percentile.
4.4 Evaluating RouteBazaar Performance
A natural metric for measuring the performance of Route- Bazaar is to quantify the total value it offers to the partici- pants (CSPs and users). Define the social value of a state of the system to be the total utility of all the agents, or, the to- tal value obtained by all the users, minus the prices paid by the users, plus the revenues (prices) earned by all the CSPs. Since prices are endogenous to the game this is equivalent to the total value obtained by all the users. Throughout this paper we use this metric to understand how well our system performs. In particular, we compare it against the optimal or the maximum possible social value achievable through global oversight while satisfying capacity constraints on edges. In the next section we discuss various factors that influence this metric and analytically study how the system behaves in var- ious situations. Several other key metrics can also be used to evaluate the system; we discuss these in §6.
4.5 Churn
Users of RouteBazaar enter or leave the system only oc- casionally. RouteBazaar is designed to accommodate slow churn. In the centralized framework, we require that users
depend on the value disparity. That is, all Nash equilibria in the system are good. The MHR condition, defined below, is widely used in game theory and economics to character- ize commonly occurring value distributions (see, for exam- ple, [11, 9]). Most natural distributions such as the uniform, normal, exponential, power-law (for exponents greater than one), Laplace, chi-square, etc. satisfy this condition [9].
Definition 1 (The Monotone Hazard Rate (MHR) condition) For a given user and a value v , let F (v) denote the fraction of traffic for which the user is willing to pay a per-unit-demand value of at most v_. Let_ f denote the derivative of the func- tion F_. The MHR condition states that the “hazard rate” of the value-demand curve,_ h(v) = (^1) −f^ (Fv ()v) , is a monotonically non-decreasing function of v_._
Theorem 3 Consider an instance of the pricing game in which all users have the same source and destination. If the aggre- gate value-demand curve for the system satisfies the MHR condition and the network contains k monopolies, the POA of the game is at most ek_._
PROOF. As in the definition above, let F (v) denote the to- tal fraction of traffic with per-unit-demand value at most v. Consider an arbitrary Nash equilibrium for the game. If the network is saturated under this equilibrium it already oper- ates optimally. Otherwise, we note that all non-monopolies in the network charge a price of 0. (We omit an argument for the sake of brevity.) Now consider the monopoly charging the maximum price at this equilibrium; say that the price is p∗. Let P + p∗^ be the total price charged by all the monop- olies (this is the price paid by all the users that are routed). Then p∗^ ≥ (P + p∗)/k. If this monopoly changes its price to p, its revenue is given by p(1 − F (P + p)). Since the sys- tem is at equilibrium and so p∗^ is the price maximizing this revenue, upon differentiating the function we get:
1 − F (P + p∗) − p∗f (P + p∗) = 0
That is, h(P ′) = 1/p∗^ ≤ k/P ′^ where P ′^ = P + p∗. Now, by the MHR condition, h is a non-decreasing func- tion, therefore, h(t) ≤ k/P ′^ for all t ≤ P ′. Finally, we note that by definition, F (t) = 1 − exp(
∫ (^) t 0 h(x)dx). Therefore, F (P ′) = 1 − exp(
∫ P ′
0 h(x)dx)^ ≤^1 −^ exp(k). The total traffic admitted by this equilibrium is therefore at least an ek^ fraction of all traffic. Therefore, the total social value of this equilibrium is at least an ek^ fraction of the total value of all the users, and so also at least an ek^ fraction of the optimal social value. The result above focuses on single-source single-sink net- works containing monopolies. However it is also relevant to more general settings of multiple-source multiple-sink net- works without monopolies because, as described earlier, such instances can contain virtual monopolies. In a companion paper currently under submission we show that both the up- per and lower bound given above extend to multiple-source single-sink networks when all users have identical value-demand curves that satisfy the MHR condition.
Topology Nodes, Edges Rocketfuel-based 50, 100 Power law 46, 93 Random 50, 93 Regular 50, 100
Table 1: Details of topologies used in this study. For Ran- dom graphs, the probability of each edge is 0.08. In the regular graph, each node has a degree of 4.
These results show that the performance of the system de- grades as the value disparity between different users increases, as congestion increases (equivalently sparsity decreases), or as the number of hops in source-sink paths increase (lead- ing to a larger number of virtual monopolies). However, if all demand-value curves satisfy the MHR condition defined above, the system performs well at any equilibrium.
6. RouteBazaar EVALUATION
We conduct a variety of simulations to study the perfor- mance of RouteBazaar in realistic settings. We study sev- eral CSP interconnection topologies that may arise in practi- cal instantiations of RouteBazaar. We also experiment with a few different distributions of user demand-value vectors. Our primary goal is to understand the global performance of the system (and compare against the theoretical results out- lined above). Our key metric of interest is the social value derived by the system relative to the optimal social value, that we also refer to as “efficiency”, under the different settings. This metric measures the ability of users to obtain as much benefit as possible from the system while allowing the CSPs to derive reasonable revenue, and indicates whether the sys- tem operates to its full potential. Note that this metric is diffe- rent from POA because POA is a measure of efficiency of the worst Nash equilibrium; in general, when multiple equilibria exist, our system may converge to a good equilibrium. We also examine lower-level details of the system, e.g. the per- formance of various CSP and end-user algorithms designed for system robustness and stability, convergence behavior and re-convergence under churn, CSP revenues, link loads, link price distributions etc. A final goal is to compare the central- ized and distributed variants of our system. The centralized approach is able to ensure sound global properties and our goal is to understand how close a completely decentralized approach can come to achieving such properties.
6.1 Experimental Setup
Topologies. We conduct experiments using several diffe- rent CSP interconnection topologies. Our baseline topology is one derived from the ISP topologies discovered in [28]. We extracted a subset of 50 highly populated tier-1 PoPs in North America and the edges between them (100 edges in all). We generated three other synthetic topologies: Power-law random graphs, Erdos-Renyi random graphs and regular graphs. The details of these graphs are shown in Table 1. In all the graphs described above, every bi-directional edge is replaced by two individual links allowing traffic to flow
Algorithm Parameters Explore-Exploit (EE) α =. 95 , N = 10000 Hedge-Bandit (HB) ǫ =. 01 , δ =. 01 Table 2: Parameters for learning algorithms.
in opposite directions. Link capacities are drawn at random from one of two values—25 or 100 units. We force links flowing in opposite directions between a pair of nodes to be the same capacity. We also experimented with other link ca- pacity distributions and our high level observations remain qualitatively similar in those settings. Link costs. Each link is assigned an initial cost gener- ated randomly between 0. 1 units and 5 at a granularity of 0. 1 units. The monetary value of “units” is arbitrary and would be determined by real demands in practice. CSPs adjust their link costs according to the algorithms presented in §4. We ensure that link costs stay in the range [0. 1 , 5 .0]. Sources and sinks. We use a multi-source multi-sink set- ting throughout our evaluation. Sources of traffic, i.e., users in RouteBazaar, could be located at any node in the above topology. However, the sinks are located at the 16 most highly populated nodes, where we assume that node popu- lation is proportional to degree (when degrees are similar, we pick 16 nodes at random). User demands. To determine the amount of demand in the system, we use the gravity model: the net demand between a pair of nodes is proportional to the population of the cor- responding nodes. The total number of users in the system is proportional to the net demand and each user has a single unit of demand to one of the 16 destinations. User values. We study a simplistic setting where all users have a demand-value vector containing a single entry, with demand set to unity. Each user is assigned an associated value with the unit demand it imposes. The values are drawn from the same range as link costs, [0. 1 , 5 .0] units. We experiment with several value distributions. The first is a Zipfian distribution with an exponent of α = 1. This rep- resents a typical income model and satisfies the MHR condi- tion. The second set of values is drawn uniformly at random from the range and also satisfies the MHR condition. The third is a bimodal distribution where there is significant dis- parity in user values: they are drawn from the ranges [0.1,1] or [4.5 and 5], with 90% of values originating from the first interval. This does not satisfy the MHR condition. Parameters. The algorithms we proposed in §4 each use a set of parameters. We conducted a variety of simulations to understand how to select these parameters. Without going into the details and in the interest of brevity we briefly list values selected for key parameters in Table 2. These param- eters ensure that the algorithms offer the fast convergence to equilibrium and good overall system performance in all sce- narios we consider.
6.2 Centralized RouteBazaar
Our first set of simulations considers the centralized Route- Bazaar framework under different settings. We first show that the system converges and is efficient in practice, and then
0
1000
2000
3000
4000
20k 40k 60k 80k 0
0.4^ 0.
1
Value in units Efficiency
Iteration
Revenue^ Value Averaged revenue^ Averaged value
0
1000
2000
3000
4000
50k 100k 150k 200k 250k 0
0.4^ 0.
1
Value in units Efficiency
Iteration
Revenue^ Value Average Revenue^ Average Value
(a) EE Algorithm (b) HB Algorithm Figure 5: Convergence: Rocketfuel topology, with Zip- fian value distribution.
Topology Value Distribution Convergence Efficiency Rocketfuel Zipfian 52,000 0. Rocketfuel Uniform 53,000 0. Rocketfuel Bimodal 53,000 0. Random Zipfian 50,000 0. Random Uniform 50,000 0. Random Bimodal 50,000 0. Regular Zipfian 52,000 0. Regular Uniform 52,000 0. Regular Bimodal 53,000 0. Power law Zipfian 50,000 0. Power law Uniform 50,000 0. Power law Bimodal 50,000 0.
Table 3: Centralized framework, with CSPs using EE. compare the two CSP learning algorithms. Convergence. Figure 5 shows the evolution over time of social value and total revenue at the central arbiter in the cen- tralized RouteBazaar system for one of our experiments. We present these results for both CSP learning algorithms— EE (epsilon-decreasing explore-exploit) and HB (hedge-bandit). Note that both the social value and revenue curves flatten out after 50,000 iterations for EE (Fig 5(a)) and 200000 iterations for HB (Fig 5(b)). This indicates that the arbiter’s simulation of user and CSP interaction reaches a stable state over time. Using the termination condition described in §4.3 the ar- biter declares convergence and outputs link prices and user routes at around 52,000 and 230,000 iterations for the two al- gorithms, respectively. In the rest of this section we refer to the state of the system at these points of time as the equilib- rium (although it may not correspond to an actual Nash equi- librium), and say that the system has converged. We tried several other scenarios and observed convergence in all of them — the iteration at which convergence was observed is shown in column 3 of Table 3 for the EE algorithm. Note that the two CSP learning algorithms differ in their convergence speed. We revisit this issue later in this section. Efficiency. We now discuss a key measure of the overall performance of centralized RouteBazaar, the system effi- ciency, as defined earlier. The higher the efficiency, the closer the system operates to its capacity. Table 3 shows the efficiency of the system upon conver- gence for different topologies and user value distributions. We assume that the EE algorithm is used to emulate CSP learning. In general, we note that despite allowing users and CSPs to interact selfishly with each other, our system arrives at a reasonably efficient outcome in most of the situations we studied. Although not 100% efficient, the centralized
0
1000
2000
3000
4000
5000
20k 40k 60k 80k 0
0.1^ 0.
0.3^ 0.
0.5^ 0.
0.7^ 0.
0.9^1
Value in units Efficiency
Iteration
Revenue^ Value Revenue average^ Value average
Figure 7: Distributed Convergence: Rocketfuel topology, Zipfian user values and CSPs using the EE algorithm
0
1
Fraction of requests accepted 0 1 2 3 4 5 Value
0
1
0 10 20 30 40 50 60 70 80 90 100
CDF of fraction of links
Load on link as a % of capacity (a) Users Utilizing the System (b) CSP Link Utilizations Figure 8: Distributed RouteBazaar at equilibrium
understand if the system oscillates, we applied a variety of tests. We monitored the change in the net social value of the system and net CSP revenues over time in various settings. In particular, we applied the centralized termination condition (Section 4.3) to the distributed simulation state to examine if the latter even converges and if so how the convergence rate compares to the centralized approach. Our observations are summarized in column 3 of Table 5. The distributed frame- work achieves convergence in all cases. (Note that iterations to convergence mean different things in the context of the centralized and distributed approach, because the latter in- volves direct user-CSP interaction.) For completeness, in Figure 7, we show the evolution of the distributed framework over multiple iterations when CSPs use the EE learning algorithm and users employ ǫs = 1 in their flow update algorithms. We find that the social value of the system reaches a steady state in about 50,000 iterations. Net CSP revenue is also stable beyond this point.
6.4 RouteBazaar at Equilibrium
RouteBazaar is designed to attract participation from users and CSPs. We now examine the status of RouteBazaar at equilibrium to check if this design requirement is met sat- isfactorily. We consider the distributed approach and take a snapshot of the system after a certain large number of iter- ations. We use the Rocketfuel topology with Zipfian value distributions, the EE algorithm for CSPs and assume selfish user response (ǫs = 1 for user flow update). Our observations for the centralized approach are qualitatively similar. In Figure 8(a), we show the fraction of users that are allo- cated routes at each value for the distributed framework. We see that very few users with low values (< 1 unit) get to route using the system. In contrast, almost all users with high val- ues (> 3 units) route using the system. We note that some users with high values are denied service—this could happen because of where they are located and how many other high-
0
1
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
CDF of fraction of links
Price of link
0
1
0 10 20 30 40 50 60 70
CDF of fraction of links
Revenue of link (a) Link Price (b) CSP Revenue Figure 9: Distributed RouteBazaar : CSPs at equilibrium value users they are competing against. In general, the sys- tem shows the expected behavior, allowing users who value the routes the most to be able to use RouteBazaar. In Figure 8(b), we show the utilizations of links owned by different CSPs. A small fraction of the links (20%) have link utilizations below 10%. About 30% of the links have 50% or higher utilization. This suggests that most CSPs are able to attract enough traffic onto their links using RouteBazaar. In Figure 9 we show the link prices and revenues of CSPs. We find that in an overwhelming fraction of the cases, the equi- librium prices are 2 units or lower (Figure 9(a)). From (Fig- ure 9(b)) we see that revenues are fairly evenly distributed across the CSPs and there is no significant skew. Roughly 45% of the revenues are in the 10-40 unit range. The rea- sonable distribution of revenues and link utilizations indicate that service providers would be willing to take part on our RouteBazaar framework. Since users with moderate to high values are able to route in RouteBazaar, our system would be able to attract enough users as well.
6.5 Churn
In this section, we discuss the performance of RouteBazaar when users enter and leave. Our discussion in §4.5 argues that slow churn can be accommodated in both the centralized and the distributed frameworks. In this section, we evaluate the rare situation where the system faces unexpected churn. We focus on the distributed setting. To test the flexibility of handling “extreme” churn, we ran the rocketfuel topology with Zipfian user values with the EE CSP response behavior. After the system converges for an initial set of demands, we add new users with a total de- mand of 1% to 5% of the existing demand. The reconver- gence times for these scenarios are presented in Table 6. We also show the efficiency of the system after reconvergence and the “restart” efficiency which reflects what would have been achieved had the entire set of users been in the system from the start. We note that although the system converges close to the restart efficiency under extreme churn, it takes a long time to reconverge. A potential concern in this case is that at certain times links may become overloaded due to extra demand in the system, causing dissatisfaction to users as well as CSPs. On the other hand, if all link loads are always < 1 prior to reconvergence, then users with the willingness to pay still get service, and CSPs still get good revenue, and long re- convergence times are of less concern. To address this, each
Demand Increase Reconvergence Efficiency Restart Efficiency αb needed 1% 14,000 0.60 0.62. 5% 28,000 0.54 0.58.
Table 6: Reconvergence on distributed simulations on Rocketfuel topology and Zipfian user values. We assume CSPs use the EE algorithm, which we updated to accom- modate churn—in this approach, CSPs employ a random price at every iteration with a fixed small probability, sim- ilar to the HB algorithm.
k Convergence iteration Efficiency 3 43,000 0. 4 52,000 0. 6 219,000 0.
Table 7: Efficiency in k-regular graphs
CSP link can have a small fraction of its capacity αb set aside as backup. Each CSP sets or alters prices to operate below 1 − αb of its link capacity at equilibrium; if not, CSPs as- sume that no revenue is made on the link and change price to bring the load down. The spare αb fraction of capacity can thus be utilized to accommodate relatively heavy churn and ensure that most users are satisfied even during churn. In our simulations using Rocketfuel topologies, we found that setting αb = 8% (conservatively) is sufficient to ensure that a link is not overwhelmed beyond its full capacity with high probability (see Table 6).
6.6 Factors Affecting the System
In §5, we outlined several factors that may affect the Route- Bazaar framework, including disparity in user values, net- work topology, and the presence of real or virtual monop- olies. Our simulations were designed to evaluate Route- Bazaar to understand the impact of these factors in practice. So far we have presented results detailing the impact of the first two factors. As our results show, the practical impact of these factors seems minimal and RouteBazaar seems to of- fer reasonable performance under a broad range of situations. As we show earlier, RouteBazaar presents a low bar- rier to entry to CSPs. Therefore we don’t expect the sys- tem to contain monopolies. We conducted a brief analysis to understand the impact of virtual monopolies by varying the connectivity of the network, and thereby impacting the hop-lengths of source-destination paths. Theorems 1 and 2 suggest that as the hop-lengths of paths increase, leading to a potentially larger number of virtual monopolies for any user, the system performance relative to the optimal social value worsens. We verify this behavior through simulations. In this set of experiments we selected the baseline regular graph topology (with per node degree of 4) and changed the average degree of each node to both increase and decrease route diversity and path lengths (use per node degrees of 3 and 6 respectively). We employed the distributed Route- Bazaar framework in this analysis. Our observations are summarized in Table 7. We note that in networks where path diversity is severely restricted (correspondingly, there is a high incidence of virtual monopolies), the system-wide
0
1
Fraction of requests accepted 0 1 2 3 4 5 Value
3 regular 4 regular 6 regular
0
1
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
CDF of fraction of links
Price of link
3-regular, Zipf 4-regular, Zipf 6-regular, Zipf
(a) Users Utilizing the System (b) Link Prices Figure 10: User and CSP properties in regular graphs.
efficiency suffers significantly. Figure 10 shows the distribution of values of users who route over RouteBazaar, and the link prices selected by CSPs, in the different regular topologies. As expected, link prices increase slightly with decreased path-diversity (Fig- ure 10(b)), because virtual monopolies tend to charge higher prices. More tellingly, the set of users using the system is very different. In topologies with larger degree, greater frac- tions of users who value the routes more end up using the system. In such topologies there are both a larger number of, and shorter on average, paths available. For the degree- graph, significant fractions of even the high-value users are denied. In this case, the effect of higher link prices is aggra- vated by longer paths—longer paths mean that users’ money will only get them so far, leading to poor social outcome.
7. DISCUSSION
Payments between users and CSPs. In the centralized approach, the arbiter can also play the role of mediating money exchange between each user and the set of service providers it routes over. The arbiter can tally the net amount owed by a user to each service provider and issue a monthly bill. In the distributed setting, a separate accounting framework would be necessary. The accounting mechanism could be based on the current approaches ISPs employ when charging cus- tomers on the basis of usage [25]. Using such an approach, each CSP tracks the net amount owed by individual users (note that the users may not be directly connected to the CSP links) and directly issues bills to the users. We believe that two factors will make the accounting problem relatively sim- ple from the view-point of CSPs: (1) The users in our setting are large stub networks and small-to-medium ISPs. Thus, they are few in number and it should be possible for CSPs to track their usage without incurring too much overhead. (2) We expect the system to mostly operate at steady state with few arrivals and departures of users, and relatively slow changes to demand-value vectors (based on time of day, for example). As a result, the usage profiles (i.e. the set of users routing over each link and the amount of capacity consumed) and link prices of CSPs are likely to change slowly, if at all. Multi-level RouteBazaar. Depending on the equilibrium prices selected by CSPs and network topology, it is possible that several users are denied service in RouteBazaar (note that the net social value of the system could still be high as users with high willingness to pay are unlikely to be denied).