TSF,
First, I'd like to thank you for the very substantive messages that you've posted here with regard to bandwidth pooling and trading. You obviously have your foot deep into this tool bag, if you don't mind the metaphor. So, it is with a sense of deference that I ask you to bear with me here for a moment as I take a little excursion into the unknown, and ask you to comment on the following, even if it veers considerably off course. We don't very often get the opportunity around here to do Q and A with someone who actually knows what they're talking about, when it comes to this subject.
============
One of the rough spots that I see concerning promoting the concept, once you get away from the spot rate markets for straight minutes of use (mou's) in the international voice sector, is one of context and feasibility of deployment. Allow me to be intentionally simplistic here, avoiding the financial instruments of the trade, while I muse a bit on some concepts that have been with me for a while.
One could make a distinction between bandwidth on demand and longer term contracts. Where, on the one hand, with bandwidth on demand it is assumed that the bandwidth would be available for use immediately upon execution of a sale or trade (or nearly that fast), and the bandwidth would be available only for as long as it was actually needed. Alternatively, supply could be throttled dynamically, in an adaptive manner, through some parametric means embedded in software. Either way, it's bandwidth that is delivered rather swiftly on a demand basis.
And on the other hand, a bandwidth contract might stipulate a given pipe size or collection of pipes to wherever, which could be installed over a "normal" two-to-three month installation interval, and whose term might be measured in years, or conceivably, indefeasibly forever. This last one, the term contract, doesn't entertain and inspire as much as the first one, bandwidth on demand.
The upper tier trading principals will have less of a problem with contextualing these instruments than the downstream service providers and very large enterprises will, who, imo, will very likely be the first SPs and end user consumers of the commodity to benefit from these arrangements (please correct me if I'm mistaken on this last point).
But if you ever want to see someone in a Fortune 100 IT department who has not been introduced to these concepts before give you a funny look, all you have to do is propose to them that they lay down a "tap" into a pooling point or a carrier hotel and set up an account for bandwidth on demand.
Yeah, great idea... being able to do a couple of key strokes and voila, you've just increased your Internet access capacity by last year's bandwidth doubling factor. But will it be - or is it, in fact, already - that simple?
By "context" I mean how the bandwidth that is traded and eventually deployed immediately fits into a real, usable framework: how it connects at the port level to the enterprise's automation environment, not only in the case of 'Net access, but in business applications sense, as well, where source-sink and overall network dimensioning relationships exist, and call for iterative tuning, as well.
If prearranged pipes that are sitting in the wait state for the purpose of connecting to a known carrier's cloud, most likely with an in-place set of SLA terms on a moment's notice, then these issues become less murky. But does this scenario really describe how one would regard a true commodity if it has to be from a known, dedicated source? I don't think that it does, nor am I saying that this is how it will ge, or is already being done. I'm merely presenting what I know to be a known model in the dedicated carrier instance, and attempting to adjust to a similar solution in the traded bandwidth sense.
The scenario above really doesn't describe a commodity being traded, not if the defining characteristic of a commodity is true fungibility**, which would imply that I should be able to receive said bandwidth and connectivity from just about anyone in the pool at the lowest market price, irrespective of any pre-existing hooks and standby connecting arrangements of a previous provider's setup to my infrastructure. Do you see what I'm getting at here in attempting to nail down a sense of "context?" In even simpler terms, how does it work?
** Slightly modified from Merriam-Webster;) - fungibility: being of such a nature that one part or quantity may be replaced by another equal part or quantity in the satisfaction of an obligation <oil, wheat, lumber and bandwidth<?> are fungible commodities>
Would you care to address some of these points? If I wasn't clear enough - which I'm almost certain is the case - then please advise. TIA.
FAC |
