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?" »
Friday, December 15, 2006
Compiled by Brian Boyko
We (and many other experts) believe that there needs to be an industry discussion between developers and networking groups, because it seems that people - at least the people we come in contact with regularly - talk often about how applications designed and tested to run over a LAN perform horribly over a WAN.
Because this dialogue doesn't seem to be happening much yet, we've decided to try to take the initiative and help jump-start the discussion between appdev teams and networking groups.
Despite the fact that this blog deals with network performance, and as such would most likely appeal to IT managers, network engineers, and the occasional CTO/CIO, this blog's earliest success was an article by Carol Schiraldi speaking about games programming. That article made it on the front page of DZone - it's kind of like Digg for developers. While getting a developer audience was entirely unexpected, that article is what convinced us that we were starting to produce some compelling content, and caused us to set our sights very high. Over the past week, we've received over 15,000 unique visitors; which is not bad for a site that has been up less than 6 weeks!
On the other hand, some members of DZone had complained - fairly, in my opinion - that much of what we wrote didn't really affect developers. Although we got back on their front page again with an article by Russell Wilson regarding UI development, DZone has mostly remained a bit aloof to our offerings - and who can blame them. So we asked one of their editors, Lowell Heddings, how we could better serve the DZone community (and by extension, the developer community.) He had this to say:
"My main question for network engineers is... aren't routers boring? =P"
I'm pretty sure he was trying to blow us off. But he's got a point. Aren't routers boring? So I actually posed this question in a company-wide e-mail. Here are some of the best responses:
(Continued…)
Continue reading ""Aren't Routers Boring?" the developer asked." »
Thursday, December 14, 2006
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" »
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" »
