Here's the problem. A user behind a Riverbed Steelhead can't communicate with a server behind a Cisco WAAS. This is nuts! The Application Delivery System (ADS--aka WAN optimization) market is mature enough to fix this. The time has come to standardize how ADS technology works so enterprises can build multivendor solutions. We have done this with every other network technology. Why should ADS technology be different?
Think about it from a practical standpoint. If your company acquires another company and both companies use different vendor's routers, you can interconnect both networks at the IP layer. With modest address management, all users can communicate from anywhere to anywhere. You can then choose to keep two router vendors, or migrate to a single vendor over time.
But if the merged companies use ADS technology from two different vendors, you can't interconnect the two worlds AT ALL! Dual-ended (symmetrical) ADS solutions are completely proprietary, and how they work is a big trade secret shrouded in marketing mumbo jumbo.
ADS solutions are very effective and clearly needed. But if all traffic from a remote site is treated by one vendor's ADS box that colors it say, "blue," and the other vendor's solution colors all its traffic "red," you must never let blue and red mix. Even though you can mix the traffic streams in the routers, you can't mix them now--period. This makes integrating the two networks a long protracted complex ordeal.
This incompatibility also applies to other situations such as when you need to connect with business partners or transition from a legacy ADS vendor to a newly selected vendor. We predict that this will become a big headache for the ADS industry, and will limit market growth.
Peter called publicly for an interoperability standard in an article back in September 2006. This new standard can be simple and build on successful precedents. We think it is a form of session protocol, which has the two ADS machines negotiate what they support and how they choose to handle the traffic between them. It starts with a clear definition of ADS functions, and each box can say "I do that" or "I don't do that." Features not supported by both devices will not be turned on. Features that are supported can be negotiated as appropriate.
Many of the features used by ADS vendors are in fact common and sometimes exactly the same--like using GZIP for dynamic TCP content compression. Vendors that want to keep a particular feature secret can put it on the list of features that no other vendor box can support. But in such a case, at least two companies with products from the same vendor can communicate. This is not rocket science--it is a matter of market will.
The economic downturn, the need for enterprises to be more flexible, and plain old common sense, will force vendors' hands. We call on the vendors to voluntarily lead the charge and address this issue responsibly, rather than stonewall.
The Leader in Network Knowledge
Tell Juniper and RiverBed to
Tell Juniper and RiverBed to make their product brain-dead so they can talk to Cisco. Funny, this is the exact same thing that made Cisco, its proprietary protocols and mechanisms like IGRP, EIGRP and CDP to name a few.
You guys should spend more time looking at how OTHERS actually implement their technologies, there is more to this then Cisco's implementation. How do you keep the Juniper internal data dictionaries in sync on both sides of the link when it isn't Juniper? I am not talking about a cache, but a data dictionary that has grown over time.
Maybe you believe many of Cisco's features are common to other vendors, but really what do you guys know about Juniper? They do not use GZIP at all, anywhere. Juniper should implement GZIP because Cisco picked it for their compression algorothm?
Juniper also uses meta-packets for their TCP Optimization, turn that off and you might as well send it over a non-compressed link.
When pigs fly
I disagree that ADS boxes from different vendors need to standardize. Although GZIP is common for compression, the algorithms for many of the other features from the different vendors are dissimilar. There are a lot of code changes being made by all vendors to improve their products. Supporting a multi-vendor ADS environment would be near impossible in an enterprise environment. IMHO I believe you pick a single horse and ride it. At least you know who to call for support.
Leave The Standards Bodies Out Of It
If you try to standardize WAN Accelleration, you will kill the technology. Optimization will be lacking and it will not be able to adapt to the ever growing needs of networks. Lets face it, Standards bodies are too slow...
Apples and Oranges
I'm not sure I agree with your point in this posting. WAN optimization is not "just" data reduction, and even if it were so, the different players all use different methodologies in key areas, making the interoperability suggestion a little unlikely. To me what you are suggesting is somewhat like comparing gas and electricity. I can power my heating with either. I can power my refrigerator with either. I can cook with either, but if I buy a house with electricity and I have a gas cooker, I'm stuck. I can't buy an adapter to fix it because they are different.
WAN Optimization is much more than a few data reduction technologies that can be forced together!
A bad idea since 2006
First things first, it's not ADS. Nothing is delivered by these boxes, they simply mangle the traffic. It's like calling cars 'Pizza Delivery Controlers'.
Then, why would you want to learn, manage and maintain another set of different vendor's boxes - just because they can interact? And they'd interact worse than two of a kind, fingerpointing included. Those few mergers are surely not the business case for rewriting their code, they won't even talk about that. Wait and you'll see how long a proper integration of Paketeer into Bluecoat will take, and it's only two out of roughly ten. Contrary to routers' basic tasks, WTS (WAN traffic squeezer) boxes :p try to be different from each other, not harmonized. Your prediction is easily wrong. Having to replace a vendor's equipment is growing the market, not shrinking.
Yes, if you have a merger of equal parties, you have to live with it or get rid of one. So what?
They are usually dumb tactical boxes on both ends anyway, so you better go get a replacement for both, with strategic capabilities. Well, let's call them PWMs, Proprietary WAN Manglers.
WAN Optimisation Interoperability
I get a warm feeling when optimisation just works between products from a single vendor. Interoperability? I wouldn't like to be the person at the coal face responsible for actually getting it working...
Bend over and grab your WANNY
WAN optimization. When streaming media was the rage pre-dot-com implosion, it was called edge shaping. Now it's known as WAN optimization. Are IT operations that far out of control that it requires a piece of hardware to perform traffic management. So much responsibility, so little authority.
Everybody is competing with everyone else for resources. Whether oil, coal or bandwidth, the many are hungering for more. Why can't everyone just have unlimited bandwidth? Because the means doesn't equal the end. More doesn't mean better in terms of productivity or bottom line results. Does an SLA measure bottom line contribution? Nope. It's only relates uptime and delays.
I say to everyone "Expose your WANNY for the world to see!" Show everyone you're equipped to perform naturally and are not dependent on third party products. Show the world you're not stricken with Traffic Dysfunction (TD). Be proud to manage your WANNY the old fashioned way. No acceleration for me!
Post new comment