Traffic Squeezer Project Road Map

Release - Pre-Beta (Prototype Version)
The current release is the Traffic Squeezer pre-beta which this new series started as one can see in the above time line. This release is far more stable than the old releases. As well it incorporates a light-weight Application and refined TS Kernel Core. It has also been provided with a integrated light-weight loosely-coupled new Device GUI.

This new Device GUI is suitable for both standalone installations such as Home users/SOHO/Corporate users. And even scalable for large Network service providers too. For more details about the new Device GUI please refer the section "Traffic Squeezer - Control/Configuration Interfaces" of the Documentation.

Application Objectives:
    * Allows users to configure Traffic Squeezer (both GUI/CLI based)
    * Show the runtime statistics of the same (both GUI/CLI based)
    * Show graph of the periodic runtime statistics samples (only GUI)

Framework Objectives:
    * Any layer of PDU compression (L2 Payload, Transport Layer Payload or Complete frame,
       Refer Traffic Squeezer Documentation)
    * Any software compression algorithm(s) can be plugged
    * Software Level Compression (Kernel Space) or Hardware Level Compression (Refer figure below)
    * Support any third-party compression hardware accelerator cards (Refer figure below)
    * Any Physical Layer Network and its corresponding Data Link Layer

2. Traffic Squeezer - Alpha, Beta
This is the actual production release expected to provide the complete set of WAN Optimization technologies described in the documentation. The core Traffic Squeezer traffic optimization functionality would be done in the kernel space. This would certainly improve the performance. In-order to configure the same,  an user-space configuration utility would be provided. This release can have two flavours of Traffic Squeezer one which works like a Layer-2 Bridge and the other work and completely support Layer-3 IP-based Network routing and can interwork in a IP-based routed network. The runtime statistics of the Traffic Squeezer, configuration and control of the same can be achieved with the user-space application. This userspace application provides both Command Line Interface (CLI) and also a GUI Web based configuration interface. In future it should also support remote configurations through telnet and ssh sessions.

The final Traffic Squeezer architecture is expected to provide a complete FLEXIBLE and MODULAR solution to the end-user, abstracting completely low-level functional operation details. So, this includes a unified look and feel Traffic Squeezer Application and a Traffic Squeezer Kernel Level Framework.

Traffic Optimization in Hardware
The kernel space Traffic Squeezer in future can have a facility of a platform to which any custom Traffic Optimization can be done through any custom hardware. This is expected to make possible with the pluggable driver interface within the Traffic Squeezer Framework.

Whereas, to perform traffic data processing in hardware, a dedicated third-party hardware accelerator card performs the same job. Controlling/configuring the same can be achieved with the existing Traffic Squeezer standard user-space interface.

Doublefish Solutions Traffic Squeezer -  Project Timeline




Here is the Traffic Squeezer historical project progress timeline since its inception. It marks all the major activities/tasks, achievements and project source-code releases which are completed and soon or later if there is anything expected to be completed in the near future.

Powered by:

Release - Pre-Alpha (Prototype Version)
The prototype version of the Traffic Squeezer is the first primitive version/stage to test some capabilities which is provided by Traffic Squeezer. It supports the functionality in the user space also the data compression and frame coalescing done only on Layer-2 frame payload. The objective Traffic Squeezer software is to provide users a better way of creating a compressed and optimized data communication tunnel between two peers through which the L2 frame payload gets compressed. These features are showcased in the Traffic Squeezer first Pre-Alpha version. However this version is still a demo version, the actual Traffic Squeezer usable software would be released from Traffic Squeezer Apha and subsequent Beta versions. Refer Documentation for details.

Traffic Squeezer - Big Picture

TS have been made or designed to remain highly modular. In a bit funny terms something like LEGO bricks.
WAN Optimization the more we discover, we can find its highly creative and yet no single/major technique cant be much standardized.

Hence to achieve optimization sometimes we need to write specific optimization techniques, or else at least we should bring some existing third-party open-source modules under one roof. Linux Kernel already have some open-source modules (mostly they exist for NON-wan-optimization context), TS can make use of them in the WAN Optimization Context, in the Traffic Squeezer Context and so vice versa.


Performance/latency:
TS delivers reasonable packet delivery rates, which is more adequate for a reasonable WAN/Leased-Link existing services.
CPU/Mother-board/RAM speeds are keep improving, for WAN or any moderate speed network-links, we are now at a point that we can do huge data-processing via TS on any basic high-end system.
      
Kernel vs User-space:
One can recollect for example IPSec is all Kernel solution, vs. OpenVPN is all User-space solution. Both have its own advantages and disadvantages.

TS initially some three years back thought to make it all kernel solution, while pre-alpha is built to test some feasibility/prototyping during 2006-2007 in all user-space mode. Later Alpha is the first real TS in Kernel space, whereas pre-beta for now is still all Kernel solution, but soon pre-beta should get hybrid-mode, means optimization-modules should be available in Kernel space, some should be available in user-space.  There can be even cases where-as some very important core optimization-modules should get supported both in kernel as well as user-space. The reason for this weird proposal is that, based on the requirements, vs. Time, vs Hardware vs Use-cases, the users should get more freedom to choose the one which suits them the best.

So this unique architecture is shown in the picture below: