by olivier | Mar 1, 2010 | IOS, QOS, Written Theory
Another QoS mechanism that is useful for slower link speeds is LFI which will fragment larger payload to specified fragment sizes and then interleave the smaller payloads in among the fragments, reducing then the serialization delay.
There are three primary LFI mechanisms supported by Cisco are as follows:
- Multitlink PPP (MLP) : used on PPP links
- FRF.12 : used on Voice over IP over Frame-Relay (VoIPovFR) links
- FRF.11 Annex C : used on voice ov Frame-Relay (VoFR) links
In MLP mode , then you define the maximum serialisation delay that you wnat on your link and under FRF.12, you define the maximum size of the fragment that you want on your link.
by olivier | Mar 1, 2010 | IOS, QOS, Written Theory
To make more efficient the use of your bandwidth on slow-speed links, we can use 2 types of compression.
- Payload compression : Reduces the payload size, using approaches such as STAC, predictor or MPPC
- Header compression : Reduces the size of the TCP and RTP headers
The goal of compressions technologies is to increase the throughput over a WAN link while we are reducing the delay.
However , especially with payload compression approaches , the time that is required by lower-end routers to run the compression algorithm can increase the overall delay so in order to avoid this , you still can equip your router with a compression module like the CAIM.
With header compression , a header typically is reduced from approximately 40 bytes to 3 up to 5 bytes for TCP header compression or 2 up to 4 bytes for RTP header compression.
However, the routers technically are not doing real compression. Rather, these routers cache information that does not change during a conversation, such as source and destination IP address and TCP/UDP port numbers. The compressed header then carries such information as UDP checksums and a session context ID (CID) which identifies which flow the packet is a part of.
by olivier | Mar 1, 2010 | IOS, QOS, Written Theory
In a Frame-Relay network, we can ask to routers during congestion in the network cloud to reduce the CIR to a lower value. So when a Service Provider becomes congested and needs to discard frames, it first discards frames with their Discard Eligible (DE) bit set to 1. The Service Provider also can request that the sending router slows its transmission rate by marking the Backward Explicit Congestion Notification (BECN) bit to 1, in a frame going back to the sender.
When this occurs , if the router is configured to respond to BECNs, the router reduces its CIR by 25 percent. If the router receives another BECN in the next time interval, it decreases its transmission rate by 25 percetnof the current rate and this can happen until the rate drops to the router’s configured minimum CIR.
Please also take in mind that sometimes , you can encounter the situation where the sender doesn’t receive anything or insufficient traffic back. In such a situation , the Service Provider can’t mark the BECN bit in a frame going back to the sender. To remedy this situation, the Service Provider can mark then the Forward Explicit Congestion Notification (FECN) bit to 1 in a frame which is destined for the receiver. Then if the receiver is configured to respond to FECN, it generates a Q.922 test frame which will be sent back to the sender and will then offer the opportunity to the Service Provider to mark the frame with the BECN bit and so will ask then to the sender to slow the traffic.
As a general rule , if a sender has slowed its transmission rate because of BECNs, 16 timing intervals must elapse before the sender begins to increase its transmission rate again.
by olivier | Feb 28, 2010 | IOS, Written Theory
WRED discards packets and that is one way for the router to indicate a congestion. Routers will be now able to indicate a congestion condition by signaling it with an approach called Explicit Congestion Notification (ECN).
ECN uses the two last bits in the TOS to indicate whether a device is ECN capable , and if so, whether congestion is experienced.
- If the bit combination is 00 , then the router means that it is not ECN capable .
- If the bit combination is 01 or 10 , then the router means that it is ECN capable and is not experiencing congestion
- If the bit combination is 11 , then the router means that it is ECN capable and is currently experiencing congestion
The 7th bit is the ECT bit and the 8th bit is the CE bit.
Cisco routers can use ECN as an extension to WRED and mark packets that exceed a specified value , instead of dropping the packets. So if the queue depth is at or below the WRED minimum threshold, the packets are sent normally, just as with WRED.
Also if the queue depth is above the WRED maximum threshold, all packets are dropped , just as with WRED.
But if the queue depth is currently in the range between the minimum and the maximum threshold, one of the following action can happen:
- If both endpoints are ECN capable , ECT and CE bits are set to 1 and sent to the destination, indicating that the transmission rate should be reduced.
- If neither endpoints support ECN, the normal WRED behaviour occurs.
- A packet with its ECN and CE bits marked can reach a destination router that has already a full queue. In such an instance, the notification is dropped.
To activate ECN , use the following command under the policy-map : random-detect ecn ( so it is applied under the MQC but you can apply it also under the interface)
