There's no denying that WAN links, although less costly than in years gone by, still form an expensive part of a distributed corporation's network. Peribit's range of sequence reducers improves the efficiency of WAN transmissions, allowing the network manager either to (a) get greater bandwidth from an existing link; or (b) reduce the speed, and therefore the cost of links without a loss of performance. We looked at two of the devices in the Peribit range. The SR-50 would typically sit in a central office, as it can handle link speeds of between 256Kbit/sec and 45Mbit/sec. The SR-20 is aimed more at the branch office, as it works with links from 128Kbit/sec to 2Mbit/sec. Speed upgrades are done simply by entering a new licence code, incidentally, there's no hardware to swap.

Although there are plenty of devices that can compress data for more efficient transmission over the WAN, the SR range takes a more clever approach, watching the data as it passes and retaining common byte sequences in memory. If it recognises a byte sequence, then instead of passing across the WAN, it instructs the remote device to retrieve it from memory. As time goes by, the devices build an increasingly effective list of common byte sequences and, in our lab at least, similar clumps of traffic were sent, more and more efficiently, and in shorter and shorter times (presumably as an increasing number of similarities was found among the data being transferred).

TCP acceleration
Along with this Molecular Sequence Reduction (MSR), as Peribit calls its data reduction technology, the SR range provides a whole lot more. At the top of the list is Packet Flow Acceleration (PFA), a concept that's transparent to endpoints but which reduces the latency of WAN links and gives a performance boost particularly to short-lived sessions such as Web Service calls. When a local SR sees a TCP connection request, instead of passing it over to the WAN, it responds with the appropriate acknowledgment, and tells the SR at the remote end to do a "proxy" call setup with the destination machine. The SRs then sit between client and server and handle the resulting sequence number mismatches. Because the TCP connection request was dealt with locally, the actual meat of the transmission can start much faster than would have been possible had it had to wait for the connection request to be acknowledged by the remote server.

Although you can theoretically let the unit "reduce" everything that goes through it, you can also apply some QoS parameters. The most coarse is to make the decision to reduce only certain traffic types and to pass through other types unmolested, or you can use the SR's application-level capabilities to apply different priority criteria to different types of traffic, depending on your business's particular requirements. The SR has an in-built set of "known" applications, but adding your own is a simple case of defining IP addresses/ranges, port numbers/ranges and/or URLs. Incidentally, although the SR only optimises the flow of IP traffic, everything non-IP is passed through unchanged, so it won't break your antique DECnet world or your AppleTalk zones.

When you install the units, you do so with them turned off. The SRs sit in line with the network routers and when powered off, the ports on the back become simple pass-through connectors. You connect the devices in line, make sure the network is still up (which it will be so long as you used straight-through cables to connect the router to the SR) then power up the SRs. Once running, you can adjust the MDI/MDI-X switches on the back of the SRs if required to make the link lights come on. The reason you do all this is simple: if the device fails completely, or the internal software decides that a fault has developed, the SRs switch off-line, the network ports drop back into pass-through mode and your WAN link is still up (albeit without the SRs' performance enhancements). Depending on the model, you either configure the unit's IP address through buttons and an LCD display on the front panel, or via a serial connection to the console port on the back.

Ease of management
Management of the units is via a superbly designed Web (HTTPS) user interface, though if you have a number of units and you want to distribute common settings to a number of units, there's a central management tool that lets you do so. The GUI covers setup, administration and graphical reporting, as well as providing the ability to export raw data for offline analysis in a Peribit-supplied Access application (which produces graphs looking pretty much like the ones in the Web GUI). Via the GUI, you define one station as a "registration server" and point the others at it; the registration server co-ordinates the interchange of low-level information to prevent a clump of devices all shouting the same stuff at each other over the WAN.

Although the units will intercommunicate so that each knows the others' local subnet addresses, you can also add extra information by hand (e.g. the addresses of distant subnets that the units wouldn't necessarily know about), as well as allowing them to listen to RIP/OSPF broadcasts or even to interrogate a Cisco router to pull out routing table information. The setup process is very easy, and once the devices have found each other the status screen in the GUI gives excellent clues as to what's wrong if something isn't quite working properly.

The SR's approach to WAN traffic reduction is one of those concepts that makes you think: "That's obvious - why doesn’t everyone do it". To its credit, though, the company has not just put together some boxes that remember byte sequences, but has instead developed a complete package that combines this novel idea with all the right peripheral concepts such as QoS, compression and reporting. The GUI lets you do all but the most esoteric configuration tasks (there's a command line interface you can use, either via the GUI or through SSH) and yet it's clear and straightforward (we had a two-hour briefing from Peribit, and once they'd left we were able to build our review setup from scratch without the need to RTFM once).

The benefit that the SR range gives you is, fairly obviously, based on the nature of the traffic flowing over the WAN. The average company is likely to see some benefit, however (the benefit in our test network, for example, varied between a few percent and 80 percent, although the latter was the result of a deliberate attempt to send identical lumps of data repeatedly). Along with the performance improvement, though, is the bonus that the units are deliberately designed so you don't have to reconfigure anything on your network to slot the SR in (so although it has an IP address for management, you don't have to allocate addresses to the ports for traffic passing, which means no inventing new subnets or reconfiguring your network.


Units can operate in monitor mode, which means that before activating them, they can watch the network and report the performance improvements that would be achieved by deploying them across the network. Also, Peribit can supply a Windows application that performs a similar function, again to allow the prospective purchaser to evaluate the units' likely usefulness and ROI period.