* Forward Error Correction
In the last two newsletters (see here and here) we commented on the fact that data replication was significantly different than other data applications and that it could be negatively impacted by small amounts of packet loss. Today, we’ll talk about ways to overcome the impact of packet loss, talk about the impact that out of order packets has on goodput, and return to a topic that we know is a hot issue for our readers: what functions should be done in a router.
One of the key points of the last two newsletters is that while packet loss affects throughput for any TCP stream, it particularly affects throughput for high-speed streams, such as those associated with multimedia and data replication. As a result, numerous techniques, such as Forward Error Correction (FEC), have been developed to mitigate the impact of packet loss.
The basic premise of FEC is that an additional error recovery packet is transmitted for every ‘n’ packets that are sent. The additional packet potentially enables the network equipment at the receiving end to reconstitute the lost packets and hence negates the actual packet loss. The ability of the equipment at the receiving end to reconstitute the lost packets depends on how many packets were lost and how many extra packets were transmitted. In the case in which one extra packet is carried for every 10 normal packets (1:10 FEC), a 1% packet loss can be reduced to less than 0.09%. This is great, but carrying extra packets if they are not needed is not a good idea – the extra packets are just needless overhead. As such, what is really needed is adaptive FEC whereby the amount of extra packets that is carried is changed dynamically based on packet loss.
Out of order packets do not tend to occur very often on hub and spoke networks and are more common on meshed networks MPLS networks. If too many packets are received out of order, TCP will cause a retransmission of packets similar to what happens with dropped packets. As such, the impact of out of order packets on goodput is similar to the impact of packet loss.
A few weeks ago we published a couple of columns on whether or not WAN optimization should be integrated into the router (see here and here.) The response to those newsletters was quite spirited indicating that this is an important topic to our readers.
In terms of what functionality should be performed in the router, we believe that you should look at it on a case-by-case basis. For example, packet re-ordering and FEC can both be performed in either the router or in a separate appliance. If the network is supporting just typical data applications, either approach will work. However, routers are designed to support typical data applications and part of their design is to have buffers that fill up when a lot of data is being sent and then drain as either less data is transmitted or the TCP session ends. As we pointed out in the first of these newsletters, in a data replication application the data flow is constant and the session never terminates. As such, it is likely that the router’s buffers will not have the opportunity to drain and hence packet re-ordering and FEC are best implemented in a separate appliance.
We will continue to discuss in future newsletters the factors that impact WAN goodput as well as highlight what functionality belongs in a router.
