Control unidirectional traffic over Frame-Relay

Two of the most-used methods of traffic control on Frame Relay networks are the infamous FECN and BECN. The Forward Explicit Congestion Notification and Backward Explicit Congestion Notification work by flipping a bit in the Frame-Relay header and they are set in the network to indicate to the end devices that congestion was experienced; the assumption is that the end device will reduce its transmission rate to reduce the congestion.

More specifically, when router A is sending a bunch of traffic to router B and there's congestion in the network, the carrier's Frame-Relay switch will set the FECN bit on the frame to let router B know about the congestion, and the switch will set the BECN bit in the next frame traveling back towards router A to let it know that congestion was experienced.

The problem is that sometimes you have a lot of UDP traffic that doesn't use acknowledgements, especially when dealing with multi-media stuff like VoIP or streaming media, and this traffic tends to flow primarily in one direction. So in this case, if there's congestion and there are no frames traveling back toward router A, most systems by default are unable to regulate the traffic flow. Note that "no frames" really only means "no frames for a second or two." There may be frames flowing in that direction, but if they're infrequent enough, this situation could degrade the quality of your voice traffic.

Some routers have a workaround for this. When router B receives a FECN, it can send a Q.922 test frame back to router A with the BECN bit set. This takes a little longer, but if the round-trip-time isn't too long, it's often enough to let router A know that congestion is being experienced and that it should throttle down its transmission rate. For more information on this for Cisco IOS routers, look up the command "traffic-shape fecn-adapt."

Another possible solution is to deactivate silence suppression, which would cause traffic to be sent in both directions more frequently. Obviously, this is a tradeoff between bandwidth and responsiveness.

Thomas Alexander Lancaster IV is a consultant and author with over ten years experience in the networking industry, focused on Internet infrastructure.