Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Why bandwidth trading markets haven’t matured? Analysis of technological and market issues P. Ferreira1,2,3 J. Mindel3 L. McKnight1,4 [email protected] [email protected] [email protected] 1 – ITC: MIT’s Program on Internet and Telecoms Convergence, MIT, Cambridge, US 2 – IN+ Center for Innovation, Technology and Policy Research, IST, Lisbon, Portugal 3 –Engineering and Public Policy Department, Carnegie Mellon University, Pittsburgh, PA, US 4 –School of Information Studies, Syracuse University, Syracuse, NY, US 1 Why bandwidth trading markets haven’t matured? Analysis of technological and market issues P. Ferreira1,2,3 J. Mindel3 L. McKnight1,4 [email protected] [email protected] [email protected] Abstract This paper provides an in-depth analysis of technological and market issues that will impact the development of bandwidth trading markets with liquidity. We provide a very broad definition for a bandwidth trading agreement and we analyze several network topologies in which trading bandwidth would make sense both from a business perspective and a technical perspective. The paper suggests that there is a gap between what the current routing protocols allow carriers to do and what carriers would like to do in order to implement more complex business relationships to trade bandwidth. We provide several examples of such situations. Additionally, we point out two major problems that may hamper the implementation of dynamic and fluid spot markets for bandwidth trading. The first problem is related to the excessive time that disseminating the new routing information generated by an agreement may take. The second problem is associated with the difficulties in performing traffic engineering to balance load across links once carriers become multi-connected, which we believe will be the case for most of them with mature bandwidth trading markets in place The analysis provided in this paper contributes to understanding the directions in which routing would need to be enhanced in order to establish more attractive bandwidth trading markets. The analysis of market issues addresses the promise of these markets from the perspectives of demand and feasibility. From a public policy perspective, bandwidth trading markets are important because they have the potential to impact the sustainability of competition in the telecommunications sector. Existence and sustainability of market competitors in the service sector is a fundamental tenet of telecommunications policy because competitive markets offer consumers services with better quality that are priced closer to their true costs. This paper shows that there is price volatility in today’s bandwidth markets, however not enough to convince market participants to adhere in bulk and thus to build the critical mass needed for the markets to take off. There is a significant amount of education that needs to take place for suppliers and wholesale consumers to become adept at the use of, for example, future contracts for risk management purposes in such markets. 2 1 Introduction From the outset, bandwidth trading has been a polarizing topic of debate. During the late 1990’s, proponents of bandwidth trading markets “offered” to revolutionize the bi-lateral market mechanisms used in the telecommunications sector. Today, however, the presence of bandwidth trading is far more subdued because of distress in the telecommunications sector, the collapse of Enron, the supply/demand imbalance in many long-haul markets, and a number of other obstacles. In spite of these issues, there is research value in analyzing the opportunities and obstacles associated with bandwidth trading. If there’s perceived merit, then bandwidth trading may reemerge at some point. If there are fundamental flaws, then perhaps we can write-off bandwidth trading as a fad or mistake. The market drivers for bandwidth trading included an influx of new suppliers following the passage of the Telecommunications Act of 1996, rapidly growing demand for capacity, buyer demand for more control over connectivity, the evolution of interconnection business models, and Enron’s declaration that bandwidth could profitably be traded as a commodity. The key promises were claimed to be: 1) Faster, cheaper, and more flexible provisioning of bandwidth services; 2) Better risk management opportunities; and 3) Price discovery. In this paper, we examine specific technical issues and general market issues associated with bandwidth trading markets. In Section 2, we examine a specific set of technical issues associated with the trading of terrestrial, point-to-point, long-haul transport bandwidth services for IP traffic. Section 3 begins with an analysis of the declining price trend observed in long-haul bandwidth markets, and concludes with an open-ended discussion of issues that need to be resolved and/or better understood before we can expect bandwidth trading to become a significant market mechanism in the telecommunications sector. 3 2 Technological Caveats This section presents a very broad definition of bandwidth trading and discusses several scenarios in which it can take place building up a topological taxonomy for bandwidth trading. In light of those scenarios, this section analyses various caveats of the current interconnection technology which hamper the development of bandwidth trading markets. 2.1 Definition We argue that bandwidth trading reflects the idea that one Autonomous System (AS) relies on bandwidth from another AS to deliver traffic. In this situation, the latter AS is providing a service to the former AS, for which it charges a certain price. Assume that traffic T, originated at node S in ASx, is destined to node D and transverses path P through the network. We say that we are in the presence of bandwidth trading when there is at least one link belonging to P that does not belong to ASx. This situation is illustrated in Figure 1, in which ASx uses bandwidth from ASy between IXP1 and IXP2. In this case, ASy charges ASx a certain price based on the specification of the bandwidth traded, represented by BT in the figure. Path P ASx S IXP1 IXP2 D $ ASy BT Figure 1- General depiction of a bandwidth trading agreement. Figure 1 illustrates the most general example of bandwidth trading. IXP1 and IXP2 are, respectively, the ingress node and the egress node of BT. Note that IXP1 and IXP2 are interconnection points at which several ASes might meet. Therefore, in addition to 4 specifying the ingress and the egress nodes, one must also indicate the AS from which the traffic comes from at IXP1 and the AS to which the traffic should be delivered at IXP2. We will call these ASes, respectively, the coming from AS and the deliver to AS. Specifying these ASes is necessary to enforce the correct routing relationships at IXP1 and IXP2, particularly that no traffic other than T is routed between ASx and ASy under this agreement. Finally, to fully specify the bandwidth trading agreement, one needs to add the specification of traffic T, which includes, for example, the Quality of Service (QoS) that ASx requires. Hence, from a technical viewpoint, a bandwidth trading agreement is specified by a vector of the form (IN, CF, EN, DT, T). IN and EN are the ingress and the egress nodes of the bandwidth traded and T is the specification of the traffic to be carried. CF is the AS that presents T at node IN and DT is the AS that will receive that traffic at node EN. The five parameters of a bandwidth trading agreement are summarized in Table 1. Bandwidth trading agreement between ASx and ASy ASz ASx Coming from Ingress node From Traffic Node S T Bandwidth Pipe Delivering To Egress node To Node D ASy Item Description/Comments Ingress Node The IXP beyond which ASy assumes the responsibility for transporting the traffic Coming from The AS delivering the traffic at the ingress node, ASx in this case Egress Node The IXP to which ASx requests ASy to transport the traffic Deliver To The AS to which ASx requests ASy to deliver the traffic at the egress node Traffic The specification of the traffic that ASx requests ASy to transport Table 1- Elements of the technical specification for a general bandwidth trading agreement. An example in which this definition of a bandwidth trading agreement is clear is the case of Band-X at www.band-x.com, shown in Figure 2. This figure depicts a session in a trading floor at Band-X used to exchange wavelengths. A wavelength is an end-to-end 5 light path that supports a certain QoS and that can be assigned to a user to deliver traffic between two points in the network (Ramaswami, 1998). This page lists the offers that ASs Type of bandwidth traded announce in a common trading floor ingress node egress node type of traffic Price charged that can be for the service transported Figure 2- Snapshot of a Band-X session in a trading floor for wavelength exchange. One offer is listed in this case. The ingress node and the egress node of the bandwidth pipe are Frankfurt (GER) and Stockholm (SWE). The bandwidth traded can transport traffic between these two nodes at 2.5 Gbps. This is a measure of the QoS offered. The price to be charged is $768860 USD for the first year. An AS accepting this offer will be the coming from AS for the bandwidth trading agreement and will specify the deliver to AS, which is the AS that will receive the traffic at Stockholm. 2.2 Topological Taxonomy We now look at particular cases of the general definition of bandwidth trading given before. For that, we focus on the location of IXP2. The first situation, illustrated in Figure 3, is when IXP2 is node D. In this case, ASx requests ASy to carry traffic T beyond IXP1 and up to the destination node. We call this situation “to-destination” bandwidth trading. 6 ASx ASy (“coming from”) S D Egress IXP1 node Ingress node Figure 3- Illustration of “to-destination” bandwidth trading. Using the notation developed in the previous subsection, a bandwidth trading agreement of this sort is defined by (IXP1, ASx, D, __, T), where IXP1 is an interconnection point between ASx and ASy. The deliver to AS is not specified because at the egress node there is no AS to whom the traffic must be delivered. In addition, in this scenario, there is a business relationship between ASx and ASy, under which ASy charges a price to ASx to carry traffic T between IXP1 and node D. ASx wants to participate in a bandwidth trading agreement of this sort if, for example, it does not own bandwidth to reach node D, which is the case every time this D is interior to some other AS. The second situation is when IXP2 is an interconnection point to ASx. In this case, ASx request ASy to carry the traffic from IXP1 up to IXP2. Beyond IXP2, ASx will again carry the traffic in its network. We call this situation “to-self” bandwidth trading because the traffic leaves ASx and returns to ASx at another interconnection point. This case is shown in Figure 4. ASx (“coming from” “deliver to”) S D Ingress node ASy IXP1 IXP2 Egress node Figure 4- Illustration of “to-self” bandwidth trading. 7 A “to-self” bandwidth trading agreement is specified by (IXP1, ASx, IXP2, ASx, T), where IXP1 and IXP2 are two different interconnection points between ASx and ASy. “to-self” bandwidth trading is characterized by the fact that the coming from and the deliver to ASs are the same AS. In this case, there is a business relationship between ASx and ASy to carry traffic between IXP1 and IXP2. The bandwidth provided by ASy is an alternative to the path within ASx through which the traffic was, in principle, previously delivered. ASx might need this new path for two reasons. First, the path within ASx is no longer enough to assign to traffic T the requested QoS. Second, this path can be suitable to transport traffic T, but ASx prefers to allocate it to other traffic that yields more profit, even after discounting the payment that ASx has to make to ASy for transporting traffic T between IXP1 and IXP2. The third situation is when ASx requests ASy to transport traffic between IXP1 and IXP2 and to deliver the traffic at IXP2 to another AS, say ASz, in which case ASx establishes a second agreement with ASz to carry the traffic between IXP2 and node D. We call this case, “remote” bandwidth trading because the ingress node for the second bandwidth trading agreement is remote relative to ASx’s network. Figure 5 illustrates this situation. Before, the traffic flew from ASx to ASz through some other path, which could be entirely within ASx or could go through some other ASes. With the bandwidth trading agreement, the traffic travels from ASx to ASz through ASy. The agreement between ASx and ASy is of the form (IXP1, ASx, IXP2, ASz, T) and the remote agreement is of the form (IXP2, ASy, D, __, T). In the case discussed, the second agreement is a “to-destination” agreement but it could be any of the other types of agreements described before. Regardless of the type of the remote agreement, the interesting point about this situation is that ASx requests ASy to carry the traffic up to a node in the network beyond which ASx is again responsible for making the traffic reach the destination. However, ASx does not own infrastructure connecting from that node to 8 node D and, for that reason, relies on bandwidth from a third AS to make sure that the traffic reaches the destination. ASy ASx (“coming from 1”) S (“deliver to 1” “coming from 2”) ASz D IXP2 IXP1 Egress node 2 Egress node 1 Ingress node 2 Ingress node 1 Figure 5- Illustration of “remote” bandwidth trading. In this case, there are two business agreements. There is one agreement between ASx and ASy to carry the traffic between IXP1 and IXP2 and a second agreement between ASx and ASz to carry the traffic beyond IXP2 to node D. The topological taxonomy suggested here for bandwidth trading is summarized in Table 2. The variables used to derive this taxonomy are the egress node and the deliver to AS, as they alone allow for identifying the type of agreement made. In the case of remote bandwidth trading, there is a second agreement that can take any of the forms of agreements seen before. ASx is responsible for delivering traffic T from node S to node D and relies on a bandwidth trading agreement with ASy ASz ASx Coming from Ingress node From Traffic Node S T Bandwidth Pipe Delivering To Egress node To Node D ASy Egress node ≠ D Taxonomy Egress node = D Deliver to = ASx Deliver to ≠ ASx Name “to-destination” “to-self” “remote” Specification (IXP1, ASx, D, __, T) (IXP1, ASx, IXP2, ASx, T) (IXP1, ASx, IXP2, ASz, T) Business Between ASx and ASy Between ASx and ASy Between ASx and ASy relationships Between ASx and ASz Table 2- Taxonomy of topologies for bandwidth trading. 9 Also, note that in the scope of a bandwidth trading agreement, an AS assumes responsibility for carrying the traffic between the ingress and the egress node. In order to provide that transport service, that AS can rely on other bandwidth trading agreements. For example, under a “to-destination” bandwidth trading agreement, ASy becomes responsible for delivering the traffic between the interconnection point between ASx and ASy and the destination node. To accomplish that, ASy may rely, for example, in a “toself” bandwidth trading agreement, to make the traffic leave its network and arrive at some other node within its domain from which ASy may easily transport the traffic to node D. Figure 6 depicts this scenario. ASy ASx (“coming from2”) (“deliver to 2”) (“coming from1”) S Ingress node2 ASz IXP2 IXP1 Ingress node1 TO-DESTINATION IXP3 D Egress node1 Egress node2 TO-SELF Figure 6- Illustration of nested bandwidth trading agreements. We call this set of situations “nested” bandwidth trading, as some agreements come nested in the others to complete the transport services agreed. 2.3 Caveats of Current Technology This section analyzes how the bandwidth trading scenarios identified in the previous section may be implemented over the routing protocols currently used in the Internet. The aim of this analysis is to point out potential problems that may arise when carriers try to establish a dynamic and fluid market over the functionality that the Internet supports today. 10 The protocols currently used in the Internet to route traffic include the TCP/IP (Postel, 1981), used to route messages end-to-end, and the Border Gateway Protocol (BGP) (Traina, 1995), used to exchange routing information between ASs. More recently, Label Switching (LS) (Rekhter, 1997) approaches have been suggested to speed up packet forwarding and to enhance the routing functionality provided by the IP layer. We start with an analysis of “to-destination” bandwidth trading. In this case, ASx requests ASy to carry the traffic up to the destination D. This is exactly what routing does today in the Internet (Rekhter, 1995). The forwarding tables that routers have allow exactly to forward packets towards the final destination. The destination for a packet is inferred from the packet header, inspecting the IP address of the destination node, or from the label carried in the packet, when LS is used (Barnerjee, 2001). A router sends a packet through an outgoing link to a certain next-hop passing the responsibility to carry and deliver the traffic to that node. This is exactly the functionality needed to implement “to-destination” bandwidth trading. Arguably, there is nothing new about “to-destination” bandwidth trading. It simply resembles an old practice used in the Internet ever since. However, note that bandwidth trading agreements generate an amount of new routing information that must be exchanged among ASs across the network. This routing information is exchanged between ASs over External BGP (EBGP) sessions and within each AS through Internal BGP (IBGP) sessions (Stewart, 1999), as shown in Figure 7. Disseminating the new routing information using BGP may take more time that what could be considered satisfactory to implement a dynamic spot market for bandwidth trading, in which bandwidth would be re-allocated among ASs right away and for shorter periods of time, relative to the current practice with leased lines. 11 ASx EBGP sessions IBGP sessions EBGP session IXP1 ASy D Advertisement for route to D Dissemination Beyond IXP1 Figure 7- Illustration of EBGP and IBGP to disseminate routing information. Moreover, in a fluid bandwidth trading environment with multiple paths to the same prefix, races among route advertisements may occur and for some time routers may keep inconsistent routing information in their forwarding tables. According to experimental studies done by Labovitz (Labovitz, 2000) the network might take between a couple of minutes to tens of minutes to converge after the introduction of new or faulty routing information. This sort of delays to use new routes can certainly hamper the implementation of very dynamic bandwidth trading markets. Several BGP extensions have been proposed to deal with some aspects of this problem. For example, BGP route flap dampening mechanisms (Villamizar, 1998) can be employed to avoid using routes while they flap. However, route flap dampening does not speed up the network convergence. It just prevents using improper routes while the network is unstable. ASs usually set up a full mesh of IBGP session between their routers (Bates, 2000), so that every router can rapidly learn the routes that every other router within the AS is able to use. This is a way to speed up the dissemination of routing information within the same AS. However, this solution does not scale well and several approaches have been considered to cope with this problem, as for example, route reflection and AS confederations (Traina, 2001). However, these solutions reduce the routing information that each router keeps. This helps the network to scale, but slows the convergence of the network. 12 Now, consider the cases of “to-self” and “remote” bandwidth trading agreements, which are the ones that go against the conventional ways in which routing is accomplished. The big difference presented by these two types of agreements is that ASx wants to define the deliver to AS, whereas in conventional routing, an AS forwards traffic to a next-hop and it is this node that has the responsibility for transporting the traffic from then on. Specifying the deliver to AS entails that ASx needs to have knowledge about the network beyond the egress node of the bandwidth trading agreement. This might introduce scalability problems, since routers become overloaded with topological information that, in principle, they would not need to keep. However, these scenarios make sense from a business perspective. Take the example of “remote” bandwidth trading and assume that for some reason, ASz does not accept to forward traffic from ASy. In this case, if ASx requests ASy to carry the traffic beyond IXP1, ASy will not be able to rely on ASz to accomplish the transport service. In an extreme case where there is no way around ASz to reach the destination of the traffic, this might not even be delivered. “remote” bandwidth trading appears as a natural option to overcome this situation. ASx establishes an agreement with ASz to carry the traffic beyond IXP2, and the fact that the traffic reaches IXP2 through ASy is irrelevant for ASz. Note that this is not transparent to ASz, because ASz needs to be instructed by ASx that it should pick up the traffic at IXP2 from ASy. We say it is relevant because ASy and ASz do participate in any kind of bandwidth trading agreement. Note that this case of agreement brings to ASx a new route to the final destination, besides the one it already had to deliver the traffic. In fact, in a mature bandwidth trading market, it is plausible to think that ASs will have multiple connections to the same destination. ASs usually seek to have several paths to reach the same destination for sake of reliability (Stewart, 1998). Also, note that this situation may also appear in “to-self” and “to-destination” bandwidth trading. We refer to the case of “remote” bandwidth trading for sake of being concrete. 13 For example, consider a National ISP in the US that broadcasts a sports event to Europe. This ISP sends live image of the event and statistics about the performance of the players. Assume that this ISP does not have infrastructure to directly connect to the ISP in Europe responsible for showing the sports event on-line on the Web. It then relies on a “todestination” bandwidth trading agreement with a transatlantic carrier to make the traffic arrive in Europe. However, the ISP might want to rely on one transatlantic carrier to send the image and on another transatlantic carrier to send the statistics. In this case, if one of the carriers fails, there is still the chance that the other does not and some information about the sports event reaches Europe. The previous situation is an example of a scenario in which an AS wants to split traffic among links. A similar situation, from a technical viewpoint, occurs when an ASs needs to split traffic among several links, which may happen frequently when the bandwidth trading market allows for “partial” transport of traffic. In this case, when, for example, ASx issues a request to ASy to carry traffic T to IXPa, ASy might answer that it is not able to provide that service but it is able to transport traffic T’ to IXPa. ASx may accept this offer, if, for example, it can establish a bandwidth trading agreement with another AS to carry traffic T’’=T-T’ to IXPa. ASx could not want to split the traffic between the two trading agreements but it might have to do so, if this proves to be the most attractive solution. In order to fully benefit of being multi-connected, ASs need to have some mechanism to allow for splitting load among links and for signaling the receiver that the traffic has been broken into several parts and will arrive through different paths. If the same delay is attained on each link, for example, by requesting the same QoS on each bandwidth trading agreement associated to each link, it is likely that stream re-ordering at the receiver is unnecessary. However, some procedure to re-group traffic from several incoming links is always needed. BGP introduces several mechanisms that allow for revealing preference for some routes over other routes. An example is the LOCAL-PREF (LP) attribute (Stewart, 1999). If an 14 AS advertises a prefix with a higher value in this attribute over one route relative to other advertisements for that prefix in other routes it signals that it prefers to use the first route to carry traffic for that prefix. This attribute can be used, for example, in the situation described above as shown in Figure 8. The image of the event is introduced at one node and the statistics are introduced at another node. They are both destined to prefix p in Europe. IXP1 advertises its route to that prefix with a LP of 10 to the node transmitting the image and with a LP of 100 to the node transmitting the statistics. IXP2 advertises its route to Europe reversing the values of the LP attribute. It advertises the route to the node transmitting the image with a LP of 100 and to the node transmitting the statistics with a LP of 10. Every node within the network of the ISP in the US knows about the two routes to Europe, but the image will preferably be transmitted using IXP2 and the statistics will be preferably transmitted using IXP1. p advertised with LP=10 Destination prefix p p advertised with LP=100 IXP1 Bandwidth traded for stats Image Bandwidth traded for image IXP2 Stats National ISP Transatlantic Carriers European ISP Figure 8- Illustration of the use of the LOCAL-PREF (LP) attribute in BGP. Note that the LP attribute can be used in the way described above yielding the desired effect because the traffic was already split into two streams originated at different nodes. In the case where the traffic comes from the same router, the BGP attributes used to balance load among links would not be sufficient to achieve the goal. Load splitting could only be obtained if that router had two routes for the same prefix with different 15 NEXT-HOPs and a mechanism to choose one or the other according to the shares of the load it is willing to send to each link. This is usually achieved today in the Internet by employing traffic engineering mechanisms (Srisuresh, 1998) that configure the parameters that allows to achieve load balance. Still, it becomes complex to manage all these parameters consistently and running ASs in such environments is a task that requires much experience and practical wisdom. Finally, consider the case of “to-self” bandwidth trading, in which the traffic leaves an AS and returns to that AS at some other interconnection point. Note that this is not the common practice in the Internet today. When an AS receives traffic destined to one of its nodes, it seeks a route within its domain to deliver the traffic. Making the traffic to flow through other ASs is something different that can be accounted for in one of two ways. A first approach is to build into the topological view that the AS has of its own network, the path through the other AS. This path would be like a tunnel connecting the two nodes, with a cost associated that reflects the payment that has to be made according to the bandwidth trading agreement. In this case, the AS would use this path transparently, evoking its routing procedures as before. LS can be used in this case to implement that tunnel. When the traffic arrives at the ingress node of the bandwidth trading agreement, it becomes label switched and follows a label switched path, within the other AS, that terminates at the egress node of the agreement. A label in the traffic is used only in the bandwidth traded. Conventional routing is used elsewhere. The second approach is to enhance the routing algorithm allowing for notifying that the path is actually a path outside the AS. This is helpful, when, for instance, the cost associated with that path cannot be masked as a cost within the AS’s domain and therefore the first approach may not be implemented. 16 Overall, the technical problems identified in this section are represented in Figure 9, which also matches these problems to the type of agreements studied in this paper. This figure represents the space of bandwidth trading agreements and makes clear that the big change that bandwidth trading brings is that it opens up the sub-space at the right of the picture, which is motivated by business arrangements among AS that require enhanced routing functionality in order to be implemented. The left part of this picture can be implemented using the well-known routing practices currently employed in the Internet. Figure 9- The partition of the space of bandwidth trading schemes into two sets and the main technical problems that may arise to implement these schemes. The picture also illustrates that the problems of time-scales and load splitting, described before in this section, cross the entire space of agreements. A time-scale problem occurs every time new routing information is generated, which is the case in every type of agreement. A load splitting problem occurs every time an AS gets, through a bandwidth trading agreement, a new route to some destination, which is also always the case regardless of the type of agreement. 17 3 Market Issues Resolution of the technical issues discussed in Section 2 would provide valuable operational flexibility to buyers of bandwidth service contracts. However, these technical issues are only part of the story. Price declines are widely viewed as another key issue precluding the emergence of mature bandwidth trading markets, but again, there are other important issues that also need to be resolved and/or better understood in this regard. Section 3.1 examines the data indicating a declining price trend. Section 3.2 examines the relevance of price trends for bandwidth trading, and then highlights a range of market issues associated with bandwidth trading opportunities and obstacles. 3.1 Declining Price Trends The traditional market for bandwidth, at the backbone level, encompasses the major Internet Backbone Providers (IBPs). Board Watch compiles information about the major IBPs in the North American market. According to this website, a nation-wide IBP must have POPs in at least five different states, four national public peering agreements at access points and a marketing focus on selling wholesale, high bandwidth dedicated connections to ISPs (Boardwatch, 2001). According to this source, the US market currently encompasses about 70 IBPs. These IBPs connect to other continents, mainly to Asia and Europe, through submarine cables. In this section, we will look at the price of bandwidth over these cables between the US and Europe. 3.1.1 Data Used and Model The data used to characterize the price of inter-continental bandwidth comes from Telegeography.com at www.telegeography.com. Telegeography has just very recently released price quotes for bandwidth between NYC and London from January 1999 to 18 January 2002. These data are available for registered users at their website during a free trial demo version of the database that they have compiled. From this database, we have downloaded 255 price quotes for leasing contracts for T-1, E-1, DS-3 and STM-1 links. Figure 10 provides a snapshot of Telegeography’s database. Each quote provides information on the month, the type of bandwidth provided, the lease install price and the monthly price per Mbps. We are interested in explaining how the monthly price per Mbps of bandwidth depends on the time and on the bandwidth provided. The variable time is measured in number of days, 1 being the first day of 1999. Cities : London-New York Bandwidth: Contract Type: Date Range: Additional Display Options: T-1, E-1, DS-3, STM-1 / OC-3 Lease Jan 1999 - Jan 2002 None City Search : Results To sort: click arrows 255 Records Found Location 1 Location 2 City One City Two Bandwidth Lease Price ($USD) London London New York New York Posted Date Contract Type Type Mbps Lease Install Price Monthly Price per Mbps Jan 1999 Lease E-1 2 4,000 Jan 1999 Lease DS-3 45 1,874 1,780 London London New York New York Feb 1999 Feb 1999 Lease Lease E-1 E-1 2 2 3,780 3,675 5,000 Figure 10- Adapted from snapshot of database at Telegeography.com. To start with our analysis, we plot the monthly price per Mbps for links of 45 Mbps (DS3) and 155 Mbps (STM-1). This is shown in Figure 11. For both types of fiber we can observe that the price has been decreasing tremendously in the last couple of years. Moreover, we observe that an exponential decline in the monthly price of bandwidth might explain well this dynamics, with the exponent being a linear function of time. From the exponential fits show in this figure, we can also understand that the constant premultiplying the exponential trend depends clearly on the capacity of the link. 19 Analysis over Time 45 Mbps Analysis over Time (155 Mbps) 3000 y = 1494,8e-0,0031x R2 = 0,8961 900 800 700 2000 Price/Mbps Price/Mbps 1.000 y = 2485,3e-0,0029x R2 = 0,8389 2500 1500 1000 600 500 400 300 200 500 100 0 0 0 200 400 600 800 1000 1200 1400 0 200 Time 400 600 800 1000 1200 1400 Time Figure 11- Trends in the price of bandwidth for DS-3 and STM-1 links between NYC and London (actual data and exponential fit). 3.1.2 Results Obtained We can aim at fitting to the data shown in the previous subsection, a curve of the form f(M)*exp(α*T), where M represents the bandwidth of the link and T represents time. We present results for two specifications of f, linear on the left and exponential on the right in Function f β1*M+ β2 β1*M ^β2 Overall Fit F[2,190]=302.44 F[2,190]=380.99 Adjusted R2 0.76221 0.80145 Parameter β1 β2 Α β1 β2 Α Coefficient -24.802788 4444.549026 -0.001989 5875.076503 -.3208379108 -.001971877264 Standard Error 2.0173475 2.0224176 0.00013579938 2.8221895 .032828324 .00012031105 T-statistic -12.295 21.976 -14.643 20.817 -9.773 -16.390 P-value 0.000 0.000 0.000 0.000 0.000 0.000 Table 3- Results of regressions aimed at explaining the price per Mbps per month as a function of the bandwidth provided and time. The results presented in the previous table indicate that we might want to choose the second specification, since its overall fit is better. Additionally, we know that the 20 following laws should hold: 1) more bandwidth is more expensive: ∂Price/∂Mbps>0; 2) there are bulk discounts in the bandwidth markets: ∂2Price/∂Mbps2<0; and finally 3) the price of bandwidth has been decreasing over time: ∂Price/∂Time<0. These inequalities hold for all values of M and T for the second specification. The same does not happen for the first one. Specification 2 entails bulk discounts of 39% per Mbps from an E-3 line to an OC-3 line, that is, the price per Mbps decreases 39% when one leases a 155 Mbps relative to one gets a 45 Mbps link. Additionally, this specification entails an average price decline per month of 5,7%, that is, the price per Mbps of bandwidth between NYC and London has been declining roughly 50% per year, during the last couple of years. 3.2 Commodity Market Opportunities and Obstacles Above and beyond the technical caveats and readily apparent market obstacles to bandwidth trading (the latter of which have been largely reported in the trade press), there persists a lingering doubt amongst buyers of bandwidth services that bandwidth trading is even useful. Why don’t buyers perceive a demand for the promises of bandwidth trading? Is it a lack of appreciation for the benefits? Were the promises partly misguided? The intent of this section is to present an open-ended discussion of issues pertinent to the perceived demand for bandwidth trading’s promises. We begin with the declining price trend discussed in Section 3.1 of this paper. It is a misconception that price trends reduce the attractiveness of commodity markets. Price trends, whether declines or inclines, do not preclude the volatility that partly motivates buyers and sellers to participate in trading a commodity. Volatility is a measure of how uncertain we are about future price movements. The data shown in Figure 11 shows that despite the downward trend in the price of bandwidth, volatility clearly exists today, even when imbalances between supply and demand persist in most long-haul markets. Additionally, prices can even increase for short periods of time, as depicted in Table 7 for several routes between June and September 2002. 21 Route Amsterdam – New York Frankfurt – New York Oslo - New York Antwerp – Rome London – New York Rise in price from June to September 2002 28.72% 10.83% 8.36% 8.30% 7.86% Table 4 - Sample Rate Rises for STM-1 Contracts (Source: Tarifica, Sept. 2002) The promise of improved opportunities for risk management has been a hard sell to buyers and sellers in the telecommunications sector. Part of the problem is educational and part of the problem is that there is not sufficient tension between demand and supply in most long-haul markets to generate the price volatility that would motivate such management concerns. Futures contracts are an example of the financial instrument that buyers and sellers could use to hedge exposures to price, demand, and supply risks. To be useful, futures markets must have sufficient liquidity to enable principals to enter and exit the market as needed for hedging. Hedging and speculating are roles that market participants play in a commodity market. Hedgers seek to reduce uncertainty, whereas speculators (who contribute to market liquidity) seek profits by taking additional risks. Even if spot markets for bandwidth trading emerged, the consolidation of long-haul suppliers, and/or the reemergence of dominant providers that controlled both long-haul and broadband access markets would be a serious deterrent to the emergence of futures markets. The market power of these providers might enable them to manipulate market prices, which would diminish the usefulness of futures contracts as hedging instruments. The issue of faster, cheaper, and more flexible contract durations is another promise of bandwidth trading. What’s the source of the demand for faster and more flexible contract durations? What types of firms, or firm activities, warrant the purchase of large amounts of bandwidth on short-notice for short term usage? If significant price volatility emerges, then firms might be more likely to seek the operational flexibility made possible by such contract terms. Current practice today is to purchase the maximum required bandwidth 22 needed for a period in which the maximum may only be required for relatively short durations. Let us assume that there is a clear and documented demand for faster, cheaper, and more flexible contract durations. Is bandwidth trading the best interconnection business model to provide these benefits? Cheaper can be interpreted as lower transaction costs, which in turn can be subdivided into (at least) three categories. One category includes the cost of finding a counterparty, the cost of negotiating contract terms, and the cost of performing counterparty credit checks. These costs are minimized in commodity markets. Bandwidth trading markets would have transparent, market-clearing prices. Mature commodity markets would also have a clearinghouse (or other credit mechanism) that served as the counterparty to all trades, which reduces the counterparty risk faced by any single buyer or seller. Another, perhaps most significant element of transaction costs are that of establishing an access circuit between the buyer’s network and the interconnection facility. It is not clear that bandwidth trading holds any advantage over other, prevalent interconnection business models. Bandwidth trading exchanges may be centralized or distributed. Similarly, peering/transit exchanges, carrier points-of-presence (POPs), and GigaPOPs may also be centralized or distributed. Bandwidth trading may ultimately serve a niche market because the supplier-anonymity associated with standardized, commodity contracts for bandwidth services may not serve all buyers. The identity of the contracted supplier may not be revealed until service delivery is imminent. Consider, for example, a buyer that demands physical path redundancy in his bandwidth services to ensure reliability. Is this buyer better served by working with a single supplier that can guarantee this path redundancy, or by working with multiple suppliers to achieve it? For the former, bandwidth trading contracts are not appropriate, whereas for the latter they may well be so. 23 Along the lines of redundancy and reliability, there is an argument to be made that bandwidth exchanges are a single point of failure. By concentrating all bandwidth purchases in a given city through a single bandwidth exchange, a buyer is exposed to physical catastrophe or bankruptcy of the exchange itself. A bandwidth exchange with distributed interconnection facilities in a given city reduces the risk of physical catastrophe. Assuming the trading market has sufficient liquidity to satisfy both buyers and sellers, the credit risk exposure of the exchange itself is likely the most significant risk that buyers face with the bandwidth exchange. Can the exchange withstand default of a large supplier? The introduction of ‘price discovery’ into bandwidth service markets is one additional promise that bandwidth trading proponents made. According to mainstream financial economics and microeconomics, ‘price discovery’ is a positive benefit of efficient commodity markets. This is considered important because it reveals the commodity’s true economic value. While behavioral economists would certainly agree that prices in these markets reflect a convergence of the market's collective group opinion, they would argue against the fact that this opinion necessarily reflects true economic value. The dynamics of group decision-making are not always completely rational. Dot-com valuations in the late 1990's are an example of market opinion that did not reflect true economic value. 4 Conclusions This paper suggests that bandwidth trading reflects the idea that one AS relies on bandwidth from another AS to deliver traffic. It also introduces a general specification for the technical elements of a bandwidth trading agreement. These are the ingress and the egress node of the bandwidth traded, the coming from AS and the deliver to AS, which are the AS that originates the traffic at the ingress node and the AS to whom the traffic should be delivered at the egress node, respectively, and the specification of the traffic. Additionally, we analyze several network topologies in which bandwidth trading can be used and we explain the business motivation behind them. The bandwidth trading 24 scenarios considered are “to-destination”, “to-self” and “remote” bandwidth trading. In the case of “to-destination” bandwidth trading an AS requests another AS to deliver the traffic to the final destination. In the case of “to-self” bandwidth trading an AS requests another AS to carry the traffic between two interconnection points between those ASs, making the traffic return again to the same AS. With “remote” bandwidth trading an AS requests another AS to transport the traffic up to a node beyond which a third AS is responsible for delivering the traffic to the final destination. The paper suggests that there is a gap between what the current routing protocols allow carriers to do and what they would like to do in order to implement more complex business relationships to trade bandwidth. Particularly, TCP/IP and BGP provide a framework in which routers forward traffic toward the final destination and pass the responsibility for delivering the traffic to the next-hop. However, in order to implement “to-self” and “remote” bandwidth trading, routers would need to specify to whom the traffic must be delivered at routers along the way. We emphasize the fact that this would require routers to know much more about the network than what they usually do, which may bring scalability problems to the network. Additionally, routers would need to affect the routing policy of routers in other ASes, which is not a common practice in the Internet, although there are some mechanisms, like MPLS tunnels, to achieve that. Additionally, we point out two problems that may hamper the implementation of dynamic and fluid spot markets for bandwidth trading. The first problem is related to the excessive time that disseminating the new routing information generated by an agreement may take. Bandwidth trading markets in a time-scale of hours may be safely implemented, but making bandwidth available within minutes might be a problem with BPG. The second problem is related to being multi-connected, which we believe will be the case for most ASs with mature bandwidth trading markets in place. ASs can only benefit 25 from being multi-connected if they can share load among links, which cannot be easily obtained with the current plain BGP mechanisms. Instead, traffic engineering has to be carefully employed to manage all the parameters that may cause traffic to be balanced across connections. In sum, we analyze potential arrangements for carriers to exchange bandwidth, which allows us to build a common language to talk about bandwidth trading. Additionally, we identify problems that may arise when carriers try to implement some of these arrangements over the routing protocols currently used in the Internet. This is a first step in order to understand in which directions routing needs to be enhanced in order to establish attractive bandwidth trading markets. This paper also raised a number of market issues impacting the emergence of bandwidth trading markets with liquidity. First, the fact that volatility exists in pricing today can be used to convince one that greater volatility will exist if and when there is greater tension between supply and demand in markets. This volatility may be a necessary, but not sufficient condition to convince market participants to rely on futures contracts for hedging price (and supply and demand) risk exposures. There is also a significant amount of education that needs to take place for suppliers and wholesale consumers to become adept at the use of these futures contracts for risk management. Spot markets for bandwidth trading assume a demand for large amounts of bandwidth on short notice, and also assume that the bandwidth trading business model is the most appropriate interconnection business model to satisfy this demand. Extensive reliance on any interconnection business model – whether bandwidth trading or public peering point – introduces reliability concerns that do not exist in a more distributed approach (whether ad-hoc or not) to network interconnections. Finally, the issue of price discovery in markets with liquidity has been somewhat tarnished when one considers the unrealistic market valuations placed on traded commodities in recent years. This paper presents an analysis of issues that are critical to 26 the development of bandwidth trading markets with liquidity. Though the state of technology and markets will continue to evolve, the approach taken in this paper is timeless, and can be reapplied in several years to reevaluate the factors affecting the development of bandwidth trading. References A. Barnerjee, J. D., J. Lang, B. Turner, K. Kompella, Y. Rekhter (2001). “Generalized Multiprotocol Label Switching: An Overview of Routing and Management Enhancements.” IEEE - Internet Technology Series January. Bates, T. (2000). BGP Route reflection - an alternative to Full Mesh IBGP. E. C. R. Chandra, Network Working Group, RFC. 2796. Labovitz, C. (2000), Delayed Internet Routing Convergence. SIGCOMM, Sweden. Postel, J. (1981). Transmission Control Protocol: Protocol Specification, Darpa Internet Program, RFC. 793. Ramaswami, R. (1998). Optical Networks, A practical perspective, Morgan Kaufmann Publishers. Rekhter, Y. (1995). Application of the Border Gateway Protocol in the Internet. P. Gross, Network Working Group, RFC 1772. Rekhter, Y. (1997). Cisco Systems' Tag Switching Architecture Overview. D. K. B. Davie, E. Rosen, G. Swallow, Network Working Group, RFC. 2105. Srisuresh, P. (1998). Load Sharing using IP Network Address Translation. D. Gan, Network Working Group, RFC. 2391. 27 Stewart, J. (1998). Using a Dedicated AS for Sites Homed to a Single Provider. R. C. T. Bates, E. Chen, Network Working Group, RFC. 2270. Stewart, J. W. (1999). Inter-domain Routing in the Internet, Addison-Wesley. Traina, P. (1995). BGP4 Protocol Analysis, Network Working Group, RFC. 1774. Traina, P. (1995). Experience with the BGP4 Protocol, Network Working Group, RFC 1773. Traina, P. (2001). Autonomous Systems Confederations for BGP, Network Working Group, RFC. 3065. Villamizar, C. (1998). BGP Route Flap Damping. R. G. R. Chandra, Network Working Group, RFC. 2439. 28