Established product companies are often frightened of open standards. There are four common approaches to dealing with the threat that an open standard might hurt your own proprietary product.
- Firstly make the first move and establish your product implementation as the standard. Phone.com did this very successfully with the WAP 1.0 standard many years ago and it drove a period of market dominance for them.
- Secondly, engage with the standard definitions process but ensure that it moves slowly enough and in the right direction so that you don’t get caught out by new products from competitors being compliant before you.
- Thirdly, and it is perhaps a variant of the second, engage with the standards process but with the hidden intention to completely screw it up. I could cite examples of this but my legal friends, of whom I have none, advise against it.
- And lastly, from a lofty position, try to dis the whole open standard activity as being (a) too slow, (b) unlikely to deliver, (c) liable to produce a horrible Frankenstein compromise of no use to anyone, or (d) going to produce an implementation greatly inferior to your own proprietary approach.
I think in the case of SDN we’re seeing all of these approaches demonstrated quite nicely. What interests me at the moment though, is why there isn’t an open standard for WAN Optimization. The conditions are right for it: it’s a well established technology, used very widely, and the key mechanisms (compression, de-dupe, protocol manipulation, QoS) are all well understood and implemented in broadly similar ways by each vendor. It’s also too expensive! Customers get locked-in; some of the vendors are notoriously high-handed and arrogant; plus most network admins just want to turn it on and forget about it.
Congestion Management
Let’s think of it by analogy with another component in the comms stack – congestion management. Every IP stack ships with an implementation of the RFCs concerning windowing. For example; how wide, how quickly it should be opened, when to back-off and close the window etc. There is a dominant implementation (Reno) and alternatives (for say long thin networks such as satellite hops) but you don’t pay for them.
So why not make WAN optimization a native part of the IP stack? Why doesn’t Debian or Redhat ship with WAN optimization built in?
Well I think the problem is currently that no-one has stepped up to cover the cost of doing this. It’s not an easy technology to develop – at Replify of course we know this first hand. There is some open-source activity in this area – it’s called Traffic Squeezer. It’s admirable in many ways, but it doesn’t have de-dupe, and that’s the hard bit that adds the biggest benefit in many important scenarios.
Riverbed Technology
A large SD-WAN vendor like Riverbed isn’t going to kill off a big chunk of its own business by donating its de-dupe technology to the Linux community. (Or at least not until it decides that method 1 in my first list might be a good move.)
We, at Replify, can’t afford to donate our technology to the community either – we’ve got investors and employees to consider. However, there are companies with the resources, clout and motivation to make something happen. Say you’re a provider of open stack technology, or a mobile handset OS provider, or a mobile handset manufacturer, or perhaps a comms equipment vendor (other than Riverbed) or a PaaS or IaaS vendor – you can get first mover advantage, hurt the competition, enhance the ecosystem and improve the end-customer experience by buying or building the technology and making it freely available and driving an open-standard around it. It’s a guess, but I think we could see something like this begin in 2014.
Footnote – caught a friend wearing a Samsung Gear smart watch recently. Principle function seems to be that it tells you how long until you need to recharge it.
You can try other SD-WAN vendors for yourself or why not try Replify?