Wred, compression and LFI
I am finishing up on chapters regarding WRED and LFI.
WRED is a congestion avoidance mechanism. What that means, is that when congestion occurs, you try and avoid filling up the buffers completely by dropping some packets. Normally the standard queueing for fast interfaces (>E1) is FIFO, with the congestion avoidance of tail dropping. That means whenever the buffers are full, any new packets to the queue, gets dropped. This has a nasty habbit of producing TCP synchronization.
TCP synchronization is an event that occurs when multiple TCP streams are flowing through your router. When tail dropping is in use, all of a sudden no new packets can be accepted, and is therefor dropped. The windowing feature of TCP will run its backoff algorithm, thus all TCP streams will do this, and all of a sudden the line is underutilized. A nasty side feature of this is that UDP streams will just keep on at it even after tail dropping some packets. This is due to the fact that UDP does not use any windowing features. End result is TCP synchronization and TCP starvation because of UDP packets.
To the rescue comes RED (Random Early Detection), which is a mechanism for dropping packets already in the queue, to prevent newly arrived packets from being dropped. It works by splitting the queue up into three “parts”, the no-drop part, the drop part and the full drop part. 3 Parameters will be set, the min-threshold, the max-threshold, and the MPD (Mean Probability Denominator). When the average queue size is below the min-threshold, no dropping will occur. Above the max-threshold, tail dropping occurs. However in between the min and max thresholds, RED will increasingly drop packets randomly. The MPD is specified as a number, for example 10. That means that right before max-threshold occurs, RED will drop 1 out of 10 packets. The lower this number, the more aggressive during the entire time. So its a linear scale of dropping.
Cisco implements RED by using weights, these weights can be either IP Precedence or DSCP.
You can use RED by doing: “(config-if)# random-detect”, however this wont work if you are running WFQ/PQ/CQ/CBWFQ (however in CBWFQ you can specify it under your classes). It will however also work with fair-queueing under the class-default class. Dont ask me why.
Compression, especially header compression is a useful feature when working with voice in particular. The overhead for voip packets is substantial, therefor on some links its useful to enable compression. Basically header compression knows that on a link the headers stay the same, so the first frame is sent with normal headers, and both ends compute a hash value. This hash value is then used instead of the original headers for the comming data traffic. This can result in 40bytes becomming 2-4bytes. Quite a saving. Remember that with 20ms of voice, you are looking at a packet rate of 50.
LFI (Link Fragmentation and Interleaving) is a method whereby you can “chop” up packets in the hardware queue and interleave them with smaller packets. Note that more headers will be used, hence less bandwidth effecient, but it will provide better delay for delay sensitive packets. It is configured on a link-per-link basis.
On to watch some videos to wrap things up.