Network and Telecom Strategies Blog

Handling Poor Application Performance over the WAN

Posted by: Eric Siegel

It's the end of my writing quarter, and I'm putting the finishing touches on a paper for management about WAN performance optimization (also called WAN Optimization Controller [WOC]) technologies.

That reminded me to make a note that WAN performance optimization isn't always the best solution, although I do think it's great! (See, for example, my previous blog entries "Final Catalyst WAN Performance Optimization Notes" and "Be a Hero! Cut costs to Zero!"; there are others.) (And, by the way, Catalyst is a great place to meet your colleagues! So let's put in an advert for them: Go To Catalyst!)

Here are some alternatives to WAN performance optimization that should always be considered:

• Application redesign or reselection: In some cases, it's better to replace a few poorly-designed applications instead of trying to alter the WAN characteristics. Backup and file transfer or distribution applications that don't remove long duplicate data strings ("deduplication") or that handle transmission errors or congestion inefficiently are prime examples. The Burton Group report “Designing Applications for the WAN” was written to assist programmers in designing applications properly for operation over the WAN, thereby avoiding the need for optimization. 

• Application remoting: Often called "terminal server" or "Citrix," this solution is best for applications that are tightly-intertwined with some remote service; for example, an application in a remote office that makes frequent calls on a database in the enterprise's central server location. Application remoting can also save money on licensing fees and has other advantages. Application Remoting data flows will probably require network QoS.

• System tuning: In some cases (e.g., inability to use all of the bandwidth in a high-latency path), simply tuning existing software or upgrading to more recent version (e.g., shifting to Microsoft Windows Vista from Windows/XP) can produce massive results at minimal cost. 

• WAN service modification: For some situations, the need for more bandwidth or better network delay or error characteristics is unavoidable or is the most cost-effective solution. In some cases, technology changes (e.g., to satellite from terrestrial links) are also involved. Renegotiation of carrier contracts and changing carriers are also options. 

See the Burton Group report "WAN Performance Optimization Quick Start" to learn about WAN performance optimization, and wait for my new Management Initiative document "WAN Performance Optimization" if you have to discuss things with your management. (As always, if you desperately need it now, and you're a Burton Group client, send me an email and I'll give you a pre-publication copy.)

Please Install Network Taps!

Posted by: Eric Siegel

(I see that today I'm just full of exclamation marks in my titles!)

Anyway...

I have a report coming out in a few weeks, "Network Tapping and Flow Tracing Tools" and a portion of it discusses network taps and "SPAN" (Switched Port Analyzer) ports, which are also called "mirror" or "monitor" ports.

A monitor port is a port on a switch, router, virtual machine processor, or other device that can be configured to copy (or “mirror”) the data from another of the device’s ports or from an otherwise inaccessible data path inside the device. A diagnostic or measurement tool can then be plugged into the monitor port to examine the data flow.

In contrast, a tap is not embedded in network or host equipment. Instead, it's a low-cost physical device that passively, and invisibly, intercepts traffic on a WAN or LAN link. Taps can be electrical, for copper WAN links and Ethernet, or they can be optical, splitting some of the light energy from an optical fiber.

Most enterprises don't install taps; instead, they use the existing monitor ports to connect monitoring equipment and intrusion detection and management equipment. This is a mistake.

While I was talking with tap vendors over the past few weeks, I was struck by how often they commented that enterprises just don't focus on the need for taps. So here are a few reasons that the small investment in a tap infrastructure pays BIG dividends, especially when you have a intrusion incident or diagnostic crisis: 

• Taps do not drop packets. Monitor ports may drop frames, especially under heavy load, because they handle frame monitoring at a lower priority than their primary function. This can be irritating, because it always seems to happen precisely when your network is being flooded by a problem or intrusion.

• Taps do not remove errored frames (e.g., short frames, jabbers); the diagnostic tool can see exactly what is on the communications link, errors included. Monitor ports don't see errored frames because they're removed as they enter the switch or router, long before the monitor port sees them. If errored frames are causing congestion, your diagnostic tools won't see them at the monitor port.  

• Most taps can multicast to multiple output ports, allowing more than one diagnostic tool to see the data flows. That's extremely useful! It's wildly irritating to race into a server room with screaming managers on your tail, and then discover that some mystery cable is plugged into the switch's sole monitor port. What does that cable do? If I unplug it, so that I can plug in my trace tool, what is going to break? Aaargh. Time wasted, tracing cables to figure out what is going on. It's much nicer to have an extra port on the tap! 

• Some taps can filter the traffic, decreasing the volume that the diagnostic tool must cope with. They can provide that function without using a network device’s limited processing capabilities.

• Some taps can combine traffic from multiple sources into one output port for the monitoring tool, possibly adding source identification and hardware time stamping to the frames.

Well, there's a lot more about taps and monitor ports -- and about matrix switches, storage, and trace tools, etc. But you'll have to wait for the report! (If you desperately need it now, and you're a Burton Group client, send me an email and I'll give you a pre-publication copy, of course.)

Time to inventory your IPv4 Addresses!

Posted by: Eric Siegel

I see that Mike put up a blog post about IPv6 ("And you think 2012 will be a problem...") mentioning that I'm working on a paper about IPv4 address exhaustion and the resulting need to be prepared for IPv6-only Internet users.

An important consideration for all enterprises is that, starting in 2009, some Regional Internet Registries (RIRs) began to formalize mechanisms for the transfer of address blocks subject to RIR approval. That allows the appearance of a market in address blocks.

The address block market will peak as the IPv4 address shortage becomes extreme after 2012, then gradually decline as IPv6 gains popularity. Large blocks of addresses, which had no financial value previously, will need to be inventoried and appear as an enterprise asset. (Larger blocks will be more valuable than an equivalent number of addresses in smaller blocks.) In some cases, enterprises may re-number their internal networks to create large address blocks that can then be sold.

So, if you have no idea how many IPv4 address blocks you own, or which ones are used, the time has arrived for you to start an inventory. IPv4 address blocks will suddenly have financial value, and you might even want to consider selling them in a couple of years to an enterprise that hasn't planned ahead and suddenly needs IPv4 addresses but can't get them from their ISP. (That won't be YOU, of course....)

By the way, you can talk with Mike in person about IPv6 and IPv4 at the upcoming Catalyst Conference in Europe on April 19-22. He'll be there!

If you're interested, here are some of the RIR regulations governing transfer of IPv4 blocks:

RIPE:

http://www.ripe.net/ripe/docs/ripe-484.html#55

ARIN:

https://www.arin.net/resources/request/transfers.html ("Transfer of released number resources")

http://lists.arin.net/pipermail/arin-ppml/attachments/20090406/b8a75e31/attachment.pdf

APNIC:

http://www.apnic.net/policy/proposals/prop-050

UC Sessions @ Catalyst

posted by: Mark Cortner

I’m looking forward to the sessions focused on unified communications (UC) at our upcoming Catalyst Conference in Prague and engaging in conversations with our clients and other conference attendees. I believe we’ve assembled an interesting agenda; the sessions will examine the current state and future of enterprise UC, identify and analyze what aspects of UC have gained the most traction to date, and provide perspective on how UC can impact your business strategy (and vice-versa).

The agenda will also feature a roundtable session that will feature subject matter experts and leaders representing the application, infrastructure, and service provider vendor communities that are aggressively addressing the UC market. The objective of the track agenda is to share perspective gained from our research on this broad topic area, enabling our attendees to assess their own company’s strategies related to UC with the observations and opinions of the session speakers and roundtable participants. And while the sessions should either challenge or confirm your thoughts on UC, the planned content should also lead to some provocative discussions related to this topic ...

And you think 2012 will be a problem...

Posted by: Michael Disabato

I had a conversation with John Curran from ARIN (American Registry for Internet Numbers) today. You know those folks. They hand out blocks of IP addresses so you can get on to the Internet. Short form: An IP address is the “phone number” of the host (server, laptop, smartphone, cable box, etc.) that sits on the public Internet. These “phone numbers” need to be unique, and we are running out of them. John told me that as of today, we have 560 days worth left. Frankly, I think that’s a tad optimistic, but we all have our opinions. What does this mean to you? Simple.

It’s time to get beyond denial that this is not a problem and start taking actions to connect your organization to the Internet. The ENTIRE Internet, not just those that have IPv4 addresses. Yeah yeah yeah… the IPv6 world is about 1-2% of the aggregate Internet. Today. By the time you figure out what to do, it will be more like 10-20%. Do you want to be the one to explain to your CIO why 20% of your customers can’t reach your web site? Do you think he/she wants to be the one to explain it to your CEO?

Didn’t think so. (Think: Career limiting move)

I’ve given presentations on this before. Eric Siegel is writing another paper on it as I type this. John Curran and Eric will be speaking at Catalyst North America and describing what you need to do to avoid the next Y2K problem.

It’s really not that hard: IPv6 enable your web site, email and other services in that order. If you need help with developing a strategy for that, contact Burton Group. We can help.

Michael

Questions About SaaS network performance SLAs and Diagnostics

Posted by: Eric Siegel

As I initially discussed in my blog entries on 29 January of this year ("SaaS Network Diagnostics" and "SaaS Network Performance SLAs"), the service level agreements (SLAs) and diagnostic plans for Software as a Service (SaaS) are still in their infancy. That blog entry discussed setting up measurement tools to provide SLA key performance indicators and also to assist network operations detect and quickly "triage" any performance problems, assigning the problem to the correct organization for repair.

I've now decided, in light of the increasing interest in SaaS and cloud computing (e.g., there's an entire track on "Enterprise-ready Clouds" at Burton Group's Catalyst Conference in Prague, April 19-22), I'll be writing a report on how to manage the performance of cloud-based applications.

SO....

If anyone is willing to discuss the issue, please add some comments here! How have YOU handled performance issues with your cloud / SaaS provider? What is in the contract, and what happened when you had some performance problems? How did the provider respond?

Learn about Mobile UC at Catalyst Conference

posted by: Paul DeBeasi

Individuals increasingly work from nontraditional office environments and expect to use their mobile phones wherever they work.  At the same time that the mobile workforce is growing, enterprises are deploying Internet Protocol (IP) Telephony (IPT) and unified communications (UC) solutions.  IPT systems provide new capabilities to virtualize communications across the enterprise, breaking the linkage between a user and a single physical telephone. UC integrates many forms of communication such as email, voice, instant messaging, and presence across various hardware and software platforms and also integrates communication into business applications and processes.  Many organizations have begun the process of integrating their various communications applications and services.

Unfortunately, the mobile phone user still largely operates outside of this environment. For most people, the mobile telephone is simply a means to make and receive phone calls, nothing more.  Smartphones—such as the iPhone—may offer additional features such as mobile messaging and calendar synchronization, but they lack the ability to offer mobile users the same access to communications services offered by a desktop phone in their office. In effect, the mobile phone operates outside of the enterprise private branch exchange (PBX) or telephony service.

These mobile users must endure numerous inconveniences that include dependence upon two phones (desktop and mobile), two phone numbers, two voice mailboxes, and two contact directories. When a user is away from their desk, a call to the desktop phone can result in a missed call, voice mail, and caller frustration. Similarly, a call to the mobile phone when the user is busy can result in voice mail, but in a different voice mail system, frustrating both caller and user.   In addition, mobile users do not have access to corporate phone directories and they must often use full 10-digit dialing when calling another employee who may only be down the hall. 

Numerous vendors and service providers are introducing products and services to enable mobile users to access many of the same features and services that previously could only be accessed through a PC or fully-featured desktop IP telephone. The goal is to enable enterprises to extend telephony features to their mobile users, while making mobile users more productive regardless of location.  Some products and services take advantage of the increasing intelligence of the mobile phone, while others insert themselves between the public switched telephone network (PSTN) and users’ various communications services.

If you’d like to learn more about mobile UC products and services join me at the Catalyst Conference in Prague on Monday April 19.  Mark Cortner and I will provide a ½ day workshop on Mobile UC products and services.   Click here to learn more: http://www.catalyst.burtongroup.com/EU10/. 

Cisco + Tandberg, More Thoughts

posted by: Mark Cortner

I recently participated in an analyst roundtable discussion with executive leaders from Cisco and Tandberg to discuss the strategy behind the pending acquisition of Tandberg by Cisco.  The discussion summarized many of the high-level objectives stated in past briefings and press releases, but also added more insight into the benefits the companies anticipate as a result of the acquisition.

In general, the benefits from an acquisition such as this could be derived within one or more dimensions; an improvement in market positioning, acquisition of a critical mass of key knowledge resources, expansion of product capabilities through technology acquisition, and top-line revenue growth. The executives from both companies initially stressed that the people component of the acquisition was perhaps the most important benefit that the combined companies would experience. I agreement with this opinion, I believe that Tandberg will add strong technical, marketing, and sales expertise to Cisco. The addition of Tandberg expertise will enhance Cisco’s credibility with the technical influences and decision makers within enterprise IT organizations.

Cisco’s vision includes high growth for video-based applications, with conferencing opportunities both with enterprise and service provider networks. Cisco reiterated the importance of driving a network effect for video and made brief mention of Tandberg’s Codian MCU. If Cisco and the rest of the industry is successful in driving increased interoperability and in turn, higher utility, I believe when we look back at this value from acquisition the most significant technological/product component will in fact be Codian.
 

Cisco Exits WiMAX RAN Market

Posted by Michael Disabato

In his paper, “Mobile WiMAX: Why the Fuss?,” NTS Research Director Paul DeBeasi downplayed the significance of WiMAX as a 4G development. In spite of Sprint/Clearwire’s efforts, I agree with him and still think WiMAX will be a niche player in the 4G market. One need only look at the number of GSM phones that are backward compatible with the standard and the potential for upgrades moving forward. Evidently Cisco now agrees, as they have announced  it will stop designing and building new WiMAX base stations, instead focusing on the packet core network. This means the $330 million acquisition of Navini Networks in 2007 has been shelved for now, perhaps for good.

The radio network was never where the money was anyway, since the choice of physical layer was all but mooted after the last, large CDMA network operator (Verizon) decided on LTE for its 4G network. However, 4G (LTE and WiMAX) us a packet network for the core instead of circuit switching, and Cisco is the market leader in packet networks.

Over time, your handheld, smartphone, tablet, whatever will be and IP terminal running IP-based apps, including VoIP. Since WiFi and GSM-based networks are MUCH more prevalent than WiMAX, those two will survive, and WiMAX will fade.

We’ll be covering this and other mobility subjects at Catalyst Europe. If you have not signed up for this, go here and register. We have an excellent agenda over a full day to discuss everything from wireless developments to policy considerations. See you there!

Michael

Cisco + Tandberg: A New Open, Interoperable Product Portfolio?

posted by: Mark Cortner

Earlier this week, Cisco and Tandberg provided an initial peek at plans for an integrated product portfolio that will be disclosed following the closure of Cisco’s pending acquisition of Tandberg. In the announcement, the companies stated that they believe that competition and industry expansion will be best served through open standards and interoperability. I recently posted thoughts on Cisco’s release of its proprietary telepresence protocol to the public domain and its intention to propose the protocol as an open industry standard as is an initial step to drive interoperability standards in telepresence. The release indicates that Cisco will create an open architecture that enables greater interoperability with third-party systems beyond "telepresence" systems.

I’m curious to learn how this architecture will deviate from Cisco’s current visual collaboration architecture(s). I agree that one important factor related to industry expansion will be interoperability between vendors in all visual collaboration categories—immersive telepresence, room-based videoconferencing systems, personal systems, and infrastructure elements such as MCUs. The degree of customer acceptance and adoption achieved by video-based solutions will depend greatly upon how each type of solution can interoperate with other systems—from the same vendor and different vendors, both internal and external to the enterprise. I find that enterprise perceptions of video-based collaboration vary significantly, as many are still wary of past interoperability and limitations on system utility. I believe Cisco and Tandberg are on the right track, they realize that without widespread interoperability, the past barriers to video adoption will be difficult to overcome and new growth segments such as personal systems will not reach their market potential ... it will be interesting to see how the "open and interoperable" strategy will unfold and translate into actual product strategy and implementations.