{'fraction_non_alphanumeric': 0.02663284717818643, 'fraction_numerical': 0.0050729232720355105, 'mean_word_length': 4.888059701492537, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Evolution of controls for the available bit rate service

In the summer of 1993, the asynchronous transfer mode (ATM) community began a search for a mechanism to allocate bandwidth dynamically within an ATM network, while simultaneously preventing data loss. By the fall of 1994, the ATM Forum had introduced a new service category for this purpose, the available bit rate (ABR) service, and had selected a rate-based mechanism for its support. Simply put, the mechanism would consist of a stream of ABR resource management (RM) cells, generated by one end of the connection (the source) and looped back by the other (the destination), into which switches would encode the maximum rate at which the ABR source was to generate data. The ABR service is an addition to ATM that uses a feedback mechanism to control the transmission rates of traffic sources. Although the performance of the ABR service will depend critically on the quality of feedback sent by switches, the algorithms for determining this feedback are largely outside the scope of ATM standards and specifications. We describe how two of the properties implemented by the ABR source and destination, out-of-rate RM cells and a use-it-or-lose-it policy, were implicitly architectural decisions, and we explain how and why the ATM Forum ultimately revised these decisions. We then discuss how the ATM Forum addressed the issues of conformance testing, point-to-multipoint connections, and parameter negotiation for the ABR service. At the end, we reflect on the process by which the ABR specification was developed.