Download Why bandwidth trading markets haven`t matured? Analysis of

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