Monday, January 29, 2007
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" »
Friday, January 26, 2007
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?" »
Thursday, January 11, 2007
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" »
Wednesday, January 10, 2007
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." »
Wednesday, January 03, 2007
By Ben Haley
I’m a developer for NetQoS, and I’ve been mulling over the idea that Cisco is planning to take the IOS in their routers and break it into different modules, which they can then provide separately. As a developer I am always interested in architecture, but as a customer do I really care how the code is implemented? After all, I buy a router to direct traffic. My main interests are that it does this reliably, quickly and for a reasonable cost. What difference does it make if the IOS comes feature-by-feature or in a single package deal? In this case I believe the change will be very positive.
The IOS is the Internet operating system for the router. Everyone tends to think of the router as a piece of hardware you plug in, but it’s really a specialized computer that has an operating system on it that can be tweaked to do different things. Every switch and every router has some type of operating system built into it. In fact, people have been able to figure out how to install Linux on a few models of consumer routers and add new capabilities.
Moving to a modular system provides some interesting ideas. For IT administrators, it might increase the cost, or if relatively few features are needed, save money. (Cisco, I think, tends to make money on the hardware, not on the software.) Either way, it’s an interesting concept to say “How would you do this, and what would be the impact?”
(Continued...)
Continue reading "Thoughts on Cisco's Modular IOS" »
Monday, December 18, 2006
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?" »
Wednesday, December 13, 2006
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.
Tuesday, December 12, 2006
By Steven Maercklein and Zack Belcher
While we haven’t had a chance to play with Vista yet, (both of us are on the road all the time and we don’t have access to a lab,) we have been doing a lot of research on the new TCP/IP features of Vista and Longhorn.
We spent some time poring over a document from Microsoft’s Research Asia (the guys who designed the Compound TCP/IP [CTCP] algorithm) and it details how the algorithm works. It doesn’t detail how Microsoft has implemented the algorithm – there are alpha, beta, and gamma values that are tweakable, but it doesn’t go into how Microsoft has tweaked them. It looks like this was a document just to prove that CTCP was feasible and ready to be included in Vista.
It does teach you about the behavior of it and what to expect when seen in action, and it makes reference to the current technologies for congestion avoidance that CTCP is based on. However, there are several features of Vista of concern to those involved in network performance.
(Continued...)
Continue reading "Vista's TCP/IP Promises and Perils" »
