| ★ wanayoo — archive 1999 http://data.com/tutorials/atm_flow_control.html | Nouvelle recherche | Portail wanayoo |
|
|
|
|
|
Figure 1: Rate and Credit BasicsUnder rate-based flow control (A), switches and end-stations adjust transmission rates in an end-to-end loop by sending resource management cells that indicate how much bandwidth is available for transmission. With credit-based flow control (B), receiving switches and end-stations control transmission rates on a hop-by-hop basis, issuing credits that tell the transmitting station how much bandwidth is available. 
|
In this end-to-end rate-based scheme, the source of a virtual circuit indicates the desired rate in a resource management cell-a standard 53-byte ATM cell used to transmit flow-control information. This resource management cell travels on the virtual circuit about which it carries information, and is therefore allowed to flow all the way to the destination end-station. The destination reflects the resource management cell, with an indicator to show that the resource management cell is now making progress in the reverse direction. The intermediate switches then mark down the rate (the expl icit rate allocated to the virtual circuit) in the reverse resource management cell. The smallest allocation is therefore the value in the cell when it reaches the source. The source may then use this rate for subsequent transmissions until a new resource management cell is received.
Credit-based flow-control schemes also make use of a feedback loop, but they use hop-by-hop loops rather than end-to-end loops. Each link maintains its own independent control loop; when traffic moves across a network, it moves through a series of hop-by-hop feedback loops. The receiving end of each link issues "credits" to the transmitting end indicating the number of cells the transmitting station is allowed to send. Source end-stations transmit only when they have permission to do so from the network.
Under the credit-based approach, each link in the network runs the flow-control mechanism independently for each virtual circuit. A certain number of cell buffers are reserved for each virtual circuit at the recei ving end of each link. One round-trip's worth of cell buffers must be reserved for each connection, so the amount of buffering required per connection depends on the propagation delay of the link and the required transmission rate of the virtual connection.
For example, for a connection to attain a maximum bit rate of 155 Mbit/s, the connection requires four cell buffers per kilometer (to accommodate propagation delay) plus further buffering to account for any switching delay (latency). The transmitting end-station maintains a credit balance, in which each unit of credit represents one empty cell buffer at the receiving end of the feedback loop. As each cell is transmitted by the sender, the credit balance for that connection is reduced. When the connection runs out of credit, it must stop transmitting cells. As cells are removed from the buffers at the receiving end of the link, credits become available and are returned to the sending end.
From the beginning of the traffic -management debate, it was clear that a credit-based solution would have difficulty winning support among WAN equipment and service providers, making it unlikely that a credit-only approach could succeed. The memory requirements of credit-based approaches were simply too great for WAN switch makers-and buyers-to swallow.
In a credit-based flow-control scheme, the end-stations can transmit only when there is sufficient buffer space on the network to accommodate the transmission. Because WANs by their very nature cover large geographic areas, any transmission traversing a WAN link incurs sizable propagation delay. The low latencies available in a LAN simply are not available from a WAN because of limitations imposed by the speed of light. This is physics-it cannot change with improved implementations.
In a high-speed WAN network, such as one based on ATM, this propagation delay will be greater than queuing delay. That is, it will take longer for the data to cross the link than for a switch or en d-station to process the transmission. The speed at which a user can adjust to congested network conditions is a function of the propagation delay and will be much slower in the wide area than the local area.
Also, because propagation delay is sizable in WAN environments, buffer queues fill up more quickly than the network can accommodate the traffic. The buffer sizes required to support a hop-by-hop credit scheme would simply be impractical. A public carrier providing ATM services must deploy high-speed switches with a large number of access ports. Implementing per-virtual-circuit queuing on these large switches would be unacceptably expensive.
Further, large carrier switches operate at port speeds of 2.4 Gbit/s and above. The ATM Forum believed that at these speeds it would be difficult to implement any flow-control mechanism more sophisticated than explicit forward congestion indication (EFCI), the basic mechanism spelled out in version 3.0 of the ATM Forum's UNI (user-network interface) sp ecification. Credit-based flow-control schemes would not take advantage of the EFCI and would probably be incompatible with these high-end switches.
One final reason why rate-based schemes were preferable for the WAN environment is that public carriers like to charge for their services, and most felt it would be much easier to perform billing when the rate was adjusted explicitly by the network. Carriers need to provision virtual circuits, to tariff connections, and to police their networks according to the rate at which information is being sent. Billing for services would have required significantly more planning and administration if a credit-based scheme were implemented in WAN environments.
The only credit-based scheme that could have been applied effectively in WAN environments would have been one that supported dynamic buffer allocation. This dynamic credit scheme would have required a smaller amount of buffer memory, but it would have shared memory across multiple virtual circuits. If memory for one virtual circuit were idle, the dynamic credit scheme could reallocate that memory to other active virtual circuits.
It is imperative that ATM perform extremely well in LAN environments. It faces stiff competition from both switched and shared-media high-speed LAN technologies, including FDDI, fast Ethernet, and 100VG-AnyLAN. And although ATM offers quality of service guarantees superior to the prioritization schemes of competing high-speed technologies, many users will not be ready to take advantage of these features for quite some time. Rather, the initial adoption of ATM in LAN environments will be driven by the desire to efficiently support Ethernet, token ring, and TCP/IP applications at higher speeds.
In these environments, the ABR class of service essentially will be used as a "best effort" service that emulates LAN technologies. CBR and VBR service will coexist with ABR in this environment, but ABR will be the primary class of service in use for emulated LANs and IP over ATM applications.
To maximize bandwidth in LAN-emulation environments, the ATM network must keep cell loss very low. Even a low cell-loss rate can result in a high packet-loss rate, and packet loss results in inefficient usage of network resources.
Among the flow-control proposals before the ATM Forum, a hop-by-hop, per-virtual-circuit, credit-based one (based on static allocation of buffers) achieved the ideal from this LAN-centric perspective. In this credit-based scheme, no congestion occurred, so higher-layer packet loss due to congestion was impossible. This reliability made the overall behavior of LAN applications, which use existing protocol stacks (such as TCP/IP, UDP/IP, and IPX), more predictable.
Another important issue is the fairness of the flow-control mechanism. In an ATM network, CBR and VBR traffic, which have explicit bandwidth guarantees, are not subject to the congestion-control mechanism used for ABR traffic. Indeed, flow control applies only to the available ban dwidth-the bandwidth not already claimed by CBR and VBR.
A credit-based flow-control scheme also would have worked well in environments carrying a mix of CBR, VBR, and ABR traffic. CBR and VBR flows use bandwidth in such a way that the periods of idle time when network bandwidth is not reserved may last from a few microseconds to several tens of milliseconds. The responsiveness of the credit-based scheme-its ability to transmit immediately at the full line rate if buffers are available at the receiving end-makes it an efficient way to take advantage of available bandwidth. The credit-based approach is inherently more responsive than a rate-based approach, which alerts the end-station to slow down only after congestion occurs.
Conversely, during the development of the rate-based flow-control approach, a few proposals were made in which a LAN user would begin transmission of a burst at a minimum rate and slowly ramp up to a fair share of the bandwidth. While this is a reasonable approach for the WAN, it isn't suitable for LAN applications. Remote procedure call and client-server applications generating moderate loads of bursty traffic would perform poorly in an environment where transmission would have to start out slow and throttle up. They would no sooner reach their peak available transmission rate, when the traffic burst would be complete.
Credit control was simple in concept and could be proven to work. It would satisfy the most stringent demands of the local area both now and into the future. The rate-based approach also appeared to require more expensive adapter card technology than a credit-based approach. The scheduling hardware for the rate mechanism would clearly become the most complex component of the ATM adapter, while the additional hardware required to support the credit approach was modest in comparison.
It didn't take long for switch designers to realize that rate-based flow control made the best political sense for WANs, primarily because o f the carriers' cost concerns and because credit-based flow control looked quite attractive for the LAN. The simplest solution appeared to be to integrate the two in a way that would allow for rate-based mechanisms in WAN switches and carrier networks and credit-based approaches in LAN and internetworking environments (see Figure 2).
Figure 2: Credit on the LAN, Rate on the WANOne potential way to resolve the conflict between rate-based and credit-based flow-control options would be to create a hybrid approach allowing credit-based control on the LAN side, where it is most appropriate, and rate-based control for WAN links. The big problem with this approach, however, is that it requires separate interfaces for LANs and WANs, which runs counter to ATM's potential to unite the two networking worlds. 
|
But this apparently simple solution suffered from one major drawback: It created two types of ATM interfaces. Considering that ATM offers the potential for a seamless integration of LAN and WAN environments, this additional interface presented a significant stumbling block.
The approach would have implemented this interface on the trunk port card of the campus backbone switch that connected to a WAN. The interface would have functioned as a virtual source and virtual destination, terminating and connecting the credit-based control loop used on the LAN and the rate-based feedback loop used on the WAN. The LAN would look like a rate-based source to the WAN, and the WAN would appear as a credit-based subnet to the LAN.
The credit-based side of this interface would return credit information for virtual circuits whose data cells were forwarded to the WAN. The buffer at the interface from the LAN to the WAN direction only would have to be large enough to handle each virtual circuit at the full rate of the LAN link. However, on the WAN side, where rate-based flow control was in effect, substantially more buffer space would be needed. Because of propagation delay, the rate-based WAN could send considerable information to the interface before being granted access to the credit-based LAN. This WAN-to-LAN buffer would have to accommodate the potentially large end-to-end round-trip feedback delay.
This virtual source-virtual destination interface would have operated as a traffic shaper for the ABR service-that is, an interface that prepared the ABR traffic to enter the WAN and that allowed WAN traffic to enter the LAN as ABR. It is likely that similar traffic-shaping mechanisms will be needed to prepare VBR and CBR for entry to the wide area as well, so it did not seem to be an excessive burden to require such an interface.
However, unlike interfaces that prepared one type of traffic for different ATM environments or link speeds, this integrated flow-control solution effective ly divided the ATM world into two types of interfaces: credit-based on the LAN side and rate-based on the WAN side. The internetworking industry's experience with the Ethernet and token ring duality led the forum to believe that it would be far better to attempt a single interface.
Also, while the boundary between LAN and WAN may exist for some time to come, this dual-interface solution could only perpetuate it. At the borders, there could be many instances where it was unclear which side of the fence a particular product was intended to address. In this case, the vendor would have to support both types of interfaces. And interoperability problems also surfaced. It was unclear exactly how a rate-based adapter card or switch could be supported within a credit-based LAN.
Another possibility was to make rate-based flow control the default requirement for all ATM gear, while specifying a credit-based standard as an option. In this solution, rate-based control would always be used in the WAN, and it would be the default choice for the LAN. But credit-based control would be an option for LAN environments. Both rate and credit control loops could coexist within the same set of nodes (see Figure 3).
Figure 3: Separate but EqualAnother possible way to create a hybrid flow-control method would be to equip ATM switches to handle both flow-control types. Under this scheme, if all devices on a given virtual circuit path are able to handle credit-based flow control, that method would be used. If not, all devices would fall back to rate-based control as a default method. 
|
If all entities on the path of a given virtual circuit were capable of credit-based flow control, then the credit scheme could be used. If they were not, the rate-based default approach wou ld be used. If credit were selected on the LAN portion of a virtual circuit traversing both LAN and WAN, the dual virtual source-virtual destination interface between the LAN and WAN would still be required. However, if credit-based control were used only for connections that remained within the LAN, this problem could be avoided. Any virtual circuit that crossed the border between LAN and WAN would use the rate-based default.
This model would have permitted users to buy low-cost rate-only switches with minimal buffering, or high-performance (and more expensive) credit-based switches with larger buffers. But it also would have added considerable complexity. For multiple flow-control mechanisms to coexist on the same network, congestion-control protocol selection would have to become part of the ATM signaling process. And ATM adapter cards also could become more complicated.
A final compromise proposal suggested still another way to integrate rate and credit solutions. This scheme would have employed ATM resource management cells to carry both rate and credit information. That is, the cell would specify the rate at which a virtual circuit could transmit, but it would also contain a validity count field that would set a limit on the number of cells that could be transmitted at the specified rate. When the validity count ran out, the source would cease transmission on the virtual circuit until it received a new resource management cell.
With this proposal, a switch that was part of an ATM network could choose to participate in one or the other of the congestion-control algorithms. If a switch wanted to participate in an end-to-end rate-based congestion-management algorithm, it would mark the resource management cell with an explicit rate indicator. It would indicate the rate according to its calculation of the desired rate for that virtual circuit given the current congestion levels on the network.
However, the switch would also mark the resource management ce ll with a validity count. This count could be set for the interval at which the switch recomputes rate information, or for the maximum time the switch can go before communicating a new rate to the virtual circuit. The validity field may be a constant value, that is, inserted in each of the resource management cells communicated to the virtual circuits. If necessary, depending on how conservative the switch designer is, this value may in fact be variable, set to smaller values as the switch gets more and more congested.
To participate in the hop-by-hop credit scheme, the switch would indicate the virtual circuit's peak rate in the resource management cell and supply a validity count value that informed the next upstream node how many cells it could send at the specified rate. Once the upstream node exhausted this count, it would then have to await a replenishment of credits-a new validity count value-from the downstream node.
The primary attraction of this scheme was that it permitted rate and credit switches to be mixed within the local area without any special interface. A rate switch could operate downstream from a credit switch because the resource management cell contained both rate- and credit-control information. The source would not transmit at a rate greater than that permitted by the rate switch and would send no more cells than that permitted by the credit switch.
To support a credit switch on the same network as a rate switch, the credit switch would fill in the validity count field in the backward resource management cell with the number of credits allowed, then the rate switch would fill in the explicit rate field in the same backward resource management cell. This way, the source would be limited by both the rate that the rate switch specified and the number of cells (validity count) the downstream credit switch could buffer for that virtual circuit and ensure no cell loss.
As far as the end-station adapter is concerned, there is only one interface. The adapter transm its cells at the rate conveyed in the resource management cell until the validity count specified in that cell runs out. This approach might have required somewhat more sophisticated adapters and perhaps slightly more buffer memory in credit-based switches (enough to handle input from rate-based switches until the resource management cell could reach the next upstream node).
The debate on the end-to-end rate-based congestion-control framework vs. hop-by-hop credit-based congestion control has resulted in considerable enhancement of the overall quality of the ATM congestion-control technique for ABR service. Ultimately, the ATM Forum decided to adopt a rate-only specification for flow control. The reasons? First, the simplicity of one flow-control mechanism across LAN and WAN was quite attractive. If there were going to be a single approach across both environments, it had to be a rate-based solution-credit-based options were impracticable.
More importantly, develo pers of rate-based flow-control schemes made considerable progress in adapting rate-based techniques to LAN environments. The most significant of these enhancements have been the inclusion of an explicit rate-control capability and the implementation of congestion-avoidance techniques within ATM switches.
In particular, there has been considerable effort by the Traffic Management Working Group to understand and define the behavior of the explicit rate scheme for congestion management. Several areas that were initially strong goals motivating the development of the hop-by-hop credit-based scheme for LANs have been addressed.
One of the issues raised in the earlier debates was the degree of oscillation in the source rate (and, in fact, the aggregate rate observed within the network, at the switches) and the resulting need for large buffers. These oscillations were due both to the simpler EFCI scheme and, in the explicit rate scheme, to the conservative requirement to reduce the virtual circuit's rate of transmission of each cell.
Recent modifications to the explicit rate scheme have substantially reduced the extent of these oscillations while retaining the capability of the scheme to protect the network during periods of congestion and the use-it-or-lose-it concept for the source rate.
Another important aspect, the notion of a fast startup without waiting for the network to provide feedback, has been considered. This requires the scheme to limit the exposure of the network to the selection of an inappropriate initial rate by a source. It has been accomplished by limiting the amount of data that may be transmitted by a source in the absence of feedback and requiring the source to reduce its allowed cell rate successively while awaiting the reception of feedback from the network.
In environments where the round-trip delay is small (such as in LANs), the likelihood of feedback arriving quickly would further limit the exposure of the network. Such accommo dations in the explicit rate scheme (albeit with some risks in poorly configured switches with small buffers) allow for data applications such as remote procedure calls to perform reasonably well.
Some vendors no doubt will choose to implement as proprietary solutions some of the alternatives posed during the credit vs. rate debate-possibly even the integrated rate-and-credit solutions-but these will not conform to an ATM Forum standard and will be unlikely to interoperate with standards-based flow-control implementations.
Other vendors will no doubt choose to do nothing at all about ABR flow control. Most new switch designs implement the capability to discard entire packets rather than individual cells-the so-called early packet discard (EPD) algorithm. When carrying packet data that provides its own congestion-avoidance algorithm (such as TCP/IP traffic), EPD-equipped switches with adequate buffering could attain performance levels similar to those now achieved with routers. This packet data traffic could use the unspecified bit rate (UBR) class of service, which requires no bandwidth or rate guarantees, rather than ABR.
[ Home ]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
|||||||||||
|
|||||||||||
|
 |
|
|
