A client evaluating cloud computing solutions asked me about Cogent’s Utility Computing offering (and showed me a nice little product sheet for it). Never having heard of it before, and not having a clue from the marketing collateral what this was actually supposed to be (and finding zero public information about it), I got in touch with Cogent and asked them to brief me. I plan to include a blurb about it in my upcoming Who’s Who note, but it’s sufficiently unusual and interesting that I think it’s worth a call-out on my blog.

Simply put, Cogent is allowing customers to rent dedicated Linux servers at Cogent’s POPs. The servers are managed through the OS level; customers have sudo access. This by itself wouldn’t be hugely interesting (and many CDNs now allow their customers to colocate at their POPs, and might offer self-managed or simple managed dedicated hosting as well in those POPs). What’s interesting is the pricing model.

Cogent charges for this service based on bandwidth (on a Mbps basis). You pay normal Cogent prices for the bandwidth, plus an additional per-Mbps surcharge of about $1. In other words, you don’t pay any kind of compute price at all. (You do have to push a certain minimum amount of bandwidth in order for Cogent to sell you the service at all, though.)

This means that if you want to construct your own fly-by-night CDN (or even just a high-volume origin for static content), this is one way to do it. Figure you could easily be looking at $5/Mbps pricing and below, all-in. If you’re looking for cheap and crude and high-volume, then these servers in a couple of POPs, and a global load-balancing service of some sort will do it. For anything that’s not performance-sensitive, like large file downloads in the background (like game content updates), this might turn out to be a pretty interesting alternative.

I’ve always thought that Level 3’s CDN service, with its “it costs what our bandwidth costs” pricing tactic, was a competitive assault not so much on Limelight (or even AT&T, who has certainly gotten into mudpit pricing fights with Level 3), but on Cogent and other providers of low-cost high-volume bandwidth — i.e., convincing people that rather than buying servers and getting colocation space and cheap high-volume bandwidth, that they should just take CDN services. So it makes sense for Cogent to strike back with a product that circumvents having to make the investments in technology that would be required to get into the CDN mudpit directly.

I’ll be interested to see how this evolves — and will be curious to see if anyone else launches a similar service.

Carriers are very interested in CDNs, whether it’s getting into the CDN market themselves, or “defensively” deploying content delivery solutions as part of an effort to reduce the cost of broadband service or find a way to monetize the gobs of video traffic now flowing to their end-users.

So far, most carriers have chosen partnerships with companies like Limelight and Edgecast, rather than entering the market with their own technology and services, but this shouldn’t be regarded as the permanent state of things. The equipment vendors clearly recognized the interest some time ago, and the solutions are finally starting to flow down the pipeline.

Last year, Alcatel-Lucent bought Velocix, a CDN provider, in order to get its carrier-focused technology, Velocix Metro (which I’ve written about before). Velocix Metro is a turnkey CDN solution, with the added interesting bit of adding aggregation capability across multiple Velocix customers.

Last month, Juniper partnered with Ankeena in order to bring a solution called Juniper MediaFlow to market. It’s a turnkey CDN solution incorporating both content routing and caches.

This month, with the introduction of the CRS-3 core router, Cisco announced its Network Positioning System (NPS). NPS is not a CDN solution of any sort. Rather, it’s essentially a system that gathers intelligence about the network, and uses that to compute the proximity between two endpoints. NPS is essentially used to provide a programmatic way to advise clients and servers about the best place to find networked resources. Today, we get a crude form of this in the technical functionality of BGP Anycast; NPS, by contrast, is supposed to use information from layers 3 through 7, and incorporate policy-based capabilities.

And in news of little companies, Blackwave has been chugging along, releasing a new version of its platform earlier this month. Blackwave is one of those companies that I expect to be eyed as an acquisition target by equipment vendors looking to add turnkey CDN solutions to their portfolios; Blackwave has a highly efficient ILM-ish media storage platform, coupled with some content routing capabilities. (Its flagship CDN customer is CDNetworks, but its other customers are primarily service providers.)

There have been a number of interesting new developments in the content routing space recently — specifically, the issue of how to get content to end-users from the most optimal point on the network. I’ll be talking about Cisco and Juniper in a forthcoming blog post, but for now, let’s start with Google:

A couple of weeks ago, Google and UltraDNS (part of Neustar) proposed an extension to the DNS protocol that would allow DNS servers to obtain the IP address of the end-user who originally made the request. DNS is normally recursive — the end-user queries his local DNS resolver server, which then makes queries up the chain on his behalf. The problem with this is that the resolver is not necessarily actually local — it might be far, far away from the user. And the DNS servers of things like CDNs use the location of the DNS query to figure out where the user is, which means that they actually return an optimal server for the resolver’s location, not the user’s.

I wrote about this problem in some detail about a year and a half ago, in a blog post: The nameserver as CDN vantage point. You can go back and look at that for a more cohesive explanation and a look at some numbers that illustrate how much of a problem resolver locations create. The Google proposal is certainly a boon to CDNs as well as anyone else that relies upon DNS for global load-balancing solutions. In the ecosystem where it’s supported, the enhancement will also give a slight performance boost to CDNs with more local footprint, by helping to ensure that the local cache is actually more local to the user. The resolver issue can, as I’ve noted before, erase the advantages of having more footprint closer to the edge, since that edge footprint won’t be used unless there are local resolvers that map to it. Provide the user’s IP, though, and you can figure out exactly what the best server for him is.

There’s no shortage of technical issues to debate (starting with the age-old objection to using DNS for content routing to begin with), and privacy issues have been raised as well, but my expectation is that even if it doesn’t actually get adopted as a standard (and I’m guessing it won’t, by the way), enough large entities will implement it to make it a boon for many users.