Frame Relay Congestion Control

CIS532004016-201003: Network Architecture and Analysis

TABLE OF CONTENTS

Chapter 1- Introduction …………………………………………………………. 3
Chapter 2- Background …………………………………………………………. 4
Chapter 3- Review and Findings ………………………………………………. 11
Chapter 4- Conclusion …………………………………………………………. 12
References ……………………………………………………………………... 13

Frame Relay Congestion Control This document is a study of the principles of congestion control within the frame relay protocol. From examining existing congestion management efforts to up and coming possible solutions there are a multiplicity of efforts intent on solving network congestion issues. These efforts include work by independent research groups as well standards groups like the Internet Engineering Task Force (IETF) and IEEE (802.1Qau - Congestion Notification). Congestion is defined as the condition in which demand exceeds available network resources (i.e., bandwidth or buffer space) for a sustained period of time. Congestion control deals with the resource allocation and traffic management mechanisms that avoid or recover from conditions causing congestive situations. (McDysan, Spohn (1999). The methods for congestion control in frame relay involve congestion management and avoidance. Congestion management attempts to make sure the network never experiences congestion. One method of management attempts to avoid congestion entirely. This involves network designers allocating proper resource allocation which may include changes to: * Physical trunk capacity * Virtual Path Connection (VPC) Bandwidth * Allocated Buffer Space

The way in which a network allocates resources may be a balance between economic implementation cost and the degree of guaranteed Quality of Server (QoS). Congestion avoidance attempts to avoid severe congestion while at the same time keeping the offered load at the lower edge of the mildly congested region. In other words, it attempts to remain below some threshold deemed acceptable transmission rate.
Background
Frame Relay provides for a fair allocation of resources with a concept called a committed information rate (CIR). This rate is defined as an average transmission capacity agreed upon for a virtual circuit that connects one company location to another under normal conditions. For instance, a company may have a need for a virtual circuit with a CIR of 128kbps. What this means is that the company is basically guaranteed that they will have a bandwidth of at least 128kbps available at hand. However, because of the shared nature amongst many subscribers on frame relay networks, there will often be excess bandwidth available at any point and time. This excess bandwidth will actually allow customer’s traffic to “burst” to higher speeds than their subscription rate within allowable bandwidth permission. This “burst” speed is referred to as the Committed Burst Information Rate (CBIR). For example, a virtual circuit with a CIR of 128 Kbps may have a CBIR of 256 Kbps.
Frame relay traffic control procedures which out of necessity precede congestion control procedures are described in the diagram depicted in Figure 1. The total number of bits which are transmitted are plotted on the vertical axes versus time on the horizontal axes. The maximum bit rate per unit of time is limited by the access line rate, AR. The CIR is the number of bits in a committed burst size, Bc, that arrives during a measured interval of time T arriving at the equation CIR = Bc/T. The dashed line in the figure represents the slope equal to CIR. If the amount of bits arriving during the interval T exceeds Bc, but lower than what is represented as a threshold, Bc+Be (with Be equaling the amount of data in excess of Bc the network will attempt to transfer), then the frames associated with those bits are marked as Discard Eligible (DE) as represented in Figures 1 and 2.

Figure 1 Example of Frame Relay Traffic Control Operation (McDysan & Spohn,1999)

Figure 2 The basic 2-byte frame relay frame and header (McDysan & Spohn,1999)
Frame Relay switched networks provide simple congestion-notification mechanisms. Frame Relay switching equipment can mark a Frame Relay packet with either front-end congestion notification (FECN) or back-end congestion notification (BECN) within the frame relay header field as illustrated in Figure 2. As components of congestion avoidance, both FECN and BECN notifications are defined as explicit signaling. According to Stallings (2002), for explicit signaling, two bits in the address field of each frame are provided. Either bit may be set by any frame handler that detects congestion. The two bits are as follows:

* Backward explicit congestion notification (BECN): Notifies the user that congestion avoidance procedures should be initiated where applicable for traffic in the opposite direction of the received frame. It indicates that the frames that the user transmits on this logical connection may encounter congested resources. BECN sends a message to the source router when a Frame Relay switch senses congestion in the network. A BECN message requests a reduced data-transmission rate. BECN messages are also relayed to the higher-layer protocols, which can initiate some form of flow control or traffic shaping. In some cases, the higher-layer protocols ignore BECN messages. (Stallings, 2002; McDysan & Spohn,1999)

* Forward explicit congestion notification (FECN): Notifies the user that congestion avoidance procedures should be initiated where applicable for traffic in the same direction as the received frame. It indicates that this frame, on this logical connection, has encountered congested resources. A DTE device receiving this message can relay this information to a higher-layer protocol for processing, which in turn can initiate flow control or simply ignore the message. (Stallings, 2002; McDysan & Spohn,1999)

The DTE equipment at the other end of a circuit notices whether a packet has experienced congestion and notifies a higher layer that congestion has occurred. Additionally, the equipment can mark a packet as discard eligible (DE) to indicate that it is less important, which means that it can be dropped if congestion occurs.

As mentioned, the Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN) bits indicate to the receiver and sender, respectively, the presence of congestion in the network. The Discard Eligibility (DE) bit, when set to 1, indicates that during congestion conditions the network should discard this frame in preference to other frames with a higher priority, for example, those with DE bit set to 0. The danger with this method though during long periods of congestion is that the application may react by retransmitting lost frames, intensifying congestion, and possibly resulting in a phenomenon called congestion collapse. Congestion collapse, in a nutshell is the condition where the total incoming bandwidth to a node exceeds the outgoing bandwidth. This condition back in 1987 with the ARPANET led to the development of the TCP network protocol.

RFC 2914 from which many of the principles described is a comprehensive examination of the protocols for correct effective congestion control implementation. It describes through illustration the danger of not implementing proper congestion control mechanisms and discusses the role of the Internet Engineering Task Force (IETF) in standardizing congestion control protocols. This RFC was released in September, 2000. Mentioned in the text in subsection 4.3, New develops in the standards process, are RFC’s [RFC 2212, RFC 2475] concerning the development of integrated and differentiated services and of Explicit Congestion Notification (ECN) [RFC 2481]. As a forefront to newer developments a proposed construction of Endpoint Congestion Management enabling multiple concurrent flows from a sender to the same receiver to share congestive control state. The idea is to allow multiple connections to the same destination governed by a Congestion Manager to slow-start individual connections taking advantage of previous congestive states in end-to-end paths.

There are a number of recent studies intent on improving the problems associated with network congestion. One such study, Adaptive Routing in Data Center Bridges (Minkenberg, Gusat &Rodriguez, 2009), studies the benefits of multi-pathing, i.e., the presence of multiple alternative paths between any pair of end nodes. Multiple path alternatives lead to significant performance improvements by taking full advantage of path diversity. This diversity avoids congestion by rerouting “hot” flows (i.e., those detected as contributing to congestion) onto an alternative, uncongested path; only when no uncongested alternative exists are transmission rates of hot flows reduced at the sources.

The premise behind this study is to prove that if a congested flow can be routed on an alternative, uncongested path, its rate does not have to be reduced. Therefore, as the paper indicates, combining adaptive routing (AR) with congestion management (CM) can significantly increase the throughput of a congested network, because send rates have to be reduced only if no alternative uncongested path exists. Congestion due to routing conflicts could be resolved effectively by rerouting some or all of the congested flows onto an alternative path, thereby obtaining higher overall network throughput than in existing 802.1Qau approaches, which merely reduce the source rates. An advantage of the proposed scheme is that no changes are necessary to the Ethernet frame format, existing CM schemes, and Ethernet adapters; it operates by exclusively modifying the routing behavior of the Ethernet switches. Interoperation with 802.1Qau is seamless: if no alternative path exists, the send rates will eventually be reduced to match the bottleneck rate.

This groups conclusive efforts showed that the performance can be improved significantly (increased throughput, reduced latency) under both specific congestion scenarios and uniform traffic. Execution times were lowered compared to existing benchmarks which in some cases found that enabling congestion management by itself (without adaptive routing) does more harm than good.

Another study, An Architecture for Congestion Management in Ethernet Clusters ( McAlpine, Wadekar , Gupta , Crouch & Newell, 2005), describes methods for dealing with congestion by employing three levels of congestion management: 1) provide congestion detection and information feedback from the Ethernet interconnect that can be used to enable higher layer congestion management, 2) support rate control at Ethernet entrances to avoid oversubscription of the lower layer interconnect resources, and 3) provide flow optimization and rate control on the links local to congestion to deal with transient congestion issues. The final expectation was to deal with congestion by providing a method for efficient throughput, low latency, low delay variations, and eliminating frame drops, even with very modest sized switch buffers.

The simulation results presented in this paper demonstrated that these mechanisms can significantly improve performance of short-range Ethernet interconnects during heavy congestion. This study is a work-in-progress conducted in parallel with IEEE standards efforts (i.e. 802.1Qau).

Review and Findings The congestion management tools in place have been effective in alleviating what has been a growing need since networks are ever increasing capacity and bandwidth. The methods introduced in the IEEE studies are evidence that by and large the ability does exist to add on and to improve issues related to network congestion. I found the study on Adaptive Routing in Data Center Bridges (Cyriel Minkenberg, Mitchell Gusat, German Rodriguez), most interesting since they seemed to have a more complete understanding of how their methods could adapt to existing congestion methodologies. The idea where previous use of adaptive routing was limited to compensating loss of connections between nodes can now be used to establish new connections to compensate for congestive connections is a very much needed adaption.

Conclusion
This study was very much a learning experience allowing comparisons from what exists in congestion management schemes to what is now being proposed. As time progresses and network connection rates are ever increasing, there definitely is a need to modify existing congestion relief efforts to incorporate the kinds of methods which seem to be in the works as of this report. I look forward to investigating progress in this area as modifications are implemented.

References

McDysan, D., Spohn, D. (1999). ATM Theory and Applications (Signature ed.), McGraw-Hill.
Stallings, W. (2002). Network Architecture and Analysis. Upper Saddle River, NJ: Prentice Hall.
Minkenberg, C., Gusat, M., Rodriguez, G. (2009). Adaptive Routing in Data Center Bridges. 2009 17th IEEE Symposium on High Performance Interconnects, August 2009, 33-41.
McAlpine, G., Wadekar, M., Gupta, T., Crouch, A., Newell, D. (2005). An Architecture for Congestion Management in Ethernet Clusters. 19th IEEE International Parallel and Distributed Processing Symposium (IPDPS'05) - Workshop 9, April 2005, 211a.