By Brian Boyko
Editor, Network Performance Daily

There are a couple of big stories regarding consumer P2P today. Trent Reznor, fed up with his label's pricing of his albums in Australia has told his fans directly that they should "steal it," at a Sydney concert. A video of the concert, leaked to YouTube, made it to the front pages of many social news sites.

I can't endorse Reznor's suggested course of action, but I'm not going to not endorse it.

At the same time, e-mails leaked from MediaDefender, a company that patrols P2P networks looking for copyright violators, showed that, despite MediaDefender's prior public assurances, they were operating a video uploading site called MiiVi, which many suspected was a "trap" to lure copyright infringers - among other concerns.

And with all this coverage of P2P technology in the news, I thought - what ever happened to those promised P2P corporate networking apps? Back in 2005, Network World mentioned "Groove Networks Virtual Office." In that story, the author states:

"With the adoption of Globus 4.0 as the new XML-based protocol standard, grid services will become the P2P of Web services…."

"Be forewarned, get educated and be prepared for the network implications of corporate IT P2P applications. The corporate next-generation network future may be just around the corner in 2006."

Searching for Groove Networks on Google leads to Microsoft's Web site - It's an add-on for Microsoft Office now. Not surprising, as Groove's founder, Ray Ozzie became Chief Software Archetict at Microsoft. (He was also the brains behind Lotus Notes)

I looked up Globus as well. Globus's is more of a project to create a computing grid of corporate network computers - which is a pretty cool idea. 90% of the time, I'm not using 100% of my dual-core processor computer here at work. The other 10% of the time, I really could use more processing power to render video. If there's a way to grid-together peer-to-peer corporate computers so that everyone gets the power they need to do their jobs, sharing CPU power over the network.

Still, I don't think most companies are ready to go that far - mostly, I think, they just want their files faster and their latency lower.

So, where are the corporate P2P applications? Maybe I'm overlooking them (and if so, I'd love for contributors to point out projects to me in the comments) but it seems like this is an area of technology that was abandoned too quickly, and maybe deserves reexamination.

----------------------------

(N.B. We tried to contact Ray Ozzie at Microsoft for his thoughts on this matter, but was told by a representative of Waggener/Edstrom that Microsoft was unable to participate in this particular opportunity at this time.)

Editorial, By Brian Boyko
Editor, Network Performance Daily

Sun Tzu once wrote that "the general is skillful in attack whose opponent does not know what to defend"

Last June, the Chinese military hacked into the Pentagon and U.K. military computers. This fueled speculation that the next major conflagration (not that any of the current conflagrations aren't major) will be fought with information warfare. Coupled with yesterdays' anniversary of the gruesome attacks six years ago, and the general fear of the unknown (except for a smart few, computer hacking qualifies as "the unknown,") and you start to deal with fear. Fear of China shutting down military defenses. Fear of a terrorist network intentionally disrupting the computer infrastructure behind the U.S. economy.

I've never liked fear. Fear can lead you to stupid conclusions. Fear can lead you to bad decisions. Fear is the mind-killer. Fear is the little-death that brings total obliteration.

So, how do you deal with fear? First of all, you "know yourself and know the enemy."

Battlefield advantage can be found by destabilizing a military computer, it's true, but military computers are well defended with the near infinite resources, manpower, and budget of the Dept. of Defense. But if someone - whether a large state or rogue group, were to attack, they would probably choose targets which would do the most damage with the least effort and risk. Those might be corporate systems.

While it is impossible to predict what a terrorist will do - because there are many different types of terrorists with different motivations even within the same terror group - it is possible to anticipate what a rational attacker would do. Ts`ao Kung said that an effective attacker "Emerges from the void, strikes at vulnerable points, shuns places that are defended, attacks in unexpected quarters."

(Continued...)

Continue reading "Is Enterprise Networking The Next Battlefield?" »

By Bill Alderson
Senior Consultant, NetQoS

One of the problems that we have in the industry right now is trying to match up application transactions with statistics that come from devices such as servers, routers, network components, etc.

Network components deal with capacities and how many bits per second, or how many packets per second, or how many TCP connections are traveling through. In our case, at NetQoS, we look at data that is received in a "blob" or a group of data perceived as a single request. The next data blob going back is perceived as the response.

So when you look at that kind of a blob request and a blob reply, taking it and figuring out what the real business application transaction is can be difficult. For a Web site, the application transaction might be orders or page views. There are a number of various types of application transactions that we try to relate back to some form of performance that we have statistics for.

What business management is looking to accomplish is the performance not of the network transaction but of the business transaction.

We're in a place in the industry where we finally have a lot of device statistics and capacity measurements. We even have blob-to-blog response times. But identifying that transaction that the business is trying to get at is difficult to find. One of the problems with our statistics at the device level is that there may be tens of thousands of micro-transactions that lead up to what we would call a macro-transaction at the network level or the application level. But that may not even be enough. There may be hundreds or thousands of such transactions that make up the business transaction.

How do you find the performance of a business transaction? You have to go through the process of finding the little micro-transactions that build to the macro-transactions that make up the business transactions that you're trying to find performance on. And we're grappling with that today, because it's not always a 1 to 1 ratio.

It's more often than not, a multi-tiered transaction on top of that. When you're trying to measure that, there may be multiple sites that the transaction goes to. For an order, for example, there can be a transaction to check for stock, another to check pricing, another that pulls the customer data, and then, of course, there's distribution and shipping, etc. Whatever the type of transactions, the performance of this particular transaction and all the transaction's dependencies - well, it just gets to be a really complex equation that we haven't completely solved in all cases, not least because the order number is not typically placed within each and every packet for the business transaction.

On the other hand, you know what they say. Identification of a problem is more than 50% of the solution. In future weeks, months, or years, we'll start to converge and actually design into our applications as we're building them, how to measure performance of each transaction, rather than waiting for performance of a system or subsystem to fail or become suboptimal.

Editorial, by Brian Boyko
Editor, Network Performance Daily.

Volume 2 of our semi-annual magazine, Performance Edge Journal, is now available in print and downloadable online.

This issue is the first by our new, brilliant, editor-in-chief. He is highly respected by his peers, with lifetime accomplishments and a knack for getting hard interviews and writing in a way that changes minds. His academic and professional credentials speak for themselves.

In other words, I'm the editor-in-chief. But never mind that.

In it, you'll find a number of in-depth articles on VoIP Performance Monitoring and WAN Optimization, as well as NetQoS CEO Joel Trammell's look at the future of network performance management, results from a survey on recreational network use, a look at Cisco IOS NetFlow vs. Cisco IP SLA, and more.

Here's a quick excerpt from "The Future of Network Performance Management - A look into Joel Trammell's Crystal Ball."

Over the years, computer and communication networks have grown in size, scope, and complexity. Since the early days of DARP, the internet's predecessor-almost 50 years ago!-as much research and development has gone into the network itself as into the research it supported, resulting in a technology that now spans the entire globe. We have become dependent on that technology in ways we couldn't have imagined even a decade ago because of that dependency. The need to manage networks has become more and more important to everyday work and life.

The discipline of network performance management is much more critical today as more and more people rely on application services delivered across farflung networks. Industry Analyst Jim Metzler asserts that there are two main functions of IT: Application Development (which includes both work done by internal development teams or contractors, as well as licensed commercial applications and software as a service), and Application Delivery (how those applications are made accessible by end users, including customers, employees, and partners).

From this vantage point, network performance management must mature to encompass application delivery management, and move away from being as functionally compartmentalized (in terms of network management, server management, application management, and so forth), as it typically is today. IT organizations must evaluate the processes and tools they use today to understand if they are sufficient to ensure reliable delivery of applications, measure service and application response times that users experience, optimize the network for service delivery, troubleshoot performance issues, and so on, within large, increasingly complex IT infrastructures.

Not surprisingly, the job of network professionals is going to get more complicated over time as:

• network bandwidth continues to increase
• more services and applications use the network
• more varied types of traffic traverse the network

To read the rest of this article, you can pick subscribe at Performance-Edge-Journal.com

By Brian Boyko
Editor, Network Performance Daily

It seems that everyone is up in arms over Adblock, a FireFox plugin that enables users to block any ad with a right click or the downloading of a filter file that lists the most common advertisers. This has put fear into the hearts of Web content providers who make their living from advertising, with some calling it the "Nuclear Plug-in" - an "evil predator" that is "quietly eyeing all the businesses it would happily devour." - a plugin that is, even in the New York Times, regarded as an "extreme menace to the online-advertising business model."

One Web designer was so adamant about the Adblock plugin - he said that when you read the content without viewing the ads, you're "stealing" - that he blocked Firefox browsers entirely from his Web sites.

Criminy! Get some perspective.

First, from an enterprise network performance standpoint, there's absolutely no downside to not just encouraging Adblock in the name of both bandwidth conservation and network security - but to actually make it mandatory. The most annoying ads - flash banners, pop-ups, etc. are the ones that usually take up the most bandwidth and are more likely to have nasty malware payloads which cause more bandwidth and network security problems.

Relying on end-user action to prevent network performance problems can be futile, but encouraging users to use less bandwidth by doing something that they'd probably like anyway will do nothing but help.

So where does that leave people who earn a living, in part, from online advertising? Whatever the case, the Mozilla Foundation and Adblock does not "owe" advertisers a living. They didn't steal from advertisers any more than companies that make bank vault locks "steal" from bank robbers, or, more aptly, people who make earplugs steal from car-alarm manufacturers.

(Continued...)

Continue reading "Adblock: Adapt, or die." »

By Brian Boyko
Editor, Network Performance Daily

We were supposed to have the video of Dr. Steve Fulton we put up on Thursday night up by Wednesday afternoon. That didn't happen.

By coincidence, we also saw this opinion piece by John Dvorak, and linked to it the day before we needed the video to go up. The article, entitled "Don't trust the servers," talks about problems with Windows Genuine Advantage and how it illustrates the problems with SaaS solutions - that you're eternally dependent on a third party to continue to provide service.

In our case, we rely on Google Video to provide the bandwidth and hosting for the videos in our Whiteboard series. Now, you can say what you want about "getting what you pay for" and the like, but when we couldn't upload our video to Google, I realized how dependent I had gotten on their SaaS video hosting solution.

I couldn't log-in to upload the videos. At first I thought the problem was at my end - perhaps Symantec Anti-Virus had caused some sort of conflict or had firewalled off the ports that Google's video uploader needed. That wasn't it. Maybe it was something with our in-house network. That wasn't it either, as I found out when I took a copy of the video home and tried to upload it from both my Windows XP and my Linux partition. Nada. Zip. Zilch.

Despite the fact that Google's help files had a ready - and wrong - answer to every problem I came across, the problem was entirely Google's. And there was nothing I could do about it until they finally fixed whatever the problem was the next day.

See, while there are a number of video hosting solutions out there, Google Video and Veoh were the only ones that allowed me to upload clips more than 10 minutes long - and Veoh's playback was poor. Even if I could re-code the entire video at a lower resolution to lower the filesize, that didn't matter. Ten minutes was the hard limit on YouTube (also owned by Google) and other sites. My 25 minute video needed Google Video.

Eventually I was able to get the video uploaded, and though it took a while to process, it went up last night.

This isn't the first problem we've had with SaaS. Expensable.com often goes down for a few hours and we can't log expense reports. I use Gmail for my personal e-mail and while it's generally reliable, it does have some problems.

All in all, if you're looking at it from a productivity or a network performance view, moving your apps from the local network to a third party service - well, yes, it will absolutely save bandwidth and may make the network run faster for your other apps. But having a faster network doesn't mean anything if the end-user is waiting for a third-party service as long or longer as they used to wait for their slow-loading WAN apps. Or, in other words, you're not solving the problem of slow performance from the perspective of the end-user. You're just shifting blame.

This is not to rag on SaaS. I haven't lost an e-mail since I started using Gmail in 2004. My Flickr account saved pictures of my deceased friend John when my hard drive stopped working one day. And if it wasn't for YouTube, I'd never be able to show my parents in Virginia anything about my life in Texas.

But these experiences are a bit of a wake-up call that SaaS isn't going to solve every problem. Ultimately, the end goal of enterprise network performance is not to keep the network running as fast as possible, or to free up as much bandwidth. It's about finding the solutions which make the end-users more productive and enabling the company to do more as a result.

If you missed his presentation at Cisco Networkers, we have a slightly abridged version of Dr. Steve Fulton explaining how to quantify the impact of WAN optimization on application performance, as part of our "Whiteboard Series."

(Our apologies: there is no actual whiteboard used in this video. We just didn't want to go through the trouble of creating a separate "PowerPoint Series" graphic and category.)

If you have questions about the video, please leave a comment below and we'll do our best to answer them.
--------------
More information:

About WAN Optimization:
- What’s Behind Door #2: WAN Optimization and the Transparency Problem
- WAAS Up with Cisco's WAN Optimization Initiative?

Also in our Whiteboard Series:
- The impact of Voice/Video on Data Applications
- The impact of WAN Optimization on TCP Applications
- The impact of WAN Optimization on NetFlow/IPFIX measurements

By Brian Boyko
Editor, Network Performance Daily

Right now there's a bit of a brouhaha about Comcast high speed service. Many Comcast customers are finding themselves cut off from the service because of excessive usage.

To be fair, I was unable to find any reference where Comcast says that their broadband package is "unlimited." However, they fail to disclose what, exactly, "excessive usage" consists of in their Acceptable Use Policy.

I don't have a problem with Comcast limiting bandwidth. There's only so much traffic that their servers can handle, so much that can go down their pipes. Theoretically, limiting the use of the heaviest users would enable better service for the vast majority of users for whom speed is more important than volume.

(Of course, the cynical assume that Comcast is dropping high-usage customers because they're the least profitable and that supporting those users would require investing more in bandwidth and infrastructure - but we'll leave that theory alone for now.)

What I'm concerned about is people suddenly being disconnected from the Internet after passing a line that they know nothing about. I'm sympathetic - my Internet access was cut off without warning back in 1998 at The College of New Jersey, and that cost me a pretty well-paying part-time job as a Web designer. (There were other reasons, but this was a significant reason that I decided to transfer to New Jersey Institute of Technology the next semester.) If my home internet access was cut off today, I'd be at a serious disadvantage with my job editing this blog!

But it also worries me because I can't imagine this happening to a corporate customer. If an IT department asked "how much bandwidth do we have," that information would never be withheld from them. You can't do any meaningful capacity planning if how much capacity you have is kept hidden from you.

Disclosure is obviously the most important step, but there are other options that Comcast could take. Instead of cutting users off, it could throttle down speeds once a customer produces a set amount of traffic - The customer still has access to the Internet, but it doesn't take up quite so much bandwidth. While downloading Linux ISOs via Torrent are going to take longer, viewing YouTube and talking on Skype shouldn't be affected by reasonable, but lower, bandwidth caps.

At any rate, if Comcast simply couldn't keep up with the demand, then perhaps they need to consider billing as a pay-as-you-go service. Sure, we did away with hourly billing around when AOL switched to flat-rate service in 1996… but certainly, paying for the service that you use is probably very appealing to the vast majority of people paying $50 a month to do nothing more than check e-mail and Web browse.

Then again, there are other solutions which are probably preferable. Namely - improving the performance of Comcast's existing infrastructure, or adding capacity to Comcast's existing infrastructure. Apparently, though, both those solutions are more expensive than suddenly dropping a few customers from the rolls and engendering ill-will.

By Brian Boyko
Editor, Network Performance Daily

Recently, World of Warcraft released a patch which enabled players to use integrated VoIP chat. Online gaming and VoIP are, in many ways, extremely well matched. VoIP can help with the immersion of the gaming experience - roleplaying characters with voice, coordinating attacks instantly and in real time, being able to more clearly articulate nuance and inflection that could change the meaning of a sentence… not to mention that you'll finally have some good idea of whether or not the attractive blood elf lady that's been chatting you up is a 45 year old guy living in his mom's basement. Of course, that's not always a good thing…

While I don't play WoW, I have found that VoIP has become a crucial part of my gaming experience - though I typically don't like first-person shooters, I greatly enjoy the Battlefield series because of its interactive voice chat. It's very immersive - with your squad leader barking out orders and relaying info to your commander, it - well, it would be tactless to say that it feels like you're a soldier in war, but it certainly feels like you're a kid playing soldier.

VoIP and gaming are particularly well suited to each other for another reason, more technical and esoteric. VoIP traffic and game traffic usually use the same protocol, UDP.

A quick rundown for the non-technical people reading this post: UDP is a lightweight protocol with no ability to check if a packet was received; TCP is more useful for ensuring that all of the data arrives completely, UDP, that most of the data arrives quickly. This is why UDP is used for online streaming media, voice, and of course, gaming, which requires split-second reflexes and precise timing.

And though we've covered converged data and voice traffic at length before, UDP and TCP on the same network at the same time can cause network and VoIP performance problems if UDP isn't limited to a certain quality of service. Imagine a TCP and UDP connection traveling together. TCP will, in order to make sure that the packets arrive accurately, will slow down its traffic when it senses that there's less room in the pipe. UDP, in order to make sure that the packet arrives quickly, will see that there's now more room in the pipe from what TCP vacated, and take up even more room… which causes TCP to slow even further. It's a vicious cycle.

But voice and data traffic both use UDP - which is one of the reasons that even before WoW's addition of VoIP, people were using Teamspeak or Ventrilo to provide their own voice capabilities with their friends, and though there was almost always a performance hit, the fact that both WoW and Teamspeak are UDP-based makes it easier for both application to co-exist.

There are a few TCP applications in most MMORPG games, but most of them are simple ones - things like transferring inventory and IRC-like chat - which typically don't take up a whole lot of bandwidth compared to the data sent through the game or data sent through the game's VoIP. One thing that IS TCP-based is the downloading of patches and game updates - there are non-technical reasons, such as game balance, that contribute to this, but just about any online game will stop play while you're downloading the patches, rather than downloading the packages in the background while you play. My best guess is that this is partially because coding simultaneous play (UDP) and data download (TCP) is much harder than coding simultaneous play (UDP) and VoIP (UDP.)

One exception to the rule that games must use UDP is Second Life - that MMORPG requires data to be downloaded constantly and accurately, with new items being built. I can't know for sure as I'm not a coder, but I believe this to be one of the reasons why play control (UDP) in Second life tends to suffer so much and objects take a very long time, it seems, to download (TCP).

We'll try to have more technical details on WoW's VoIP rollout later in the week.

by Brian Boyko
Editor, Network Performance Daily

I once made stew. Once.

As it turns out, I'm a horrible cook. Partially because my thought process was something along the line of: "Hmm… we don't seem to have any browning sauce. What do we have that's brown?"

As it turns out, soy sauce? Not so good in a stew.

I made enough of this stuff for three people, and inflicted it on my roommates. Let's just say that despite the heat being over 98 degrees in Texas, the atmosphere in the apartment was much cooler for a little while…

We all cook our own meals separately now.

You know what, I probably could have avoided that if I had actually tasted the food before I served it to my roommates.

Now watch as I take that almost totally unrelated anecdote and tie it into the NetQoS VoIP Monitor launch today. Abracadabra!

(continued…)

Continue reading "VoIP Monitoring: VoIP without monitoring is like cooking without tasting." »