TEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, VOL, 13, NO. 7, SEPTEMBER 1995 Delay-Adaptiv Rate-Adaptive Fig. 3. Utility(performance)of a delay-adaptive real-time application as a Fig. 4. Utility (performance)of a rate-adaptive real-time application as a function of bandwidth maller than the intrinsic generation rate. For delay-adaptive the signal quality is much better than humans need. It also audio and video applications, the utility function curves might appears that at very small bandwidths, the marginal utility is look something like Fig. 3 very slight because the signal quality is bly low(se Note that the drop-off in performance is not nearly so sharp [45] for some human-factors studies). The curves take the as with hard real-time applications, but the general shape of shape in Fig. 4 the curve is very similar. In particular, this utility function Similar to the regular video utility functions, these utility convex but not concave in a neighborhood around zero. Thus, functions are convex but not concave in a neighborhood the network can become overloaded with such applications; around zero so the network can become overloaded with the exact location of the overloading point will depend on the such applications. However, the overloading point is much particular shape of the utility curve around the inflection point. smaller than those of regular delay-adaptive applications. The This analysis suggests why the Internet community and overloading point of delay-adaptive applications is tied to th the telephony community have been at an impasse for years bandwidth consumption in the normal case, whereas the over the issue of best-effort versus real-time service. The loading point of rate-adaptive applications is tied to the band- Internet community built a network to support data transfer width consumption of the minimally acceptable signal quality applications that fall into the elastic category. For them, We should note that our simple Gedanken experiment can the decision to offer best-effort service was the natural and be generalized to mixtures of different types of applications correct one. It is only now that video and other real-time with the same conclusions; the treatment is complicated by applications are being widely used on the Internet, and with the need to describe the relative allocation of bandwidth to heir appearance are coming calls for admission control the various different applications, but the general conclusion Similarly, the telephony community built a network around that the overloading criterion depends on the curvature of the an application (voice)with hard real-time requirements. When utility functions remains unchanged he community designed ATM to service these applications, This Gedanken experiment suggests that for a network the decision to offer real-time service and use admission with only traditional data applications, efficacy is maximized control was again the natural and correct choice. Now that by accepting all flows. However, when there are real-time data services are being contemplated for ATM networks, the applications, whether hard real-time, or delay-adaptive, or even idea that ATM should offer best-effort has properly arisen. 28 rate-adaptive, then efficacy is maximized when some flows are There is another class of real-time applications. Rate- turned away. We now address the question: should one build on rate 29 in an architecture that includes admission control, or should one response to network congestion. This adjustment keeps the overprovision the network so that overloading rarely occurs delays moderate no matter what the bandwidth share. Thus, the performance of the application depends completely on the quality of the signal. Certainly at high bandwidths the B. Overprovisioning marginal utility of additional bandwidth is very slight because If one could cost-effectively overprovision the network so that under natural conditions the offered load rarely exceeded applications were made the overloading point, then one might choose to do that rather an include admission control in the architecture we dont Whether or not the adjustment is actually done at the source, or done by require that overloading never occurs, we merely require that be the only reasonable design choice for multicast fows. The only ehs may ume between failures on that link; then, overloading is just y essential another failure mode. We are not asking if there are individual available bandwidth. In addition, we are assuming that all rate-adaptive links that can be overprovisioned; undoubtedly there are applications are also delay -adapti Rather. since the IP architecture is uniform, we are asking