It seems less like “news” and more like an eventuality, but Skype is putting forward an HD version of its software. In addition to two-way video teleconferencing at 720p on computers, Skype is teaming up with LG and Panasonic to produce TVs with Skype built in – including webcams and connection – no computer required.

I had a feeling this was coming back in October 09, when Lifesize announced its “Passport” product that would allow you to hook up Skype to a 720p TV. I would not be surprised if much of the technology that went into the passport ended up in the new LG and Panasonic TVs.

Obviously, higher resolution Skype means higher bandwidth needs for Skype on your network. Well – eventually. See, most Webcams aren’t high-definition, and so you’ve got a little bit of time before HD webcams hit the market. They’re not cheap either – HD requires larger sensors to produce an image with the same amount of light as SD, so early HD webcams are going to be around $100 USD or more; compared to $15-20 for a cheap webcam.

What we have here is a similar kind of network disruption technology that occurred when YouTube went high def; only this time, instead of sucking down only bandwidth, Skype’s conversations are also latency based. So, if you’re not using Skype for business, you’re going to want to keep it out of the latency sensitive class of service; and if you are using Skype for business, you’re going to want to make sure it has the bandwidth it needs in the higher level QoS without it drowning out your other latency sensitive apps.

We’ll try to get more details on Skype’s codec and bandwidth requirements soon.

Cisco released a slew of collaboration products this week. First, of course, there’s Cisco’s WebEx Mail, a replacement for MS Exchange that integrates with Outlook. There’s the Enterprise Collaboration Platform, essentially a social-networking/company portal kind of thingy that competes with MS Sharepoint. And Enterprise Collaboration Platform is an alternative to IBM’s Lotus Connections.

There are some improvements on competitor’s offerings as well; for example, Cisco includes a service called “pulse” which analyzes social network data as it occurs, and tries to “learn the social graph” associated with corporate networks. And another service, called Show and Share, is sort of like an “internal YouTube” for companies. You can host videos internally and show them to anyone inside the company – but they’re not accessible from the outside – or hosted out on the public Internet. This is also integrated with recording solutions from telepresence to the “widdle iddy biddy” Flip Digital cameras.

It’s a crowded market – not only is Microsoft the established champion, but the scrappy Google has entered in the market as well, with Google Apps for Your Domain. The two approaches to unseat the Microsoft Exchange behemoth are very different, as Google’s solutions require moving things out to the cloud.

For various reasons, companies are often hesitant to trust Google – or any company – with sensitive information like business plans, payroll statistics, personal communications, and the incriminating video of last year’s Christmas Party that you really know you should delete but it’s just too good. There’s also the fact that publically traded companies have to have on-site backups of communications for governmental regulatory reasons anyway, so why not just host the whole thing onsite and eliminate the risk, if it’ll cost about the same anyway?

Cisco’s solutions also integrate with unified communications tools like voice, video, and instant messaging, meaning that the 10 minute phonecall at 10:00 a.m. can be on the network by 10:15 a.m. (Finally, communication tools that travel faster than gossip!)

What impact will these tools have on the network? It’s hard to say, really, depending on each particular enterprise. If companies just switch out one collaboration tool for another, it’s unlikely that there will be much of an increase in traffic. But in other scenarios, it’s difficult to suggest whether overall traffic levels will go up or down. For example, instead of e-mailing large video or audio files back and forth, a unified communications portal allows for a much more simplified “multicast” solution which would take up less bandwidth overall. Then again, the ease of multimedia communication might invite more people to create multimedia communications – thus increasing the amount of bandwidth taken.

One force or the other could dominate, or the two could cancel each other out. In either case, it continues to make a compelling case for maintaining monitoring solutions so that you can catch changes in traffic as they occur, and predict future needs.

In this video (part one of two), Jim Metzler looks back at some prediction he made at the beginning of the year, and how they're shaping up to reality in this retrospective interview with Jordan Weiss.

Distributed computation has been around a while in different forms – Beowulf clusters, for example, - but Ian Clarke, the developer of Freenet and founder of Revver, has started working on a programming language, based on Scala, called “Swarm,” which he hopes will create a distributed programming language that can run on almost any operating system.

Because it runs on an application level, any computer can be a part of Swarm. You run Swarm on any computer you like, and you can access the computation of other computers running Swarm on the network; or, theoretically, on the public Internet. And Swarm allows a programmer to code an application for multiple CPUs and multiple computers with the same code that you could code for one CPU on one computer.

Now, there are projects such as SETI@Home or Folding@Home which do similar grid-computing tasks, but both are based on a model of breaking up the data to bite-sized chunks, moving that data to individual machines, where the information is processed, and then resending the output back to the central server.

Swarm is trying to flip that on its head. With Swarm, you can run the program wherever the data resides. So if you had a piece of data on Computer A, and a piece of data on Computer B, and you wanted to do a calculation that required both A and B’s data, you wouldn’t need to copy the data over the network – the program would execute on both A and B, returning the result of the calculations on B’s data to Computer A. Swarm is designed to manage which software runs with which data on which computer – without the programmer having to think about it beforehand.

Combine this with the latest advances in dynamic allocation of virtual servers according to need, and you start to really chip away at a whole bunch of scalability problems that have traditionally plagued massively-multi-user-applications… that is, Web apps.

Now, here’s the question: CPU latency is measured in picoseconds. Network latency is measured in milliseconds. The question is: How do you figure out what computations will actually benefit from being offloaded to another computer? – i.e., which computations are so far back in the stack that it would be better for them to go for a round trip across the Ether than to just wait patiently for the stack to clear? It seems to me that network latency monitoring would be very important for such an application.

For example, let’s use some of the NetQoS Network Estimation Tools (shameless plug) to determine how fast we can theoretically get a calculation going over the network. So, figuring a router latency of 0.5 milliseconds on both ends, a server latency of 2ms, a link speed of 64000, and a (very short) link distance of 10 miles – you’re looking at 132 ms of latency altogether – assuming point-to-point protocol.

In that 132ms, a 2.4 GHz quad-core computer can perform 1.26 billion calculations locally. That seems like a lot – and it is. But you actually start saving time once you hit 1.26 billion plus one calculations. For some applications, that might be worth it.

But other than pure speed, there’s another reason to consider running Swarm – and that is that applications coded with Swarm should have the ability to continue running on other servers – preserving the application in the case of fault or insufficient resources on the primary computer.

Right now, Swarm is more theory than fact, and there’s a lot of work to be done before it can be practical. But anything that requires less data to be sent over the network is something to keep an eye one when trying to preserve network performance.

Google’s E-mail was down yesterday for 100 minutes – annoying many, and hurting the productivity of a number of companies that rely on Gmail.

You could chalk this up to the danger of relying on cloud apps… but, Google is supposed to be the cream of the Cloud providers. What happened? Well, according to the Google Blog:

Here's what happened: This morning (Pacific Time) we took a small fraction of Gmail's servers offline to perform routine upgrades. This isn't in itself a problem — we do this all the time, and Gmail's web interface runs in many locations and just sends traffic to other locations when one is offline.

However, as we now know, we had slightly underestimated the load which some recent changes (ironically, some designed to improve service availability) placed on the request routers — servers which direct web queries to the appropriate Gmail server for response. At about 12:30 pm Pacific a few of the request routers became overloaded and in effect told the rest of the system "stop sending us traffic, we're too slow!". This transferred the load onto the remaining request routers, causing a few more of them to also become overloaded, and within minutes nearly all of the request routers were overloaded. As a result, people couldn't access Gmail via the web interface because their requests couldn't be routed to a Gmail server. IMAP/POP access and mail processing continued to work normally because these requests don't use the same routers.

The Gmail engineering team was alerted to the failures within seconds (we take monitoring very seriously). After establishing that the core problem was insufficient available capacity, the team brought a LOT of additional request routers online (flexible capacity is one of the advantages of Google's architecture), distributed the traffic across the request routers, and the Gmail web interface came back online.

On one hand, Google didn’t understand their network well enough to know the effects that the change would have. On the other hand, Google did some things right – their monitoring software alerted them to the problems before the users started calling Google, they were quickly able to diagnose the problem, and that lead to a simple and direct solution to get up and running relatively quickly. 100 minutes may seem like a long time, but from the problem to the repair, it’s actually relatively short.

One of the top stories on Network World’s front page today is Colt Mercer’s post on iCloud and G.ho.st – two cloud-based “Web OSes.”

If you’re not familiar with the concept, a WebOS is essentially a computer in a Web browser; a complete operating system virtualized inside your Web browser, allowing you to access specific cloud-based applications.

Don’t get me wrong – running a computer inside a Web browser inside a computer is an amazing technical feat, and one which is pretty cool. But that’s all that it is. The problem is applications.

That is, in order to access the applications – word processing, spreadsheets, photo cataloguing, etc. – you have to A) Use your computer’s OS to B) use your Web browser to C) Use the Web OS to D) use the application you really wanted in the first place. Compared to most cloud applications which take three steps, (Computer OS to Browser to Web app), or desktop applications which take two, this seems to be a woefully inefficient way of doing things.

The advantage of a unified operating system on the Web, of course, is interoperability – being able to copy spreadsheet data and put it in a word processing document, etc. However, Google seems to be able to do this without the Web OS intermediary. Gmail integrates with Google Docs, which integrates with Google Spreadsheets, etc.

So right now, any so called “Web OS” is less useful than no Web OS at all. It’s just another thing getting in the way to the application you really want.

There is still potential in this model, however. The problem is that these Web OSes are very limited in what types of applications will run on them. The main selling point of OSes on the desktop is that, say, Windows will let you run any Windows software that exists. Mac OSX will allow to run any OSX app. Linux will let you run any Unix app.

Why would you use a service that allows you to run, maybe, 15 applications, when you can use a service on your desktop that allows you to use millions?

Cloud computing has already accomplished an amazing feat. About 80% of our computing can be done on the Cloud – and about 80% of computer users can use cloud apps exclusively day-to-day. The 80/20 rule, if you will, strikes again. The trick for cloud computing apps now is reaching that “long tail” on the 20% - creating the app for the minority of users, rather than the majority.

I can see Web OSes solving this problem one of two ways. The hard way would be for all these little startups to standardize on a single platform for app development, and create millions of Web apps, to rival commercial desktop apps. At the same time, they will be competing with Google and Microsoft, who plan on developing Web apps – or have already developed Web apps – without those standards. Again – this is the hard way.

The easy way would be for a Web OS as “middleware” to make already developed desktop applications work on the cloud. A Web OS that came with some basic features, but which allowed me to run, say, anything that is featured in Debian’s APT packaging system, by recompiling it for the cloud, and running as a cloud app. Sure, some apps would be too “chatty” to be worthwhile on an Internet connection, but those apps can be recompiled in later versions to be less chatty and more responsive over longer-latency links. (Until then, monitoring how many round trips each app takes is a good policy.)

Or – and this may blow your mind – what if we could run Windows apps on the cloud? Microsoft may be working on this in their labs somewhere, but if they’re not, there’s always Linux+WINE or ReactOS.

There are advantages to such a setup – running Web apps is less bandwidth intensive than more traditional remote desktop virtualization (where you run the entire output of the screen and everything down the network tubes) and there’s certainly an advantage in providing app support only through a Web interface, and take no liability on the client’s end for the desktop OS.

There were outages related to denial of service attacks on three of the biggest social networking Web sites – Twitter, Facebook, and Livejournal - yesterday. 

What could be the purpose of such a thing?  Actually, it was a concentrated effort to silence a particular individual, a Georgian (the country) blogger who goes by the name of “Cyxymu,” an economics professor known for his criticisms of Russian conduct during the war in South Ossetia. 

Cyxymu himself blamed the attack on the Russian government according to an interview he gave to British newspaper The Guardian. 

He added: "An attack on such a scale that affected three worldwide services with numerous servers could only be organised by someone with huge resources."

If it seems implausible, Max Kelly, Facebook’s chief security officer confirmed that the major DoS was targeted primarily at Cyxymu.

Max Kelly, Facebook's chief security officer, confirmed yesterday that the attack that disrupted the Twitter site and caused problems for Facebook and LiveJournal was aimed at Cyxymu. "It was a simultaneous attack across a number of properties targeting him to keep his voice from being heard," he said.

Talk about a backfire, however.  Now everyone’s talking about Cyxymu, and people who haven’t heard of him before are talking about his blog.  He’s become the next Salam Pax. 

I’m not sure what this teaches us about network performance.  Except maybe that we have always lived in a world where butterflies’ wings have brought hurricanes; it’s just that, with everything around the world connected, there are more butterflies and more hurricanes.  That’s the funny thing about globalization and the disappearance of regionalism due to the Internet; as regional problems become worldwide ones.

And not to end this on a sour note, but… let’s say it’s true.  Let’s say that Russia decided to take down much of the most important bits of the Internet in order to silence one man.  Maybe it’s time we started realizing that an assault on freedom to communicate anywhere is an assault on freedom to communicate everywhere. 

Though with the human race being the way it is, I doubt it. 

The Dow Jones Newswires report that Google will acquire On2 Technologies, a company that makes video compression, for $106.5M worth of stock, presumably for the video site YouTube.

It’s an awfully big investment - (a hefty 6.7x multiple of On2’s trailing twelve months (TTM) revenue, one of the highest multiples in tech over the last 18 months) - for a site which is perpetually the butt of jokes about not being able to turn a profit. But there are a number of reasons it might be a smart move.

At it’s core, Google has always been about using the power of computing to make information searchable and organized.  Video has a major limitation – unlike text, you cannot search by keyword, only by ‘tags’ – self-reported information – or by context, in this case, “links.” If 12 people link to a video with the word “Tango,” for example, then chances are the video is about tango in some shape or form. 

But Google is pretty good about finding ways around these limitations.  Google 411 was a free service that had a secondary function – it allowed for Google to improve its voice recognition algorithms to the point where it could offer Google Voice.  And if it can offer Google Voice, which automatically transcribes audio voicemail messages into searchable text, it’s not that much of a leap to transcribe the audio track of uploaded video into searchable messages.  That makes video more attractive to advertisers. 

Where On2 fits into this is that On2 offers a video codec, called VP6, which is compatible with Flash video and provides roughly the same quality as the current standard, H.264, at the same bitrates (filesizes).  However, the processing power needed to decode (play) the VP6 codec is significantly less than the processing power needed to decode the H.264 codec. 

Obviously, this is an advantage for Google, who is producing its own “Google OS” for use with low-powered netbooks.  Plus, there’s an awful lot of slow computers out there that are still in use. 

But less obviously – and this is a guess – because VP6 takes less processing power to decode, complex complications – like trying to do voice recognition – can be done faster when decoding thousands of VP6 files at once, compared to thousands of H.264 files at once.  Even if the difference is on the order of microseconds per video, when you’re talking about the millions of videos on YouTube, those little microseconds add up quickly. 

Perhaps Google is losing money, but it may be because they're creating, essentially, a new application, and trying to get the best performance for it before trying to market it, and increases in application performance can often offset hardware costs, power requirements, or bandwidth needs. 

According to Yahoo Finance, which, you would imagine might have an accurate take on such things, Microsoft and Yahoo have finally agreed to a partnership.  You will remember that Microsoft tried to purchase Yahoo outright last year, but the deal fell through.  Instead, Yahoo will now use Microsoft’s Bing search engine to power search, while Yahoo will handle the online advertising. 

Why Yahoo decided to switch to Bing is unclear at this time, as Yahoo’s engine already serves nearly 20% of the market, compared to Microsoft’s 8.4% (and Google’s 65%).  I’m not prepared to speculate further than saying that Yahoo’s value isn’t really in the search engine, but the SAAS solutions that are so ubiquitous, one barely thinks of them.  Yahoo Mail, Yahoo Groups, Flickr, Del.icio.us, Yahoo Voice, and Upcoming.org.  Yahoo still has more overall users on the Web and more overall pageviews than Google.

Details are still sketchy, but the deal doesn’t seem to affect Yahoo’s SAAS offerings.  Perhaps that’s because Microsoft has gotten more aggressive on the online services front since they last tried to acquire Yahoo in February of last year, offering an ad-supported online version of Office.  Actually, that may explain the deal – Microsoft no longer needs to own Yahoo’s cloud software, but it still would benefit from Yahoo’s ad revenue model. 

We’ve talked in general about the effects of cloud computing on application performance. (Long story short: Just because it’s on the cloud doesn’t mean you can forget about making sure apps perform well.) However, one has to consider that if Office goes ad-supported, and widely adopted, how much traffic will be used up serving up those ads – especially if they’re large files, like those annoying flash-based video ads that pop up.  I suppose we’ll find out more as time goes on – whether they’re inconsequential, or eroding network performance in a matter not unlike being nibbled to death by ducks. 

Network World reports that Wal-Mart is going to be selling an AMD-Sempron 2.1GHz powered laptop with 3GB of RAM for less than $300. It’s a bit more powerful than what we think of as a “netbook” – which can go for as little as $238.

We’ve talked about how netbook ownership has gone hand-in-hand with cloud computing, but it struck me that we seem to have passed a point long ago where hardware was not the limiting factor for desktop applications.

That is, there was a time, not too long ago, when digital video editing was impossible for many desktop and notebook computers. (I’ll be referring to video editing and rendering a lot, as it’s the most processor intensive item I can think of.) Professionals could spend thousands of dollars – or hundreds of man-hours – to create videos, but home movie making didn’t really take off until the hardware could push enough pixels in a short enough amount of time.

Encoding MP3s used to be a chore. DVD playback required onerous hardware requirements. There were just some things that you just couldn’t do without a fast computer. The “top of the line” computers could do things that “bargain” computers couldn’t.

I’m not sure exactly when, but I think that we hit the point where having a faster computer didn’t open new doors to you, it just made what you already do, faster. Differences in degree, not in kind.

Certainly, video editing and rendering is faster on a quad-core i7 chip than on a single-core Sempron, but the point is that you can do video editing on a Sempron if you are willing to wait a while for the finished product. If you know you’re going to do a lot of processor intensive stuff, like gaming, or video editing, or audio mastering, or protein folding, you may decide that having the more powerful computer is a worthwhile investment, but it’s no longer talking about “need” but “convenience.”

I may be wrong on this, and I may even sound naively like Charles H. Duell in 1899, but I think that 20 years from now, we’ll still be using computers to do the same things that we do today, just faster. We’ll all be editing 4k or 8k cinema instead of high def, but it’ll still be video editing. We’ll still be playing games and browsing the web, compiling spreadsheets, etc.

Which is another factor in the rise of the “Cheaptop”; the fact that a lower-powered, cheaper computer can do the same things as its expensive cousins.

We have not, of course, reached that stage of network development; there are things you can do with an expensive, robust network that you cannot do with a simple, cheap one. And cloud computing has a way to go; not just because we’ve yet to find workable replacements for all our desktop apps on the Web, but also because the real limitations in network performance make some tasks, especially those that require low latency (like gaming) or high throughput (like video editing) difficult.

But it’s also why people are trying to find solutions to putting gaming and video editing on the cloud – because the challenge is still there. The things we cannot yet do will not be desktop applications – the things we cannot yet do are things that we will be doing on the cloud. It’s why the hype is so powerful and pervasive with cloud computing – because we techies are always looking for the next big challenge, always looking at ways to do more things. Doing them faster is great – that’s engineering. But doing new things – that’s invention. And that’s a hell of a lot “sexier.”