By Nathan Bragaw
Business Development Manager, NetQoS

NetQoS European Tech Rep. Peter Frame and I made a trip to Moscow last month to attend a network management event hosted by our new Russian partner, UNICORNS. I thought I'd share a few observations from that trip.

First, the obvious: Russia is cold. I was born in Maine and been in Minnesota in Winter, but Russia, complete with snowfall and brisk wind qualifies as the coldest place I've ever been, and that includes Minnesota in Winter. On the plus side, the food is fantastic - I didn't realize I liked borscht until I ate at Taras Bulba on Petrovka Street - wonderful Ukranian and Georgian food.

It was clear from the wonderful work our local partner, Boris Goldshteyn, did with getting some of the biggest companies in Russia to attend our first network management event in the country that the Russian economy is in full throttle.

I am always fascinated by how different cultures and environments change the needs of our customers. In Russia, it's not that their network performance problems are any different. Instead, they are facing the same problems, like VoIP performance and WAN Optimization difficulties, but they are moving at a faster rate. This is largely because they are not confined by the fiscal restraints that companies in the U.S. face due to the fallout of the dot-bomb era. Companies in Russia want to invest in technology but are challenged to ensure that the technology they seek will meet the needs of their business. The network engineers we talked to there are looking at massive growth, the push for more current technology, and demands for understanding application performance over their networks.

What differences in culture and environments have you found when working on multinational IT projects? Feel free to tell us about them in the comments section of this post.

Submit Your Network Performance Management Resolutions for 2008 by January 3rd and Win a Nintendo Wii, TomTom or iPod

Over the past year, Network Performance Daily readers have submitted some of the best ideas and fodder for blog posts. We’ve written about everything from IT politics in Fingerpointing, Frustrated Network Engineers, and the Application Performance Blame Game to technical challenges in Echo In Voice over IP Systems, and the difficulties in changing behavior in God Help the Help Desk.

Continue reading "Get Your Network in Shape for 2008 With the Network Performance Daily Reader Contest" »

We’ve been blogging with excerpts from our new VoIP Performance ebook here on Network Performance Daily. Today, Brad Reese gets into the game with his own advice on monitoring VoIP performance using Cisco NetFlow and IP SLA in a story on his Cisco Subnet blog called Are you Taking Advantage of NetFlow and IP SLA?

Brad quotes NetQoS CEO Joel Trammell on the subject. According to Joel, “the number one killer of voice traffic is network latency and jitter. Latency, jitter and packet loss cause poor audio quality and dropped calls. Latency caused by overloaded call managers or network congestion can be a major cause of poor VoIP performance."

Continue reading "Cisco IPSLA and NetFlow Help Network Managers Monitor VoIP Performance" »

NetQoS customers are in for a powerhouse educational event next year. The newly revamped NetQoS Customer Symposium is slated to be held April 20 – 23 at the Barton Creek Resort in Austin, Texas. We’ve completely redesigned the agenda to accommodate lots of new network performance best practices, tutorials, and hands-on lab time. We’re also signing up some big name speakers and counting on Dr. Jim Metzler, again this year, to dazzle us with thought-provoking new findings in the area of Application Delivery. If you’re interested, follow NetQoSLive on Twitter to track new developments and speakers as they sign on.

Based on lots of great customer feedback, we’ve expanded the conference from three to four tracks so that attendees have more options. And, we heard you loud and clear: 2008 will be all about network performance best practices. A “birds of a feather” session has also been added to the agenda so you can discuss the topics that interest you the most in a focused group. The NetFlow® training has been condensed to a four hour boot camp, allowing you to hone your traffic analysis skills in a shorter amount of time. As always, you will receive extensive training on NetQoS products with new topics on WAN Optimization, Packet-Level Forensics, VoIP Monitoring, and others.

Continue reading "Shaking Up Network Performance Training and the Annual NetQoS Symposium. Follow the Developments on Twitter." »

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

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.

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

My roommates and I have been chosen (if we choose to accept it,) to be a Nielsen family. And while, at first, I was thrilled to finally get the opportunity to stand up and be counted (I'm a fan of more cancelled series than I can count - Firefly, Brisco County Jr., Wonderfalls, The Critic, Futurama, Studio 60 on the Sunset Strip, Arrested Development, Farscape, The Tick, Justice League Unlimited…) it got me thinking about how, exactly, Nielsen is going to get accurate data on their version of "network performance."

First of all, my "Nielsen Family" consists of three roommates, including myself, who share a four bed, four-bath condo. I've never seen Patrick watch television. Ever. Mike supposedly watches TV but I've never seen him actually pay attention to it - preferring to leave it humming in the background to help him concentrate while he plays Warcraft III or Diablo II.

As for me, well, that's the stickiest of wickets. I own a TV but I only use it for my PS2 and Wii hookups. While Nielsen can track what people watch on TiVo brand PVR boxes, I'm not sure they'll be able to track my setup, which consists of a P4 Dell repurposed into a MythTV on Ubuntu box. The MythTV box connects directly to a business-class projector, but I end up using it mostly for DVD movies, YouTube, and downloaded videos. Even when I watch MythTV recorded movies, I usually end up doing so from my bedroom, which can access the MythTV box and stream the videos (and live TV!) over the LAN in the condo.

(Continued...)

Continue reading "Another kind of "Network monitoring,": Looking at the Nielsen Ratings." »

The big problem with WAN Optimization and Application Performance Monitoring was that there simply wasn't a WAN Optimization solution on the market that preserved end-to-end performance data, nor a monitoring solution that would work in an optimized WAN.

This problem has been solved.

At Cisco Networkers in Anaheim, NetQoS gave a presentation to hundreds of attendees to make the announcement that we've been working with Cisco to develop a management interface for accurate end-to-end application response time measurement that works on optimized networks. (In addition to the people mobbing our booth, John Chambers, CEO of Cisco Systems, stopped by for a chat and review of what we do.)

Through integrated software on Cisco Wide Area Application Services devices (WAAS), TCP header information is exported to NetQoS SuperAgent (an end-to-end application performance monitoring module) before optimization occurs - preserving that information. Finally, IT organizations can accurately validate the results of WAN Optimization deployments.

(Continued…)

Continue reading "Tracking The Optimized WAN: NetQoS Integrates with Cisco WAAS to Deliver End-to-End Application Response Time Reporting for WAN Optimization" »