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.”

If you were to ask me my five favorite comedy troupes of all time, I’d probably name the Muppets, the Kids in the Hall, Backpack Picnic, Monty Python, and the Legislative Branch of the U.S. Congress.

This is just a quick post today, but I wanted to follow up on something I wrote yesterday about user interfaces.

The Washington Post has a copy of the flowchart used by Rep. John Boehner (R-OH) explaining his opposition to the Democratic Health Care Plan.  Look, I’ve only taken one class on graphic design, but that’s pretty much textbook “confusing” and “scary.”  It’s actually kind of ingenious – by using different fonts, different shapes, confusing-to-follow arrows, and a color scheme best described as “Eegah!”, the Republicans have made their case that the health care plan will result in scary, confusing… charts, apparently.

Then you take the flowchart put out by the New Republic which is similarly complicated, but less scary, showing the current state of health care in America, and while it’s not designed to be scary, it certainly is complicated.

Which brings us to graphic designer Robert Palmer, of California.  Palmer took the healthcare plan, and tried to create a flowchart that presented the information about the Health Care Plan in a way that’s intended to educate, rather than confuse. 

Now, whether or not the health care plan is a good idea is beyond the scope of this blog.  But it illustrates a point about how important it is to present information in a way that those who need to understand it, can easily understand it. 

There’s an interesting article in the automotive section of the New York Times.  It talks about how the Ford Motor Company creates fictional personalities which detail a “typical” end-user for an automobile they hope to design – and then they design the vehicle around that end-user.  Ford came up with the process because they found that car designers were designing cars that they themselves would like. 

“Invented characters get everyone on the same page,” Mr. Callum said. “Personalizing gives context to the information we have. Sometimes the target demographics are difficult to relate to by, say, a 35-year-old male designer.

“We found in the past that if they didn’t understand the buyer, designers would just go off and design something for themselves,” he added.

One of the interesting things about that broad range of categories we call “IT” – network architecture, software development, even the first couple of days you work tech support - it’s a lot easier to design technology for yourself than for someone else – the intended user – who can’t always articulate what they want or need. 

This is perhaps most evident in the user interface for open-source programs.  Not to say that open-source programs are bad or anything, but an open-source developer coding an app primarily for his own needs might very well code a console app, or an app with a confusing UI – it doesn’t matter to the developer however, as he knows that he’s designing it only for himself.  Even when taken to a broader audience, developers often code for other developers. 

We’ve mentioned before that we try to design our products with multiple audiences in mind – with executive level reporting but an ability to drill down into the details for the network engineer on the front lines, for example.  But the NYT article got me thinking about something else – and that is, do network architects design networks with the end-user in mind?  Or do they design networks for network architects? 

After all, the network for a development house has different needs for a network for an accounting firm, which also has different needs than a network for a video production facility.  Should we be thinking more along the lines of designing the network around the business need, rather than adapting a generic network to the business need?

Food for thought.

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.