As we all know by now, today is the 40^th anniversary of Apollo 11’s moon landing, unless you are one of those few who choose not to believe the Mythbusters when they debunked the idea of a moon landing hoax. Then there’s my uncle Edward, who believes that the moon landing was faked from a soundstage located on the surface of the moon.

Today, the moon landing is humbling for those of us who think in terms of networks, routers, and switches – the Internet is amazing in its communication potential, but for all the good it’s done, it’s still essentially terrestrial. The furthest the network travels is to orbital distance – and only as a waypoint.

Because of the sheer distances involved, new technologies have to be invented and improved, like Vinton Cerf’s InterPlaNet; and just as the Apollo mission gave us digital watches, cordless drills, the joystick, the smoke alarm, and so many others, interplanetary Internet promises similar advances for computer technology – from improvements in security for electronic mail, to improved performance in communication challenged environments, like disaster recovery scenarios, the developing world, and the military at wartime.

In fact, it was earlier this month (July 7^th, to be exact) that the International Space Station turned on the first node in a permanent Interplanetary Internet, using a protocol known as “Delay Tolerant Networking” (DTN for short) and is designed with huge latencies and dropped packets from solar storms, or being on the wrong side of a planet, in mind.

And while astronauts typically have more important things to do, they can Twitter. (“OMGWTFBBQ - Houston, we have a problem. :-(”)

One interesting thing I just learned was that Apollo 11 had its own minicomputer on board – minicomputer in the 1969 sense of the term – because there was a 2.5 second delay between Houston and Apollo 11 due to speed-of-light issues, and that 2.5 second delay was far too long for the astronauts, hurtling around the moon, to gather, send, retrieve, and act on data. I suppose there are parallels to cloud computing here, but I’d rather not stretch it.

Anyway, that minicomputer was the first of ever smaller and smaller computers, rather than ever larger and larger computers which characterized pre-1969 computer development. Now we have computers the size of – actually, I don’t know how small computers are nowadays; I’d mention the iPhone, but you just know someone’s coming out with a cellphone twice as powerful at half the size a month from now…

Point is, today’s a day when we can look back at one of the most powerful technological and scientific triumphs with a sense of techie-geek pride. It was the nerds with pocket protectors that got us to the moon and back. And I’m proud of that.

By Keith Bendy
Business Development Manager, NetQoS

It’s hard to miss the “human network” theme in virtually all of Cisco’s recent commercials. They are clearly advocating a lot of converged network capabilities – voice, video, and other interpersonal communication or information methods.

It makes sense – video and voice are bandwidth heavy applications, and it’s a logical growth area for Cisco if they can provide more information about video and voice traffic. The challenge, however, is that despite all the video products they’ve brought into the market, (from Telepresence to the acquisition of Flip), there aren’t a lot of robust capabilities built into the products in order to troubleshoot performance.

Medianet is one of the largest initiative in Cisco’s history, and it’s focused on bringing those exact troubleshooting capabilities to the market. The objective is to integrate media traffic reporting into Cisco products and IOS, and get the ability to really understand what performance is for video and voice traffic. And in addition to troubleshooting, even having the ability to have the infrastructure react to changes in performance (i.e., “Autoprovisioning”) is really what the overall goal is for MediaNet.

MediaNet is just starting up, but Cisco is addressing a need that is very real, so I anticipate that its adoption will be high. Cisco may be ahead of the demand curve, but the need is pretty well established.

At a very high level, what's important to MediaNet customers is the ability to understand what performance looks like, find out where the issues are, and then drill in to get the information required to get the issue on the path to resolution. And so, when Cisco wanted to demonstrate the MediaNet capabilities at Cisco Live, they used NetQoS Performance Center because they have a lot of experience working with NetQoS (on products like WAAS, ACE and NAM) and it can take advantage of capabilities that exist today (like NBAR, IPSLA, and Netflow)

With Netflow, the NetQoS Performance Center is able to show how much video is on the network, and use TOS values to determine how the traffic is tagged. We can also see what the end-point IP addresses are. But NBAR provides deeper recognition of the protocols than what Netflow will typically give you. NBAR reports on specific tags for various traffic - instead of saying "This particular TOS queue is all my video traffic, and I don't know what kind of video it is," the NBAR identifiers would say: "This is telepresence traffic, this is security camera traffic, this is WebEx traffic, this is a video-capable phone” - and tag all of it appropriately.

Below is a video, from Cisco’s YouTube page, where Aamer Akhter, Technical Marketing Engineer at Cisco, demos the Cisco Medianet 1.0 network.

We’ve been harping on NBC Universal’s coverage of the Beijing 2008 Olympics, so it seems fair to look forward to the 2012 Olympics in London.

First, Cisco has become an official Olympic sponsor, replacing Nortel, which has filed for bankruptcy. 

Interestingly enough, though there’s certainly a lot of infrastructure associated with organizing the games – the needs of multiple events and multiple athletes, in multiple languages, when you’re talking about the main challenge that the Olympics produces for telecommunications networks – it’s gotta be video. 

Video seems to be at the core of Cisco’s strategy; everything from teleconferencing to those little Flip cameras is part of Cisco’s purview.  Sponsoring the Olympics is a great test – but let’s also not forget the ambitions of Cisco in sports.  The Cowboys Stadium has nearly 3,000 flat screen TVs connected via IP enabled video.  The TVs are from Sony, the content from DirectTV, everything else, from the head end to the digital media player, is from Cisco. 

(You’ll notice that we skipped over the 2010 Olympics, but as they’re being held in Vancouver, British Columbia, getting the data into the United States will not be so nearly a daunting challenge. Besides, the Vancouver 2010 logo is just a guy made out of what looks like lego blocks.  The 2012 London logo is much more interesting…)

By Brian Boyko
Editor, Network Performance Daily

I’ve been getting better and better with video as I’ve worked here – and I noticed that many people don’t really understand the nature of digital video files – what makes one file big, what makes one small, what makes one 20 MB file look good, while another 20 MB file looks lousy. 

Considering that Cisco is claiming that video will take up 90% of all traffic by 2013, it might be important go over some of the ideas about what makes up digital video files at the low level so that you can understand how they impact your network. 

If you already know this, I apologize. 

Digital video files are, essentially, pictures.  Multiple pictures played in sequence, with an audio track.  And like digital pictures, they can be compressed.  Uncompressed video is like a photo in BMP format – perfectly accurate, but huge.  Compressed video is like a JPG file – it creates artifacts, but is much smaller. 

There are many compression schemes, with advantages and disadvantages, based on different ways to compress the file.  Some are more effective at reproducing more accurate information with smaller filesizes, but ultimately, from a networking perspective, it’s really not important which you’re using.  What is important is the resolution, framerate, and bitrate. 

The resolution is the size of the video in terms of how many pixels you can see on screen.  It’s usually in varying rectangle sizes, but it’s usually expressed as the size of the rectangle (i.e., 640x480) rather than the absolute number of pixels.   High definition television comes in two types: 1920x1080 (a.k.a. “1080”) and 1280x720 (a.k.a. “720”), and “720” is the format used for YouTube high definition video.  Standard definition television comes as either 720x480 (NTSC) or 720x576 (PAL).  

The framerate is the number of frames – or pictures – that are shown each second.  In a filmed Hollywood movie, it’s typically 24 frames per second (or 24p).  On television, and with most recording equipment, they usually show 30 frames per second in the U.S. and 25 frames per second elsewhere in the world – though, in order to get faster motion, they often stagger every other line of resolution and place them between every other frame – so when you watch 30 frames per second of TV, you’re really watching 60 “half-frames” per second - also known as 60 interlaced frames  (or “60i”).

Finally, the bitrate is the number of bits of information that are in the file for each second of video.  A file with a bitrate of 512kbps has exactly 512 kilobits per second in order to convey all the information it can about the video.  With more bits, you can contain more information. 

Ultimately, the only thing impacting the network is the bitrate.  Bitrate determines filesize for downloadable video, and bitrate determines bandwidth requirements for streaming video.   A 3Mbps SD video will be the same filesize as a 3Mbps HD video, for example, provided that they are the same length. 

The quality of the video, however, is impacted by resolution and framerate as well as bitrate.  

In one second of 640x480 video at 30 frames a second, and 24 bits per pixel, you have 210 megabits worth of information.  Representing that, with, say 3 megabits is a daunting task.  On the other hand, if you increase the framerate to high definition – 1280x720 – you get 632 megabits of data per second – and representing that with only 3 megabits is an even more daunting task. 

The higher the bitrate, the higher the quality of the video; but the higher the resolution and framerate, the more you have to increase the bitrate in order to get the same level of quality.  High definition files tend to be larger than standard definition files because they’re usually – but not always – rendered at a higher bitrate. 

This was one of the reasons that when NBC was covering the Olympics, they often sent the raw footage from Beijing in low-resolution, low-bitrate formats, and only sent high-resolution files to their editors in the U.S. when they knew exactly which shots they wanted to include in their broadcasts.

By way of metaphor, think of bitrate as a fixed amount of butter that you have to butter bread.  You could spread out a single pat of butter on a whole loaf of bread, but it wouldn’t taste very buttery.  Or you could just butter one slice with that pat, but the bread wouldn’t be very filling.

Where different compression schemes come in is that they’re ways to use the limited amount of bits in each second of video to represent all the information – some compression schemes simply look better than others.  Right now, the leader seems to be H.264, which is about twice as efficient as the file system used to store information on a DVD (MPEG-2.)  A 3Mbps H.264 file and 3Mbps MPEG-2 file will have the same filesize, but the H.264 file will simply look better. 

Bitrate is also important because for streaming video, the bitrate of the video is equal to the amount of bandwidth required in order to show a video without pre-buffering or jitter – especially important for live applications like teleconferencing.  Lowering the bitrate decreases the quality, but image fidelity is often less important than immediate response time in teleconferencing applications.  (There are other issues that can cause jitter even with sufficient bandwidth, so it pays to monitor your communications network.)

At any rate, I hope you find this information useful when dealing with bandwidth.  At least now, when someone complains about how long it takes to download a video file, instead of spending tons of time and energy on network upgrades, you might want to ask if you can get a lower bitrate file instead. 

The Guardian reports that among teens, at least, peer to peer downloading of MP3 files of favorite songs is on the decline.  That’s good news for the RIAA labels, who can control the content on streaming sites more than they can control peer-to-peer networks. 

The bad news?  The teens are switching to streaming sites, like YouTube and Spotify. 

From the record company’s standpoint, this is a good thing – it’s a lot easier to control distribution to streaming sites, and taking down a single song with a DMCA notice takes the song down for everyone, as opposed to peer-to-peer, which cannot effectively be shut down at all.  But there are several differences between MP3 downloading and streaming which can impact corporate networks.

While peer-to-peer downloading does take up some bandwidth, the main problemswith P2P usage at work is the idea of liability for copyright infringement and computer security.  For that reason, it’s tempting for office workers who cannot get that song out of their head to, instead, go to YouTube, do a search for what you want to hear, and listen to the song online.  The first problem with this: Streaming audio and downloaded audio take up the same amount of throughput – but a downloaded song is likely to be downloaded once and listened to multiple times; streaming audio is likely to be downloaded multiple times each time the office worker wants to listen. 

The second problem: The listener may only want the music, but more often than not, YouTube video comes along with it.  So instead of 128-192kbps for an MP3 file, you’ve now got a 2-6Mbps video file to deal with. 

Now, even though the amount of traffic is increasing, you should have no problem handling it by classing streaming audio with non-business related traffic and monitoring your network to see if there are any changes in performance. 

by Patrick Ancipink
Director of Product Marketing, NetQoS.

Baseball has forever been a game adorned with statistics. Have you ever spent a rainy day with the Baseball Encyclopedia as a kid – or as an adult?

However, the dawn of the Moneyball age elevated a wide range of statistics from playground debate to the general manager’s office and contract negotiation. Specifically, Moneyball strategies, which downplay the importance of traditional, 19^th century baseball statistics (runs batted in) for ones that modern statistical analysis was more indicative of success (on-base percentage, slugging percentage) has helped teams like the Oakland A’s and Tampa Bay Rays contend for the World Series.

However, even with the Moneyball philosophy, there was still a significant blind spot when it came to quantifying performance in fielding, a traditionally hard to quantify area. Sportsvision, the company best known for bringing us the “first down line” on televised football games is, according to the New York Times, making an attempt to do so.

Which shortstops reach the hard-hit grounders up the middle? Which base runners take the fastest path from first base to third? Which right fielders charge the ball quickest and then throw the ball hardest and most accurately? Although the game will continue to answer to forces like wind, glaring sun and the occasional gnat swarm, a good deal of time-honored guesswork will give way to more definite measurements — continuing the trend of baseball front offices trading some traditional game-watching scouts for video and statistical analysts.

So that’s cool, but beyond my interest as a baseball fan, why am I writing about this? Because I was struck how fielding percentage is analogous to up/down fault management in its limitations.

The primary job of a fielder is to turn batted balls into outs: an infielder by gobbling up ground balls and throwing them to a base, and an outfielder by catching as many fly balls as possible. But errors (and the rate of not making errors, which is fielding percentage) measure only a fielder’s glaring mistakes — they ignore the more important matter of who reaches balls that others do not.

Using fault statistics for measuring network performance has similar limitations. Uptime/downtime is a measurement, but not a proxy for overall performance. Removing blind spots and quantifying performance is exactly what NetQoS is all about.

Also, I was working on a proposal for combining IT and baseball into a professional competitive sport I call “Packetball.” If any of you out there knows Hal and Hank Steinbrenner’s phone number, can you let me know in the comments section? Thanks.

North Korea is suspected to be the culprit in a botnet attack against South Korean and U.S. Websites. Though, even if you have rubbed “Dear Leader” the wrong way, the attacks supposedly coming from North Korea come from a botnet of “tens of thousands” of computers using a 2004-era MyDoom variant. By way of comparison, F-Secure says that they’ve calculated nearly nine million infections of Confickr. At the peak, the attacks are putting out 25Mbits/sec… roughly enough to saturate two cable network connections, one fiber-to-the-street connection, or half of a fiber-to-the-home connection.

So, if you’re having performance problems today and you get told a story that it’s all because of Kim Jong-Il, skepticism is an appropriate response.

The Google Chrome OS is real, but it probably won’t be that big a deal for most people.

Oh, I mean, sure, it may be a raging success or a colossal failure (I really can’t see a middle ground on this) but so far, we have no screenshots, and not much information other than a post on the Google Blog which confirms the rumors: A Linux-based application which starts with low-power, high-connectivity “netbooks.”

Let’s talk a bit about what a “netbook” is. A netbook is a cheap laptop which is significantly underpowered compared to “notebook” brethren, and the users of the netbooks tend to not need support for peripherals nor, in many cases, any desktop applications. Netbooks are designed to browse the web and do cloud-based computing.

We’ve had the technology for netbooks for years (Mini-ITX boards with AMD Geode processors were around in 2002), but we never had the demand. The convergence of lowering hardware prices and a lowered need for desktop processing power resulted in a perfect storm where netbooks became economically feasible.

There’s still a demand for high-powered laptops – especially among space-cramped college students and young professionals who rent a room in a 4/4 condo with three roommates. But the high cost of the high-end of notebooks has had many people realizing they can buy a desktop computer for high-end applications which require tons of processing power, and use the netbook for connectivity on the go at the same, or lower, price.

It is into this market that Google is entering, and while cloud apps would have been possible without Google, it is Google’s cloud applications – which have recently come out of beta, by the way – which make the whole thing possible.

Is the development of a GoogleOS a broadside against Microsoft? No – I just think that Microsoft has too much inertia to be making anything other than big, monolithic desktop applications for the near future. They’ve built an entire corporate culture around the coding base. But desktop applications aren’t going away anytime soon.

There are advantages to be found away from the cloud as there are outside the cloud. Google Docs is great, but it’s not as full featured as Word, which provides features that you can only get in a desktop word processor. Only a small minority of people will need Word’s “data merge manager,” for example, but for them, the service is indispensible.

Essentially, the Google Chrome OS is tied to the fate of cloud computing applications.

Considering that the OS isn’t due out until 2010, and that the market for netbooks may have changed radically in that time, Google Chrome OS probably isn’t a Microsoft killer – or even a Microsoft wounder – as netbooks are too low-powered to run Windows Vista anyway.

But there is one problem. There are now multiple services trying to bring “cloud gaming” – fully rendered 3D gaming, running over the cloud, to gamers running on any type of hardware – whether or not they have powerful processors or graphics cards. Holding them back: network performance – games require very low latency.

However, if you can run a virtual game on a virtual server and send the pictures back as output, there really is no limit to the types of applications you can run – which include fuller featured word processors, presentation applications, photo manipulation, audio editing, video editing, even 3D rendering. The last two, specifically, would benefit greatly from cloud computing, as rendering can be solved by simply brute-forcing video compression. The development of Google Chrome OS – an OS without much, if any, desktop application support – seems like it’s the herald of a cloud-only world.

Except, of course, those virtual games on virtual servers still have to deal with latency, and those large HD files still have to be uploaded to the server – so limited by throughput that you’re better off rendering on your 8-core behemoth. Like all network applications, the real issue is performance. Cloud applications trade performance for convenience. That may be a sacrifice most are willing to make when looking for a netbook, but everyone has time to time to need a powerful computer.

One of the things holding back the rollout of new applications (like VoIP, Video, and Unified Communications) is the fear that the new applications will cause network performance problems; according to Network World’s Denise Dubie, citing a survey from Apparent Networks.

Nearly 61% said that they had delayed a VoIP implementation due to network performance concerns. Some 35% postponed a video rollout for the same reasons and 26% put a unified communications project on hold. The survey also showed that network managers can’t always validate their service-level agreements (SLA) with external service providers. More than one-quarter of respondents don’t have the capability to validate SLAs.

It would be instructive to know if decision makers are “concerned” that new apps will reduce their performance because they have baselined performance and know that the network cannot handle new application rollouts… or if they’re concerned because they have no idea whether the network can handle it or not.

It’s the difference between being stopped by practicality and being paralyzed by fear.

And if you’re being paralyzed by fear, it’s costing you money.

For example, Cisco decided to “eat it’s own dogfood” and estimated that they saved $277M from bringing in their own virtual office telecommuting technology – a new application (based on their “Cisco Virtual Office”) for the network that leads to cost savings. If Cisco didn’t know that their network was capable of supporting the CVO application, they would have been out $277M.

Of course, the reason you don’t roll out an application that might save you millions when you don’t know whether those applications will negatively affect network performance is that poor network performance can cost more than whatever you’d save by the rollout.

You can know, or you can be paralyzed by fear of the unknown. I know which I’d rather be.

There’s an article from Jon Brodkin at Network World on the lack of interoperability standards in cloud computing. That is, one of the main benefits of virtualization and cloud computing is the ideal of developing an application once and being able to host it from any data center connected to the Internet. But as vendors try to compete, they may be tempted towards vendor lock-in. Applications developed on Amazon’s cloud computing platform won’t be easy to move to a competitive service, for example.

Since the whole point of cloud computing is essentially to turn IT infrastructure into a commodity, it can be very tempting to want to differentiate offerings by any means necessary. But because it is a commodity, standards of interoperability make cloud computing as a whole more useful overall.

Brodkin points out what the ideal of cloud interoperability can bring. From the Network World article:

• Moving virtual machines and workloads from one cloud compute service to another.


• Single sign-on for users who access multiple cloud services.


• Ability to deploy and provision resources from multiple cloud services with a single management tool.


• Letting one application span multiple cloud services (such as a storage service from one cloud provider and compute capacity from another).


• Allowing data exchange between clouds.


• Letting a private cloud application seamlessly obtain resources from a public cloud when excess capacity is needed.

“In more general terms, enterprises want to avoid using a plethora of cloud services with different interfaces, and don't want to be locked in to a particular cloud by technologies that prevent the movement of workloads from one to another.”

There are some efforts among cloud computing services to adhere to voluntary standards, for example, the “Open Cloud Manifesto” attempts to create an industry standard; though it’s hard to do so when the de-facto cloud computing 800 lb. gorilla, Amazon, isn’t part of the “Manifesto” group.

But one of the interesting things from a network performance standpoint about cloud interoperability is that if applications can interoperate from cloud host to cloud host, they can also, theoretically, be developed on the LAN/WAN and then moved, without much effort, to the cloud. This means that developers can code an application, baseline performance, and see what types of changes in performance occur when moved out to the cloud – or vice versa.

Indeed, interoperability makes it possible for applications which reside at the local data center to expand capabilities by going to the cloud whenever capacity outstrips demand – a way to prevent all your eggs from sitting in one basket.

For more background on this, you can check out this video Jim Metzler of Ashton-Metzler did with Cisco on cloud computing, and check out his entry in our Performance-First Insight Series, “The Management Challenges of Cloud Computing.”