A Service Architecture for ATM:
`From Applications to Scheduling
`
`Mark W. Garrett, Bellcore
`
`Abstract
`This article derives a rationale for the service architecture of the ATM Forum’s
`Traffic Management 4.0 specification. This model distinguishes a small num-
`ber of general ways to provide quality of service (QoS) which are appropri-
`ate for different classes of applications. We construct the set of ATM service
`categories by first analyzing the QoS and traffic requirements for a reason-
`ably comprehensive list of applications. The most important application prop-
`erties and the complexity of the related network mechanisms are used to
`structure the services. This method has the desirable property that the number
`of service categories does not expand rapidly with the introduction of new
`applications. We also discuss packet scheduling as the key component for
`realizing such a set of services, and report on an experimental realization of
`a fair queuing scheduler.
`
`TT
`
`he ATM Forum Traffic Management (TM) working
`group has recently completed its TM 4.0 specifica-
`tion, which includes a revised service architecture
`for asynchronous transfer mode (ATM) [1]. Five
`service categories have been identified as follows:
`• CBR — Constant bit rate
`• rt-VBR — Real-time variable bit rate
`• nrt-VBR— Non-real-time variable bit rate
`• UBR — Unspecified bit rate
`• ABR — Available bit rate
`The purpose of such an abstraction is to draw a small
`number of very basic distinctions in the quality of service
`(QoS) behavior of the network. It provides a conceptual
`tool to both equipment designers and network service
`providers by structuring the problem of providing appro-
`priate QoS and traffic management over the vast space of
`application requirements.
`We first provide a brief view of the historical develop-
`ment of this service architecture. The next section identi-
`fies a taxonomy of application classes, and the third section
`analyzes the traffic and QoS requirements of these appli-
`cations. We then develop the service categories by consid-
`ering simple and then more complex services appropriate
`to the applications identified. The next sections discuss the
`methodology of our service model derivation. In the
`remaining two sections, we argue that packet (or cell)
`scheduling is the essential mechanism for attaining mean-
`ingfully differentiated QoS behavior, and report on a high-
`speed scheduler implementation.
`History
`This service architecture is similar to the ATM bearer
`capability (BC) concept, and is essentially a newly thought-
`out version of that idea. The form of the BC information
`element, which is signaled as part of an ATM connection
`setup message, dates back to the earliest standards for
`
`broadband integrated services digital network (B-ISDN).
`The BC service model distinguishes three properties:
`whether a source is constant or variable rate, whether the
`source and destination are time-synchronized, and whether
`the service above the ATM layer is connection-oriented or
`connectionless.
`By comparison, our new model essentially retains the
`CBR/VBR distinction. The timing requirement in the BC
`is a very strong property. When it is asserted, the network
`must provide some explicit means of timing recovery, such
`as the synchronous residual timestamp mechanism of ATM
`adaptation layer 1 (AAL-1). In the new model we have a
`fundamental notion of real-time or non-real-time, but it is
`limited to determining whether timing parameters such as
`delay and jitter are specified. Finally, the connection-ori-
`ented indication of the BC does not serve a useful purpose
`because a flow must always set up a connection in ATM.
`Whether or not a higher-layer protocol is connection-ori-
`ented has little effect on the behavior of the ATM net-
`work. The BC service model is pervasive in the
`International Telecommunications Union (ITU) traffic
`management standards, and provided the original structure
`for both the AALs and the QoS classes [2].
`In order to better accommodate data communications
`applications, the ATM Forum incorporated a “best effort”
`indication in the signaling specification of User-Network
`Interface (UNI) 3.0 [3]. During the early TM discussions
`which led to the TM 4.0 model (in September 1993), it
`became clear that best effort should be split into two
`modes, a “plain best effort” (which became UBR) and a
`“better best effort” (which became ABR) [4]. One con-
`tributing factor was that people from the telecommunica-
`tions industry were less comfortable with a totally
`unspecified service than those from the data communica-
`tions side. It was not clear for several months, however,
`exactly how these two services would be distinguished. In
`
`6
`
`0890-8044/96/$05.00 © 1996 IEEE
`
`IEEE Network • May/June 1996
`
`

`

`A Service Architecture for ATM:
`From Applications to Scheduling
`
`Mark W. Garrett, Bellcore
`
`Abstract
`This article derives a rationale for the service architecture of the ATM Forum’s
`Traffic Management 4.0 specification. This model distinguishes a small num-
`ber of general ways to provide quality of service (QoS) which are appropri-
`ate for different classes of applications. We construct the set of ATM service
`categories by first analyzing the QoS and traffic requirements for a reason-
`ably comprehensive list of applications. The most important application prop-
`erties and the complexity of the related network mechanisms are used to
`structure the services. This method has the desirable property that the number
`of service categories does not expand rapidly with the introduction of new
`applications. We also discuss packet scheduling as the key component for
`realizing such a set of services, and report on an experimental realization of
`a fair queuing scheduler.
`
`TT
`
`he ATM Forum Traffic Management (TM) working
`group has recently completed its TM 4.0 specifica-
`tion, which includes a revised service architecture
`for asynchronous transfer mode (ATM) [1]. Five
`service categories have been identified as follows:
`• CBR — Constant bit rate
`• rt-VBR — Real-time variable bit rate
`• nrt-VBR— Non-real-time variable bit rate
`• UBR — Unspecified bit rate
`• ABR — Available bit rate
`The purpose of such an abstraction is to draw a small
`number of very basic distinctions in the quality of service
`(QoS) behavior of the network. It provides a conceptual
`tool to both equipment designers and network service
`providers by structuring the problem of providing appro-
`priate QoS and traffic management over the vast space of
`application requirements.
`We first provide a brief view of the historical develop-
`ment of this service architecture. The next section identi-
`fies a taxonomy of application classes, and the third section
`analyzes the traffic and QoS requirements of these appli-
`cations. We then develop the service categories by consid-
`ering simple and then more complex services appropriate
`to the applications identified. The next sections discuss the
`methodology of our service model derivation. In the
`remaining two sections, we argue that packet (or cell)
`scheduling is the essential mechanism for attaining mean-
`ingfully differentiated QoS behavior, and report on a high-
`speed scheduler implementation.
`History
`This service architecture is similar to the ATM bearer
`capability (BC) concept, and is essentially a newly thought-
`out version of that idea. The form of the BC information
`element, which is signaled as part of an ATM connection
`setup message, dates back to the earliest standards for
`
`broadband integrated services digital network (B-ISDN).
`The BC service model distinguishes three properties:
`whether a source is constant or variable rate, whether the
`source and destination are time-synchronized, and whether
`the service above the ATM layer is connection-oriented or
`connectionless.
`By comparison, our new model essentially retains the
`CBR/VBR distinction. The timing requirement in the BC
`is a very strong property. When it is asserted, the network
`must provide some explicit means of timing recovery, such
`as the synchronous residual timestamp mechanism of ATM
`adaptation layer 1 (AAL-1). In the new model we have a
`fundamental notion of real-time or non-real-time, but it is
`limited to determining whether timing parameters such as
`delay and jitter are specified. Finally, the connection-ori-
`ented indication of the BC does not serve a useful purpose
`because a flow must always set up a connection in ATM.
`Whether or not a higher-layer protocol is connection-ori-
`ented has little effect on the behavior of the ATM net-
`work. The BC service model is pervasive in the
`International Telecommunications Union (ITU) traffic
`management standards, and provided the original structure
`for both the AALs and the QoS classes [2].
`In order to better accommodate data communications
`applications, the ATM Forum incorporated a “best effort”
`indication in the signaling specification of User-Network
`Interface (UNI) 3.0 [3]. During the early TM discussions
`which led to the TM 4.0 model (in September 1993), it
`became clear that best effort should be split into two
`modes, a “plain best effort” (which became UBR) and a
`“better best effort” (which became ABR) [4]. One con-
`tributing factor was that people from the telecommunica-
`tions industry were less comfortable with a totally
`unspecified service than those from the data communica-
`tions side. It was not clear for several months, however,
`exactly how these two services would be distinguished. In
`
`6
`
`0890-8044/96/$05.00 © 1996 IEEE
`
`IEEE Network • May/June 1996
`
`

`

`Application Class
`
`Example Applications
`
`(1)
`(2)
`(3)
`(4)
`
`Interactive video
`Interactive audio
`Interactive text/data
`Interactive image
`
`(5) Video messaging
`(6) Audio messaging
`(7)
`Text/data messaging
`(8)
`Image messaging
`
`(9) Video distribution
`(10) Audio distribution
`(11) Text distribution
`(12) Image distribution
`
`(13) Video retrieval
`(14) Audio retrieval
`(15) Text/data retrieval
`(16) Image retrieval
`
`(17) Aggregate LAN
`(18) Remote terminal
`(19) Remote procedure call
`(20) Distributed file service
`(21) Computer process swap
`
`Video conferencing, distributed classroom
`Telephone
`Banking transaction, credit card verification
`Multimedia conferencing
`
`Multimedia e-mail
`Voice mail
`E-mail, telex, fax
`High-resolution fax
`
`Television
`Radio, audio feed
`News feed, netnews
`Weather satellite pictures
`
`Video on demand
`Audio library
`File transfer
`Library browsing
`
`LAN interconnection or emulation
`Telecommuting, telnet
`Distributed simulation
`
`early 1994, the genesis of ABR emerged as a
`consensus that an ATM data-oriented service
`should offer a very low cell loss rate (in order
`to keep the Internet Protocol packet loss rate
`reasonable [5]), and that this would be accom-
`plished through some sort of native ATM feed-
`back flow control. The VBR service underwent
`a similar split and clarification. In September
`1994, Dan Grossman of Motorola presented
`an argument that VBR, which is characterized
`by a double leaky bucket (LB) traffic descrip-
`tion, should have both a real-time and a non-
`real-time version, the former of which includes
`delay and jitter parameters [6].
`The rationalization presented in this article
`for the ATM service model was contributed to
`the ATM Forum in September 1994 in order
`to develop consensus that this model was cor-
`rect, useful and not arbitrary [7]. Although it
`was presented publicly after the model was
`effectively in place, the work leading to this
`result actually predated the best effort split of
`1993 (so it was not as much an afterthought as
`it might seem).
`We proceed with the derivation by looking
`at a set of applications and identifying the
`important characteristics. We show that the structure in
`the service categories reflects structure in both the appli-
`cation set and the switch functionality.
`
`n Table 1. List of application classes and some example applications.
`
`A Top-Down Approach: Start with
`Applications
`An assumption is sometimes made in the networking
`
`research community that because the future will be full
`of new and radically different applications, we cannot
`learn to design future networks by looking at current com-
`munications applications. While the premise of this state-
`ment has some truth to it, the conclusion does not. The
`current applications will continue to exist (largely), and
`collectively they do represent a very wide range of features
`and requirements.
`Consider the list of application classes in Table 1. These
`are at a level of abstraction corresponding to what the user
`is generically doing. This list cannot be claimed as com-
`plete, of course, but it is large and representative, and
`therefore sufficient for our purpose. Note that this list
`does not include terms like “circuit emulation” or
`“switched multimegabit data service (SMDS),” because
`these are services at a lower level of abstraction and them-
`selves carry more basic applications. It also does not dis-
`tinguish between business video conferencing and
`residential video telephone; both would be interactive
`video at this level.
`This list is derived (roughly following an ITU taxonomy
`[8]) by considering video, voice, image, and data in conver-
`sational, messaging, distribution, and retrieval modes.
`Some computer applications have been added which vary
`in volume of traffic and tolerance to time delay. Conversa-
`tional or interactive means there is a person on each end of
`the connection. Messaging means a person talking to a
`machine. Retrieval is a person causing a machine to trans-
`fer information. Distribution is a machine sending to peo-
`ple or machines who listen passively. The computer
`communications application classes listed (17–21) are
`machine-to-machine interactions.
`
`Each of these classes corresponds to a set of applica-
`tions; some well-known examples are indicated in Table 1.
`Signaling for the ATM network itself is an important
`source of traffic. In terms of QoS, it is an asynchronous
`application which requires timely delivery. Signaling would
`require a QoS perhaps similar to either remote procedure
`call or distributed file service.
`For some applications there may be different technical
`solutions, such as CBR MPEG vs. VBR motion-JPEG cod-
`ing for video, that significantly affect the traffic and QoS
`of the application. These innovations often improve a ser-
`vice by exploiting trade-offs (e.g., statistical multiplexing
`for loss), which in turn impose different requirements on
`the ATM service. These differences are not reflected in
`Table 1, but will come into play in defining the service cat-
`egories.
`
`Detailed Discussion of Traffic Description and
`QoS Requirements
`From our list of applications, we can identify a number of
`
`important traffic and QoS issues, such as the following:
`CBR/VBR, degree of burstiness, statistical multiplexing,
`real-time delay constraints, delay tolerance in non-real-
`time applications, interactiveness, loss tolerance, priority,
`use of leftover bandwidth, multiresolution coding (e.g., for
`loss concealment), QoS consistency, and fairness. Keeping
`this list in mind, we can now analyze the QoS needs of our
`set of applications.
`Audio and video can be transmitted conveniently using
`CBR because they are traditionally CBR-coded for circuit
`transport. Even with packet transport and VBR coding,
`the peak-to-average ratio for audio and video is typically
`in the range of 3 to 10 [9, 10]. Since this number bounds
`the statistical multiplexing gain, we could argue that CBR
`transport is moderately efficient for real-time audio and
`video applications.
`Traditional computer communications applications as
`well as video/audio/image applications which transport dis-
`
`IEEE Network • May/June 1996
`
`7
`
`

`

`The single most
`important
`distinction among
`applications
`is that of real-time
`and rate-oriented
`vs. non-real-time
`and unit-oriented.
`
`crete units of information (i.e., messaging
`and retrieval applications) can be quite
`bursty and therefore have a lot to gain
`from statistical multiplexing. Also, such
`unit-oriented applications do not have a
`natural rate. A first-order description of
`QoS for such applications is that the trans-
`action is complete when all of the data
`arrives; the sooner the transfer completes,
`the better the quality. The user does not
`care about the timing details of particular
`cells, only about the transfer seen as a sin-
`gle object. This property identifies a fun-
`damental distinction between such
`unit-oriented applications and rate-oriented
`applications such as voice and video.
`Considering this more carefully, howev-
`er, we can note that there is a minimum
`transfer time, below which the user will
`not notice any better quality. For real-time applications, a
`late cell is a lost cell. For unit-oriented transfers, it is not
`so easy to describe good delay QoS concisely. For exam-
`ple, some computer communications applications are sen-
`sitive to delay because they involve tight interaction
`between machines. These include remote procedure calls,
`distributed file service, and memory paging/swap. (Note
`that these applications can have different sensitivity to
`delay, even though we may call them all “non-real-time” or
`“delay-tolerant.”) An occasional bad delay is quite tolera-
`ble, but excessive average delay will badly affect the
`machine processes’ efficiency. A unit-oriented application
`can also be interactive. A text-based interaction between
`people or between a person and a machine is also degrad-
`ed by excessive average delay, although an occasional long
`delay is tolerated.
`Some applications are semi-interactive, meaning that
`one side of the conversation treats the communication as
`interactive and the other does not. For example, any
`audio/video messaging or retrieval application has a person
`on one end and a machine on the other. This can be han-
`dled by either a real-time rate-oriented transport or a non-
`real-time unit-oriented transport. An answering machine
`takes advantage of the existence of the telephone network,
`and the information is transported as if the application
`were interactive. One could alternatively record the mes-
`sage locally and send the audio file by electronic mail. In
`this case the transport would be noninteractive. This
`choice depends on what network options are conveniently
`available to the user.
`All messaging applications are very tolerant to delay.
`Distribution applications can be delayed substantially, but
`the delay variation has to be bounded because a buffer is
`necessary to re-synchronize the playback. For retrieval
`applications, a user may be somewhat sensitive to delay
`beyond some number of seconds; however, this is much
`longer than the interactive real-time delay constraint.
`Computer communications applications are generally
`sensitive to loss because all data must be received correctly
`and errors cause retransmission. The cost or inconvenience
`of retransmission depends on whether the application is
`also sensitive to delay. When a machine process must wait
`for retransmitted data, it may be desirable to purchase a
`more reliable network service. For bulk message forward-
`ing, retransmission over a lossy or delayed channel may be
`perfectly acceptable and cheaper. Audio and video can be
`quite tolerant to loss if they are coded correctly. Loss of
`video frame synchronization information will cause signifi-
`
`cant QoS damage, while loss of some pic-
`ture element resolution or some speech
`samples could easily go unnoticed. The
`current thinking in video coding research
`is toward layered or multiresolution cod-
`ing, where high- and low-priority streams
`are created. Loss of low-priority cells has
`very limited effect on the overall quality,
`while the high-priority stream must be
`well protected against loss [11, 12]. (Note
`that layered coding is not yet reflected in
`video standards such as MPEG, which
`were not originally designed for packe-
`tized transport.) The permitted loss toler-
`ance of a video service may depend greatly
`on the user application. A video confer-
`encing application may require less relia-
`bility than entertainment and distribution
`video, for example, because the users can
`easily compensate for slight glitches in the transmission.
`There are two aspects of priority. The first is to differ-
`entiate between applications that tolerate loss or delay dif-
`ferently. The second is to determine who gets access to
`resources (bandwidth or buffers) in real time. Resources
`may be allocated to one service but, if not used, can be
`made available to another [13]. The statistics of the appli-
`cations sharing a VBR service, for example, are interesting
`in two ways. First, the statistical behavior and some knowl-
`edge of the required QoS can be used to produce resource
`allocation rules that realize statistical multiplexing gain
`while retaining appropriate QoS. Second, the statistics of
`the sources will indicate how well the leftover bandwidth
`not used by that service can be relied upon by other ser-
`vices running at lower priority. An obvious example is that
`even somewhat delay-sensitive data applications can make
`good use of bandwidth left over from a VBR video service,
`because on the rare occasion when the video uses all of its
`allocation, the data service can easily survive on less for
`the moment.
`Finally, whenever various users are statistically multi-
`plexed there is an issue of fairness. Even when a service is
`defined symmetrically with respect to two users, it is
`possible that one user gets better service than another
`because of the quantity or timing of the traffic submitted.
`If there is a wide variation in quality, such as the delay in
`transmitting a message, then the user may be annoyed by a
`perceived lack of QoS consistency provided by the net-
`work. The network can potentially provide some function-
`ality to guarantee (or aid) fair and consistent service
`provision across the set of users who subscribe to the same
`service.
`
`Service Categories Derived from Application
`Properties
`The single most important distinction among applications
`
`is that of real-time and rate-oriented vs. non-real-time
`and unit-oriented. When people are observing a continu-
`ous flow of visual or auditory information, a lack of conti-
`nuity caused by excessive jitter or loss has a significant
`quality impact. Furthermore, when the application involves
`people interacting in real time, there is an overall delay
`constraint of a few hundred milliseconds, beyond which
`the delay becomes noticeable and annoying. Applications
`having this delay constraint require very precise handling.
`Those that do not can be switched more economically. The
`
`8
`
`IEEE Network • May/June 1996
`
`

`

`tolerance of delay can be exploited to
`allow the switch considerable flexibility.
`CBR Service Category
`Real-time applications are predominately
`those which contain video or audio infor-
`mation. These applications also tend not
`to be very bursty, in the sense that it is
`reasonably efficient to assign a fixed band-
`width to a single source. For this reason,
`voice and video communications are com-
`monly carried over fixed-rate circuits with
`tiny delays incurred in switches. This leads
`to a definition of the CBR service as a
`very simple, reliable, guaranteed channel.
`CBR is (by this definition) intended for
`real-time applications, and therefore
`assumes a real-time delay constraint. The
`allocated rate is defined, and the applica-
`tion is assumed to offer traffic constantly
`at this rate. The acceptable loss rate, max-
`imum delay, and maximum jitter are also specified.
`Although CBR may be the simplest service to define, it
`may not necessarily be the easiest to implement well. For
`example, consider a CBR connection spanning several
`administrative domains. The CBR rate is measured and
`policed by an LB mechanism 1 at each administrative
`boundary. After traversing the first network, the measured
`jitter, or cell delay variation (CDV), will surely increase.
`The traffic entering the next network is then more bursty,
`even though the description signaled at connection setup is
`the same. One approach to this problem is to initially set
`the bucket size parameter to accommodate the jitter inher-
`ent in the source and added by all of the networks in the
`path. However, this will probably lead to overly pessimistic
`engineering rules because the entity setting up the connec-
`tion does not generally know about the whole path. The
`problem of CDV accumulation, and how it scales as the
`network gets very large, is perhaps one of the most impor-
`tant and underestimated open problems in ATM network-
`ing.2
`UBR Service Category
`The applications that will not utilize a CBR channel effi-
`ciently are those which sporadically send discrete units of
`information. Most computer communications and messag-
`ing applications behave this way and therefore benefit
`greatly from statistical multiplexing. These applications do
`not have the real-time delay constraint, but can be moder-
`ately sensitive to loss. We can call these applications unit-
`oriented, as distinguished from rate-oriented, because
`fundamentally the object is to transfer a fixed quantity of
`bits rather than to provide a continuous flow.
`The most natural, simple service discipline (in terms of
`implementation) for these applications is first-in first-out
`(FIFO) queuing, as we find in the Internet and other com-
`puter networks. The tolerance to delay implies that large
`buffers are appropriate in the network because they trade
`delay for loss. The notion of a simple service for non-real-
`time bursty traffic (for which a FIFO might be an appro-
`priate implementation) is what we commonly call “best
`
`1 In ATM terminology, this is the Generic Cell Rate Algorithm (GCRA) [1].
`
`2 Jitter accumulation is no less difficult in the Internet, if we hope to intro-
`duce resource reservation and guaranteed delay bounds.
`
`We can now add
`more service
`categories by
`finding features of
`applications which
`are not completely
`or efficiently
`satisfied by the
`existing categories.
`
`effort.” This has evolved in the ATM
`Forum TM group to be called unspecified
`bit rate (UBR) because it is a service with-
`out any explicit rate parameter. Note that
`UBR is exactly the service model of the
`current Internet, which argues that,
`although simple and lacking much control,
`it is quite useful and commercially viable.
`The UBR definition therefore includes
`no notion of rate or GCRA parameters,
`although it may be useful to negotiate a
`ceiling rate corresponding to the smallest
`bottleneck along the path (the peak cell
`rate parameter is used for this). Similarly,
`there is no cell-wise delay or jitter require-
`ment, or any explicit loss rate contract.
`The QoS in this case is determined, not by
`algorithms operating on each cell, but by
`engineering the capacity of the overall sys-
`tem to accommodate the overall traffic
`demands. Although there may be no rate
`allocation per virtual circuit (VC), it is probably a good
`design choice for the UBR service, as a whole, to have an
`amount of bandwidth assigned to it which cannot be pre-
`empted by other services.
`In the current Internet, the subnetwork itself is assumed
`not to do any congestion control. An end-to-end protocol
`such as TCP regulates the flow of traffic. This model is
`generally appropriate for ATM UBR service as well. In
`cases such as Internet Protocol (IP) over ATM, where a
`retransmission protocol operates with a data unit larger
`than a cell, UBR should include an enhancement such as
`early packet discard [5] to maintain good performance.
`
`Progression from Simple to Complex
`CBR and UBR, therefore, are two very simple services
`
`which can accommodate the vast majority of applica-
`tions. We can now add more service categories by finding
`features of applications which are not completely or effi-
`ciently satisfied by the existing categories. This approach
`gives us a systematic process and justification for creating
`new service categories.
`Real-Time VBR Service Category
`An improvement in efficiency can be made by allowing
`real-time applications to use VBR coding. Sources can be
`statistically multiplexed, resulting in more efficient band-
`width usage. Since multiplexing implies some nonzero
`probability of loss, the applications must be coded appro-
`priately.
`We can define a VBR service category as real-time (like
`CBR), but where the source rate is allowed to vary. The
`acceptable cell loss rate, delay and jitter are specified. The
`sustainable cell rate and maximum burst size (SCR/MBS)
`parameters can be used in addition to the peak rate to
`describe the variable bandwidth process. An effective way
`to provide statistical multiplexing while ensuring appropri-
`ate QoS for VBR video is to make engineering rules for
`the amount of bandwidth and buffers that are necessary
`for a given number of multiplexed sources. To produce
`these rules would require extensive experience with user-
`perceived quality as a function of allocated resources and
`perhaps other properties of the service. This design is
`more feasible when a dominant type of coder exists, and
`its statistical behavior can be studied in depth. For this to
`
`IEEE Network • May/June 1996
`
`9
`
`

`

`Service categories
`
`Real-time
`
`CBR
`Fixed, guaranteed resources
`
`Non-real-time
`
`UBR
`"Best effort"; no explicit network
`control or source description; rate
`adaptation and loss recovery at
`endpoints
`
`r.t. VBR
`Allows statistical multiplexing;
`takes advantage of limited
`tolerance to loss (includes peak-
`allocated VBR as a special case)
`
`n.r.t. VBR
`Adds explicit resource
`reservation; improves
`loss and delay
`
`ABR
`Uses feedback to
`improve loss
`and fairness
`
`n Figure 1. Architecture of ATM service categories. The fundamental dichotomy is
`between real-time and non-real-time applications. For each case there is a very
`simple solution and then one or two more complex solutions.
`
`For some non-real-time unit-oriented appli-
`cations, QoS can be improved substantially
`by adding network functions that improve
`fairness, loss, and/or delay. As discussed
`previously, an appropriate delay control for
`these applications is quite different from
`one appropriate for real-time applications.
`The non-real-time VBR service category
`improves loss and delay over UBR by pro-
`viding peak and sustainable rate parameters
`(and corresponding bucket parameters) and
`a loss rate parameter. These are used to
`allocate resources for each nrt-VBR connec-
`tion. The loss rate allows the service catego-
`ry
`to be engineered
`for statistical
`multiplexing while maintaining acceptable
`performance.
`The main QoS considerations that have
`led the ATM Forum TM group to its defini-
`tion of ABR have been minimizing loss and providing fair-
`ness. The network functionality that realizes these goals is
`a rate-based feedback flow control protocol, the details of
`which can be found in the recently completed ATM Forum
`traffic management specification [1]. End-to-end flow con-
`trol algorithms (such as TCP) do not necessarily cause
`resources in the middle of the network to be shared fairly;
`nor do they minimize congestion as efficiently as might be
`possible using information from the congested node within
`the network. The operation of ABR’s feedback flow con-
`trol is assumed to be independent of the windowing mech-
`anism of TCP. This raises two issues. Most immediately,
`how do these two protocols behave together? Is TCP per-
`formance improved by the ABR flow control? Is it ever
`worse? What happens when the ATM network is only a
`small part of the end-to-end TCP path? Some encouraging
`results were presented to the ATM Forum during the
`development of ABR, but clearly more work is needed.
`The second issue opens an interesting topic for research:
`Supposing that ATM becomes a significant technology
`underlying TCP/IP internets, can the explicit congestion
`notification from within the ATM subnet be passed to the
`end-to-end flow control mechanism, and does this improve
`performance over having independent mechanisms?
`The ABR protocol does not use the LB traffic descrip-
`tion, and the resource allocation philosophy is therefore
`closer to that of UBR. It has no signaled cell loss rate,
`although a network provider could generally advertise a
`CLR value with its service. No delay or jitter parameters
`are applicable. The ABR protocol does include an optional
`minimum cell rate. While this parameter is certainly useful
`for allocating minimum resources to the connection, and
`thus improving the delay averaged over, say, a file transfer,
`it does not necessarily provide a delay bound for each cell
`carried, as would be the case for a real-time service.
`
`work in ATM, it may be useful to signal a source type
`parameter to identify the appropriate set of engineering
`rules for the application. (Note that currently no such
`parameter exists, and, in general, an adequate consensus
`regarding the use of rt-VBR has not been attained in the
`industry.)
`There are two flavors of real-time VBR