Software defined networks could create an auction-based bandwith bazaar


What if delivering bandwidth worked like an auction, where business bid for the right to transfer their traffic depending on how crowded the network is? That’s the idea behind an article written by IBM’s (s ibm) Tinniam V Ganesh over at telcomaisia. Ganesh, an infrastructure architect at IBM India, says such a process is possible using software defined networks that can intelligently route traffic and can be programmed to follow auction-based rules.

Because of that he envisions a way to price bandwidth based on network congestion and availability asking, “Why cannot we have an intelligent network in place in which price of different data transfer rates vary depending on the time of the day, the type of traffic and the quality of service required?” He believes that software defined networks, and specifically the Open Flow protocol, could make it possible for different devices to bid for bandwidth based on urgency, speed and quality of services required.

What he’s suggesting isn’t all that far-fetched. As far back as 2008, I sat on a panel with Vijay Gill, a network architect at Google (s goog) at the time, who suggested a similar auction-based pricing for bandwidth. Back then there wasn’t a mechanism to make such pricing work, but thanks to efforts to virtualize the network (essentially separating intelligence that routes network traffic from the devices that actually push the packets,) creating programmable networks that could follow such a model becomes possible. The mechanism for this would be dynamically updated “flows” allocated for each request for bandwidth. From Ganesh’s article:

In order to dynamically allocate smaller or fatter pipes for different flows, it necessary for the logic in the Flow Controller to be updated dynamically based on the bid price.For example, we could assume that a corporate has three different flows, namely immediate, ASAP, price below $x. Based on the upper ceiling for the bid price, the OpenFlow controller will allocate a flow for the immediate traffic of the corporation. For the ASAP flow, the corporate would have requested that the flow be arranged when the bid price falls between a range $a – $b. The OpenFlow Controller will ensure that it can arrange for such a flow. The lowest priority traffic will be send during non-peak hours.

Would we want the web to work that way?

First off, we have to understand that not all networks are created equal. There are many pieces and pipes that comprise the web, some public and some private. The private pipes between data centers, such as Amazon’s efforts to connect its AWS data centers directly to Equinix’s International Business Exchange data centers, and Google’s efforts to create its own network are private. On these networks it may make sense to offer some kind of auction to help offset congestion. That means bandwidth charges would fluctuate based on traffic. The downside is startups building out infrastructure might have to deal with higher prices during times of peak demand but it’s possible they could keep costs low if they could schedule some backup jobs or tasks during off hours.

However, the public Internet, which is what consumers and businesses connect to, is a bit different. At the last mile, operators build their networks to try to accommodate peak demand, but by building such a system they could flatten demand at the peak and make the dispersion of traffic more equal.  The danger for consumers and web companies is that the owners of the public networks might not have reason to expand their pipes as the demand for traffic increases–they would just allow their customers to bid up higher prices for more bandwidth. There’s also the fact that consumers (and businesses) dislike variable pricing, and there’s certainly no guarantee that savings on bandwidth would be passed along to consumers in the form of their broadband or wireless data bills.

Nevertheless, software defined networks are going to gain in importance for services providers and for big bandwidth users. I’ve written how service providers can use SDNs to lower their costs, and I know that many webscale companies are rolling out their own tests of the Open Flow protocol or of SDNs in general to understand what they can do with virtualized networks. I expect new services that lower costs to roll out later this year and next, but I’m not sure I’m ready to see an auction-based Internet among them.


Ray Seals

Didn’t Enron try this as well? Create a market place for Bandwidth. I know their motives where driven by other needs but I’m wondering if there are any lessons to learn from what they tried?

Thomas Sachson

No doubt this will come — and probably alot sooner than most think.

To some extent, we are already doing dynamic bandwidth pricing with our firm’s FreeBand technology. We make tools for carriers to sell bandwidth directly to content creators who package the bytes (10mb for 24 hours, 50mb for a week, etc) directly into the apps they create and then give to their customers to use for free. And depending on the time of day and amounts consumed the carriers charge differently (allowing low cost byte selling when the networks are empty, or more expensive when during peak hours). See more at

Dave Burstein

I know some stock traders are paying heavily for priority, literally inducing the Hibernia new trans-Atlantic cable. But is there much else that can’t do just fine with the regular service in the core that’s $1-3/megabit now? Bandwidth costs are so low – and dropping – that they rarely are a determining factor at the carrier and core levels. Unless you’re a Netflix or a Hulu, the savings from timing most of your traffic haven’t been large enough to be interesting. If you are that large, you de facto are negotiating every deal and can negotiate pricing based on peak and off peak loads if you want to.

Where do you see enough large customers to make this work in a wholesale market? (Local wireless is more complicated, but that’s a different product.)

Comments are closed.