Letters to the editor: “Cisco AON: Fight fire with fire”

Also: DSL, IPTV, Apple

AON and deja vu

When I read Kevin Tolly’s column “Cisco AON: Fight fire with fire”, I had a feeling of deja vu. Six months earlier, I had conversed with Ron Schmelzer and Jason Bloomberg of Zapthink on this subject. My original message to them and personal professional opinions expressed to Mr. Tolly follow:

Cisco’s AON announcement reminds me of the beginning of Microsoft’s XML/SOAP push a few years ago with the emergence of .Net and the joint UDDI proposal with IBM. How? Think of it this way: Hedging against possible loss of desktop/server OS market share (among other reasons), it was a brilliant move toward extending Microsoft technologies out to the furthest reaches of applications extending across the Internet.

Consider this: Along with UDDI concepts, there comes the real possibility of eventually tapping a whole new market: Syndicated software component services that are brokered via UDDI-related downstream registration and payment mechanisms. When it finally becomes reality, enjoy it (free) while you can.

Eventually, I expect software components to be dynamically discovered, attached (bound), consumed by composite applications, priced, and paid for by the consuming application – all automatically, of course.

This model is really no different than the “auto-pay” service that I now use for payments to my various home utility providers (phone, electricity, etc.). Once the ease of use of automatic pocketbook draining becomes the norm, no one will think twice about paying for software the same way. In fact, it will make software project costing a lot easier than it is today.

In the case of Cisco, they are on the inverse side of this value chain in the sense that they seek to enable XML services as they flow through the network infrastructure. But there’s another angle: Collapsing AON-type service enablements into the hardware/firmware will have the effect of creating demand for even greater throughput, similar to how Moore’s Law in CPU development has created demand by allowing more and more software bloat, and therefore, functionality at each layer. This creates and sustains growth in Cisco’s physical infrastructure value and revenue.

My comments may appear cynical, even paranoid, but the IT marketing machine has repeatedly produced such market-hype feeding frenzies in the past, I would argue, and has been doing it again.

The value chain to which I refer is that of the so far highly overblown SOA (read: Web services) market and its related XML-based “structured content” streams, all of which requires brand new infrastructure — still under development — to manage operations and integrity of such data and transactions.

Until this is substantially complete, e-commerce trust relationships cannot reliably develop or enjoy widespread growth under SOA loose coupling technologies. Cisco’s AON will therefore play out as the “FUD factor” of Internet e-commerce enablement. But it’s not just crud FUD; XML-based SOA transaction streams present a very real technical challenge to secure business growth.

Each new technology in the network space is presented by its vendor proponent as something that can be inserted into your existing network, or simply bolted on. But interoperability is no longer the primary consideration, because in practically all distributed network architecture implementations, there are already so many devices and protocols in the pecking order, that adding “just one more” is adding one more unwanted complexity to a company’s engineering and systems management woes.

When a few of us enterprise architects (working for Fleet Financial at the time) met in late 2002 with Forum Systems’ CTO and co-founder Mamoon Yunus, we were impressed with his understanding of the architectural hurdles still ahead for XML (hence upcoming Web services ecosystem) security products. We outlined our concerns on architectural complexity to him at that time. In early 2003, they issued a white paper entitled, “The Need for Hardware-based XML Security” that was prescient in its message about software payloads across the Internet and the specter of continuing buffer overflow exploits. To their credit, Forum Systems produced its XML security offerings in various form factors: hardware (FIPS-hardened server card), gateway appliance (hardened and managed), and server-side software agent. These covered most of our concerns with architecture choices, but of course the jury was still out regarding management of policies and real-time operations (and still is).

In October 2002, I told Mamoon Yunus that I expected his technology to soon be embedded in Cisco and other network hardware devices, because logically that was where it belonged (as a central set of services, not on all the edges). I am still wondering what is taking Cisco so long to see this and simply buy a whole series of vendors to create the reality suggested by the marketing hype of AON. After all, Cisco should not reinvent the XML security wheel.

Just like standalone network devices in 1980s and early 1990s were invented and introduced piecemeal as “one more device” in a linear network chain – then were later embedded into “collapsed backbone” device architectures that still dominate today — there is the same thing just beginning to shake out with respect to XML security and overall operational management. Cisco has the size, presence and clout to become the aggregation point for XML management, but could blow it by trying to do it on its own.

Spencer Day

Enterprise Architecture, Network Computing Group

Bank of America

Boston

Regarding Kevin Tolly’s column, “Cisco AON: Fight fire with fire”: It is understandable that Cisco’s Application Oriented Networking (AON) strategy has been met with what Tolly claims is a lack of buzz.

Cisco positions AON as a network solution for the next generation of business applications, which will be predominantly based on service-oriented architecture (SOA). The WAN implications of SOA-based applications are profound: exponential increases in traffic volume, more sensitivity to network latency, less predictable traffic patterns and increasing difficulty in identifying high-priority traffic. Yet, Cisco’s AON promises little relief.

While AON’s XML processing can offload part of the burden, Cisco’s own literature admits that a key component of AON, enhanced message handling, is “only appropriate for a fraction of the overall traffic.” Why should users bother with an applications-aware network approach such as enhanced message handling when it doesn’t solve the fundamental challenge: too much time-sensitive traffic over too little bandwidth?

Additionally, applications-aware networking burdens users with expensive and time-consuming tuning and debugging of applications for the network, which could take months and then must be redone on a continuous basis as new devices, users or software versions are rolled out.

Ciena believes there is a much simpler approach than applications-aware networking. Why not use the field-proven network techniques being used today to satisfy the high-volume, low-latency traffic of networked remote storage and apply it to XML, Web services, LAN extension and other distributed application traffic? Using applications-transparent networking techniques, users reduce complexity and allow their software developers to continue to do what they do best, and let network users focus on what they do best.

Michael Mullaley

Director, enterprise networking

Ciena

Linthicum, Md.

Techs are not engineers

Regarding Mark Gibbs’ Gearhead column, “DSL techs and favorite tools”: I’ve seen and heard the same comments coming from DSL users since the late 1990s. It’s still the same thing. The network hasn’t changed in that time – or the change has not been universal – and the phone companies are still paying a lot of attention to the people who use the telephone.

Coming from a retired engineer for SBC, those techs Gibbs speaks of are not engineers. They are fully capable of taking care of problems for the customer, and are a lot better at resolving problems than the tech support on the phone – but they only know what they know. Engineers are the guys who put the systems together. As for Gibbs’ perception of the phone network, don’t forget: It wasn’t built for anything more than voice frequency communication originally, and that includes some specifics to optimize that capability. None of which is good for high-speed anything. If you want high speed, you’re better off with the Wi-Fi providers who, I hear, are really expecting to provide wireless broadband for everyone – and soon. My nephew is working with such a company that plans to service a rather large area in Contra Costa County, Calif. In some cases, it will be the only broadband access available that’s designed and optimized for broadband – not voice.

Mike Richardson

Capitola, Calif.

A simpler approach

IPTV revolution

Regarding Johna Till Johnson’s column, “Who wants their IPTV?”: IPTV is evolution. I agree that at first there will not be major changes from what we can get today via cable or satellite, but having a common way to deliver all information (phone, TV, Internet) to your home via Ethernet is huge. This is really the first major step toward convergence of all three of these services. The only thing that will hamper IPTV is multicasting. Due to the way multicasting works, only one telco vendor will be able to send IPTV to your house. This means you still will get only one other option for broadcast TV (SBC/AT&T in my case). The real deal would be adding a service such as Akimbo on top of IPTV. In my TiVo lifestyle, there are very few things that I need to see live – some sporting events, maybe news. This is the real threat to cable and satellite as it makes virtually everything on demand and with no boundaries, just more caching.

Mark Nielsen

Technical architect

ADVO

Windsor, Conn.

Standards vs. practicality

Regarding Scott Bradner’s column, “Apple and the value of standards”: I think it would also be fair to say that standards are not always the best implementation of a particular technology. When one looks at the complexity of X.400 vs. SMTP, or Skype vs. trying to roll your own Session Initiation Protocol-based solution, the issue is not the standard used, but the practicality of the solution.

Waleed Hanafi

Consultant

Singapore