By Ben Erwin, Product Manager for NetQoS Performance Center 3.0
& Steve Harriman, Vice President of Marketing at NetQoS:

We've recently held a Webinar to discuss NetQoS Performance Center 3.0. We had a Q&A session there and we would like to reproduce some of the questions attendees asked about NetQoS Performance Center 3.0, and the answers we provided. We also plan to answer the questions we couldn't get to during the Webinar on this blog by the end of this week.

(Continued...)

Continue reading "Q&A on NetQoS Performance Center 3.0" »

By Brian Boyko

Back in November of 2006, (which seems like such a long time ago,) Network Performance Daily published a column by Carol Schiraldi about "why enterprise developers use Java and game programmers use C++."

We published this for a number of reasons - but the main one was that typically, enterprise developers are programming for function first, reliability, second, and performance over the network, if it's even considered at all, is a tertiary thought.

What this means is that applications, developed originally for the LAN environment, often take up valuable network resources unnecessarily when placed into a WAN environment.

[Full disclosure: NetQoS sells network performance management software which diagnoses problems like "chatty apps," and we want you to buy them. Anyway…]

But one area where this isn't a significant problem is in game development, which was the thesis of the original column. Game developers, who realize their games have to perform well over the Internet, typically build with performance in mind first.

This was confirmed when we had a chance to talk to Timothee Besset, a game developer at ID Software, developers of the famous Wolfenstein, Doom, and Quake series of games. Here's what he said about this issue:

(Continued…)

Continue reading "ID Software Developer Timothee Besset on Network Performance in Games" »

By Brian Boyko

If you spend some time poring through RFC documents (something I don’t recommend for the 99% of the population that is still sane) you’ll find tons of improvements, modifications, case-specific optimizations and alternatives to TCP, the workhorse of networking transport protocols since the 1970s.

Seth Noble, President and Founder of Data Expedition, Inc., believes that he can do one better. His company claims that their proprietary transport protocol, MTP, for “Multipurpose Transaction Protocol,” provides a scalable alternative to TCP that uses bandwidth more efficiently. According to Mr. Noble:

“TCP's 1970's data model makes dealing with this problem more difficult than it needs to be. TCP was created with the assumption that packet loss would "rarely" occur, and so it is rather fragile in our modern, congested networks. A lot of very smart people have tried for many years to patch TCP and help it cope, but it still carries its 30 year old legacy with it.”

“MTP/IP was designed from scratch to operate in congested environments where packet loss and other network problems are common. As a result, MTP/IP does an exceptionally good job of quickly AND correctly identifying whether or not data has really been lost and then recovering that data with little or no disruption.”

(Continued...)

Continue reading "Proprietary MTP: an alternative to TCP?" »

By Brian Boyko

"Jesus has come back, and he's a phone now."

The Apple iPhone might not be the second coming, but it will certainly be popular. Already the Web is being inundated by speculation, information, mis-information, rumor, innuendo, and anyone with an opinion on Apple writing about the iPhone.

So we thought: Why buck the trend?

The truth is that when this device comes out, many people are going to buy the iPhone, they will use it at their jobs - including those in a corporate IT environment - and that means it is going to become the responsibility of the IT manager.

(Continued...)

Continue reading "Why Apple's iPhone means more work for the IT department" »

by Jeff Hicks

Voice over IP (VoIP) is a hot topic in enterprise networking - mostly because it's a challenge. In implementation, VoIP employs a number of different protocols, and has a unique set of performance requirements that make it a challenge for any data network. Examining VoIP protocols should give someone a basic idea of the performance requirements that VoIP places on the network.

First, there's call setup, which sets up everything needed to make the telephone connection between the caller and the recipient (or “callee”). This requires protocols that enable dial tone, number lookup, ringing, and busy signals before the call even occurs. In addition, the call setup protocols handle things that happen after the call - any resource cleanup and statistic reporting.

Call setup protocols use either TCP or UDP to transfer data during the setup and takedown phases of a telephone call. The messages are sent back and forth between the caller, recipient, and call server using well-known ports. For calls that travel between the VoIP network and the Public Switched Telephone Network (PSTN), the call server will converse with a VoIP gateway using the call setup protocol. There are many different call setup protocols, some standardized and some proprietary. Let’s discuss a few of these.

(Continued...)

Continue reading "VoIP Protocol Basics, and Why VoIP Consumes More Bandwidth Than You Might Expect." »

Prof. Christopher Yoo, Vanderbilt University School of Law

Professor Christopher Yoo joined the faculty of the Vanderbilt University School of Law in 1999, and his research focuses primarily on how technological innovation and economic theories of imperfect competition are transforming the regulation of electronic communications.

In addition to clerking for Justice Anthony M. Kennedy and working at the law firm of Hogan & Hartson under the supervision of now-Chief Justice John G. Roberts, Jr., he has also published "Network Neutrality and the Economics of Congestion" [PDF] in Georgetown Law Journal, and "Beyond Network Neutrality" [PDF] in the Harvard Journal of Law and Technology.

Thanks to Network Performance Daily for giving me the chance to discuss some of my ideas and to the various readers on Network Performance Daily and Slashdot.com for their comments. The comments suggesting that QoS and optimizing networks have nothing to do with network neutrality are a testament to how much the network neutrality debate has changed over the last year and a half. For example, the network neutrality Policy Statement issued by the FCC in August 2005, which remains the focus of the network neutrality conditions in the AT&T-BellSouth, Verizon-MCI, and SBC-AT&T mergers, it focuses on providing differential service on the basis of application and devices as well as content source.

(Continued...)

Continue reading "Net Neutrality: Professor Yoo Responds to Comments" »

Art Brodsky, Communications Director of Public Knowledge

This article continues our series on Network Neutrality.

We asked him to share his thoughts on Net Neutrality with us.

Net Neutrality, as we [at Public Knowledge] understand it, would return to communications law and regulations the concept of non-discrimination. This has been part of communications law since the 1934 [Communications] Act [PDF], until it was partially repealed, in essence, by the FCC last fall, for high speed services.

What we're trying to do is make sure that the carriers, whether they be telephone, cable, broadband-over-power-lines, etc., aren't in the position of picking "winners and losers," substituting their judgment for those of the customers.

(Continued...)

Continue reading "Network Neutrality Debate: A case for Net Neutrality" »

For more information on this topic, you can download our Tech Brief on Cisco WAAS, available here

by Steve Fulton

Users expect a ubiquitous and instantaneous network, as well as consistent application performance. This, combined with a proliferation of business critical, Web 2.0, (and recreational) applications that consume precious WAN bandwidth, forces IT to get very creative in squeezing more performance out of existing infrastructure.

Hence the red-hot market for application acceleration and WAN optimization products that address WAN performance problems caused by latency, congestion, and applications (such as WAFS and CIFS) that were designed for the LAN and now have to traverse the WAN due to data center consolidation.

Cisco shook things up in late 2006 with the introduction of WAAS-short for Wide Area Application Services-technology that is transparent to the underlying network infrastructure. According to Cisco, WAAS combines WAN optimization, acceleration of TCP-based applications, and Cisco's Wide Area File Services (WAFS) in a single appliance or blade.

WAAS addresses problems related to traffic congestion that need some sort of optimization done at the branch. It complements Cisco's Application Control Engine (ACE), which is a data center optimization product that integrates server load balancing, application security, and unique virtual partitioning capabilities.

(Continued...)

Continue reading "WAAS Up with Cisco's WAN Optimization Initiative?" »

by Jeff Hicks

There's a number of reasons why a company would move to VoIP. Generally there's been some component of cost-savings - it may be in regular long distance savings, it may be in hardware cost savings (versus a PBX system), it may be that you only have one network infrastructure to deploy and manage.

But it's interesting how in the past couple of years, costs have become less of a factor in the decision process. Long-distance rates have dropped, so the cost factor is not quite as pronounced as it used to be, especially considering short-term rollout costs.

(Continued...)

Continue reading "VoIP Traffic Isn't Just Normal Traffic" »

by Nathan Bragaw

We just entered into a strategic partnership with Network Instruments. Their GigaStor appliance captures and stores all the packets traveling networks for historical packet-level analysis. Our SuperAgent identifies the source of performance problems, application, server, or network, and isolates when and where they are degraded. Together, the products can monitor large networks, isolate performance issues, and provide packet-level analysis specific to the problem.

For example, this allows an engineer to identify a network that is showing slow web performance. The engineer can then drill down to a packet capture that includes network traffic 30 minutes before and 30 minutes after the event. This capability is changing the troubleshooting capabilities by replaying network traffic prior to the issue occurring. It's like having a TiVO for your network.

Engineers get an alert from SuperAgent, identifying the time and location of a network problem. Then you go into GigaStor and sort through the traffic to identify the root cause of the problem. We’re pretty psyched about GigaStor’s ability to reassemble packet streams to recreate e-mails, web pages, IM sessions and VoIP calls.

We call it Retrospective Network Analysis, or RNA for short.

We should have the products completely integrated sometime in the next six months or so. We’ve already started selling Network Instruments’ GigaStor products through our sales team and our Web site.