Sorry to hear you had a bad day. Allow me to indulge in some musing on this subject.
"From a service provider prospective, there really isn't an advantage to using a pooling point if you go out and build your network and lease space."
Would that statement hold equally true for a facilities-based service provider and a reseller? A good number of the newer GbE horrizontal players don't even have their own fiber, to begin with. They would almost depend on such a model [maintaining a presence in a pooling or peering point] just to maintain their operation.
From my perspective the "pooling point" model is not rigidly defined yet, nor is it cast stone, despite the symbolism that some would like to assign to it.
If I look at what the metro traffic aggregator Layer One has done, I'd classify their model as a type of pooling point. This is one where you must pay to bring in your fiber and pay for a port as you have suggested. It only makes sense, however, if you can amortize your up front costs of entry across multiple customers, or a high enough traffic level.
layerone.com
cookreport.com
"That is the classic argument from the carriers, and I happen to agree. If I connect into a pooling point, I am going to get charged for a port on their switch, in addition to my building access, pop space and equipment fees. Also, the market is so competitive that you can't charge the customer for the port fees that you incur, so you have to pay them out of pocket."
I wouldn't go into the trading business for a single or even a low number of customers' needs. I would consider it, however, if I were bringing in multiple strands to a pooling point that could switch me at will to any number of other pooling point members, and if I had sufficient traffic to make it worth my while. The up front cost component (loss lead dynamic) is almost inevitable here, and it only makes sense if you can be assured that you will reach critical mass to break even and then go profitable. If you don't reach critical mass, like you say, you pay for access and the logistics that go along with it out of your own pocket.
In the end, I think that where the larger WAN reach is concerned (unlike the Layer One model for the metro) the real problem centers on the lack of an elegant means of effecting a trade. I.e., the technology and the administrative orchestration (not to mention the BTO contract divide, as you have noted) isn't there yet. Some of the work being done at OIF/IETF/ODSI is geared to correcting the technical shortcomings, in some cases through the use of a UNI and a control plane with accounting and management.
I suspect that on the administrative side of these initiatives they will support SLA tracking and BTO type contracts, as well. But the standards work being done today is not something that will prevent a lot of bad hair days over the next two years for folks who have a need for trading b-w.
"I don't think the demand for BOD is enough to spark interest in trading."
I don't think that the demand for BOD, with the current levels of security, accountability and reliability, along with the other impediments that go along with manual processes, is enough to support interest in trading today. But if these shortcomings were lifted I think (I damn well know) that a lot of enterprises would throttle their capacity and tool for new applications in order to shore up their bottom lines, in a flash. The model to support this does not exist yet.
Oddly enough, we've had BOD capabilities for a long time through the use of ISDN at lower speeds. You can order up a 128 or 384 or T1 Primary Rate Interface (even multiple T1s/Primary Rate Interfaces through bonding), but that's where it stops for all intents and purposes. And it isn't exactly cheap. We have had reasons to research multiple T3 pipes on demand for disaster recovery applications, and in each case it was like calling out the Army Corps of Engineers to get a study done and then a pricing model created. This is really ironic, because here the technology "does" exist through customer controlled reconfiguration techniques, using digital cross-connects. These were all the rage about ten years ago for T1 speeds, but the carriers have pulled back on their availability lately, especially where higher speed lines are concerned.
In each case that I've explored during the past three years, the carrier has stated that they did not have a "productized" version of this service, and that it was a non-standard configuration. Right.
In the end, we've found it less of a burden, and in some cases even cheaper [because of the ridiculous break even points once we were given the pricing breakdown] to go with the real thing on a full period basis, instead.
"1) No carrier or customer has BOD currently, aside from a few usage based internet service providers. Usage based billing is a billing gimmick rather than a technology.
I take it you're referring to the 95 percentile techniques that are used at some peering points?
"2) I could only see a very few applications for BOD"
Again, it's a catch 22 situation. Because it is not available it has not caught on. I could think of numerous storage and archiving applications that could benefit from time of day, end of month or as required provisioning. Instead, FedEx benefits from the overnight tape delivery.
"3) I don't see any of the incumbant carriers with large networks clammoring for ways to provide more efficient bandwidth allocation to corporate users or other carriers. There seems to be more money in selling oversized pipes."
No argument on the surface, although the larger carriers have been swapping and trading bandwidth for eons through mostly manual and digital cross connect means. Only, they don't publicize it and they don't make the details known. What the larger carriers very pointedly don't want is one of their primary assets, bandwidth, becoming commodified. And on this point they usually are not bashful about making this point known in public. In contrast, some of the newer age carriers' models were built in such a way as to eventually depend on it. And so goes the conflict.
I await your erudite comments and corrections. |
