Compression Depression

Mike Bantick
Thursday, 18 June 2009 05:00

Business IT - Technology

First and foremost is accounting for the failure of any particular Juniper WX box.  When the box is shutdown or fails, the comms path immediately goes into hardware bypass, meaning your traffic (except in some rare failure scenarios) will continue to traverse the network unimpeded.

But this traffic will be uncompressed, and if, as the network engineer, you have saved the company money in paying for WAN bandwidth, you could suddenly be embarrassed as the cheaper, smaller link becomes saturated with data.

Failure of the device can be overcome with some neat redundancy techniques, including a second Juniper box running in stand-by.  Juniper provide a licensing model to cater for this architecture, and it is to be encouraged.

Other considerations include the standard network planning scenarios.

Because each IP packet is re-wrapped and appears to edge routers as simply traffic between two Juniper boxes rather that individualised for different services, the usual niceties of comms design need to be rethunk.

Routing , ACL  planning and QOS are suddenly overwritten by a single stream of routes between two devices.  It is only if you need to cater for traffic that bypasses the compression devices (see below) or for when the devices fail in which case all traffic suddenly becomes ‘bypass;’ traffic that these network configuration items will come into play.

Some traffic such as pre-compressed FTP data may actually come out the other side in worse shape than it went in. 

For example, pre-compressed traffic packets close to MTU sizes that go into a Juniper compression box may indeed exceed the MTU restriction when only very slightly compressed and re-wrapped in a new IP header.  As such, for what concerns it could cause, the packets will then traverse the rest of the network as fragmented packets.

Encrypted traffic will not be compressed, though it is possible for some WX devices to manage SSL tunnels themselves, or in other words, decrypting the data with their own copy of the certificate, compressing and then re-encrypting the traffic for its network traversal.

This of course opens up a whole new area of consideration, that of data security. 

The WXC hard drive equipped devices in particular must be scrutinised in this regard.  Despite having a proprietary disc storage format, the fact remains, that these devices are storing strings of data in memory, and for compression reasons, the longer the string the better.

It is indeed feasible that this data could be read in the clear whist ‘at rest’ travelling through the device, even in a SSL managed network.

For our network, I have made this statement many a time, the Juniper WX and WXC devices are the first real ‘silver bullet’ out-of-the-box solution I have come across in over 25 years in the industry.

In some test results, delivering ideal data, resulted in an effect WAN capacity thirteen times the actually pipe rating.  This got to the point where the mainframe VIPA card (the IP interface) needed to have a software refresh to stop it being overloaded for the first time ever as the WXC requested was able to accept a much greater stream of data from the FTP application (Connect Direct in this case).

This leads me to ponder such services as the upcoming HD movie steaming proposed by Microsoft for the Xbox 360, as well as similar services from other venders.

If the company is able to control both ends of the pipeline, with compression/assembly algorithms, pre-cached, smart enough and fast enough, then delivery of such content is indeed feasible even within environments consisting of restrictive cap limits and broadband speeds.

It works extremely well in a corporate environment, there is no reason the same technology could not translate to the home successfully.