Traffic Squeezer - Traffic Templates  -> Traffic Templating

Traffic Templating is a unique way where the traffic can be matched with dictionary words and could be templated with the most frequently occurring words and can be replaced with template Ids/notations. But the challenge is that this can introduce immense latency in the traffic processing. Hence traffic templating feature should be eventually introduced into Traffic Squeezer step by step. But in contrast the processing power of CPU is increasing and getting cheaper too. Hence one can achieve speeds equivalent with CPU as similar to any dedicated offload acceleration processors of the past !


Traffic Squeezer - Templating feature is released with a very specific set of optimization options and key-words as its static dictionary, but that does not mean its complete. Its all about individual requirements and with respect to each unique deployment. More larger the dictionary, the more larger it the overhead of processing information. Hence a fine balance need to maintained so that we get good data optimization with reasonable amount of processing overhead.

Multi-Lingual options:
If your deployment(s) deal with specific Language more frequently than English, you can customize the dictionary and extensions and multiple languages of your own.


Application Protocol Specific options:
Unfortunately many application protocols are actually (especially in Internet, as well as in private links such as WAN) Human Friendly scripts, use Human Friendly notations, chatty, and for Humans ! They are NOT MACHINE FRIENDLY !!
One can look at the compiled code, which usually produces highly optimized, highly compressed reduced foot-print of a Code programmed in a Programming Language into machine specific Assembly Code.
For example let us look into the HTTP Protocol and HTML Language which is the backbone of internet, every tag, every attribute of HTML tags are bloated, which are easy for humans to understand, code, maintain, and so on, but not really optimized for machines ! And so even the HTTP Application protocol itself. Traffic Squeezer Templating can be applied simply to reduce this foot-print and further can be fine tuned the more frequently used applications.

Compression vs Traffic Templating ?
Its better we dont end up comparing which is better, and which is more optimized. In the context of Traffic Squeezer or WAN Optimization, its all about machine performance and high optimization ratios. The problem with compression is that more bigger the content to be compressed (with possibly some repeating patterns in it) more is the compression ratio achieved. Where as with Templating, its far fairly simple, translate the lengthy content with a shorter notation(s), re-create the original content on the remote end. Templating can be done/applied on one word, one line/sentence, or entire network packet !

We cant expect compression done on a packet which is just around on a average 100-1500 Bytes (assuming its MTU) can provide us effective optimization. But on a contrast Templating feature completely removes more frequently occurring keywords with notations. Which is precise and what is really needed for network packet optimization.

This can be further explained in this picture below:

So now any one can tell, if
       Source Content = File, then Compression is perhaps the best option.
but if
       Source Content = Network Packet, then Templating is or can be highly effective.

What ever is the optimization technique does individually, one can still enable both compression, and templating (and other techniques) and can achieve the best combined overall optimization.


Templating along with Compression:
Combination of both Templating and Compression is tested out. During the trials it is found as long as the data/content is significantly high, it can improve further efficiency of compression, since already most content is already removed. Assume on a average if the user gets 30% compression ratios on a specific traffic type, then upon enabling both Templating and Compression, there are chances to get this improved by 10-15% more on a average. As everyone knows, compression is no different from Templating, but compression does a dynamic runtime dictionary and does pattern substitution. Since the source content itself is stripped via Templating, this should improve compression ratios even further.
Conclusion: More the repeating patterns matched and tagged with Templating, more is the compression ratios one can get.