Internet Engineering Task Force Integrated Services WG INTERNET-DRAFT L. Breslau/S. Shenker draft-ietf-intserv-hetero-00.txt Xerox 15 November 1995 Expires: 5/15/96 A Proposal for Accommodating Heterogeneity Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This document is a product of the Integrated Services working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at int- serv@isi.edu and/or the author(s). Abstract Routers need not provide all services defined by the intserv WG. This will inevitably lead to heterogeneity in the set of services offered by network elements. How can we enable applications to obtain the end-to-end service they desire in the face of this heterogeneity? This document describes an approach involving replacement services and characterizations that builds end-to-end service out of heterogeneous per-link service offerings. This proposal was first described in [1], from whence much of the text was lifted. Breslau/Shenker Expires 5/15/96 [Page 1] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov 1995 Introduction The Integrated Services WG is currently operating under the assumption that while the IETF will define and standardize a set of services such as those described in [2-5], it cannot -- and indeed should not -- mandate the universal deployment of these services. Within this context, a router can be considered compliant with the integrated services architecture if it can respond to requests for enhanced qualities of service, even though it may not implement all (or any) of the specified real-time services. We refer to such a router as "integrated services-aware". Whether or not a service is deployed remains under the control of individual network service providers and router vendors. Different vendors may choose to support different subsets of defined services in their products, and different service providers may choose to deploy a different subset of defined services in their networks. Thus, different services will be available at different routers (or, more generally, network elements in the sense of [2]) in the Internet, and some routers may not support any service other than best-effort. While private IP networks may achieve a high degree of homogeneity, heterogeneity in the set of services offered by various routers is inevitable in the Internet as a whole, and we must incorporate its presence in our overall architecture. In this document we discuss one approach to dealing with such heterogeneity gracefully. We consider the situation where there are several defined services that require admission control, along with the traditional best effort service. Absent the mechanisms we describe in this document, the normal semantics of a service request for these admission controlled service are assumed to be that if the service requested is not available, either because the current load is too high or because the router does not offer the service, then the service request is denied. For specificity we will refer to the Guaranteed, Predictive, and Controlled Delay services defined in [3- 5], but nothing in this proposal limits us to those particular services. All routers support best effort service, but routers need not support any of the other services. We confine this discussion to the problem of heterogeneity in the set of services offered by integrated services-aware routers. We specifically do not address the problem of non-integrated services-aware routers, which offer only best effort service and cannot respond to requests for other services. Without mechanisms to cope with heterogeneity in the set of offered services, routers not supporting a service requested by an application must deny the service request. This enables applications Breslau/Shenker Expires 5/15/96 [Page 2] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 to use only those services offered by all routers along a path between source and destination. This restriction to the "best common service" significantly limits the services available to applications. For example, applications running on any host attached to an ethernet supporting only best effort service would be unable to secure anything other than best-effort service at all routers along a path. Such a design would severely limit the use of partially deployed services, thereby inhibiting the incremental deployment of new services. This default "best common service" behavior would therefore greatly slow, and perhaps even prevent, the evolution of the Internet towards an integrated services architecture. Thus, mechanisms that address the problem of heterogeneity are a necessary component of an integrated services architecture. Some cases of heterogeneity can be handled trivially. When presented with a service request, routers are always free to substitute a "better" service, in the sense of the ordering used for merging (see [2]). For instance, a router can always use a better level of predictive service than the one requested, and in fact merging depends on such substitutions. Less trivially, if predictive is always considered better than controlled delay in the ordering relationship, then a router can always substitute predictive service for controlled delay service. In such "ordered" cases, the network element actually can be considered to offer the lesser service as well as the better service. Thus, when we say a network element does not offer a service, we mean that it does not offer it or any other strictly better service. However, as part of offering the lesser service, the element must export the appropriate characterization values. Replacement Services The approach we take is based on the principle of "replacement" services. When a service is requested, it can be replaced by an alternate service (under conditions described below) at those routers not offering it. That is, the service request's RSpec specifies one service, but the router not offering that service invokes another service. The fundamental principles underlying this approach are that (1) the service expected by an application should be modeled on the ideal of end-to-end connectivity of the requested service (i.e., the service that would be provided if all routers along the path offered the requested service), and (2) the network is responsible Breslau/Shenker Expires 5/15/96 [Page 3] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 for informing the application the extent to which this is a realistic approximation. This insulates applications from having to understand, or even know about, the detailed nature of heterogeneity or how the different services along the path compose. This insulation is critical, we feel, for enabling applications to function relatively undisturbed while the network infrastructure evolves. Before continuing, it is important to note that we are not addressing the issue of allowing substitutions for admission control failures. That is, we are not proposing using replacements if the requested service is offered at a router but admission control has denied the request because the load is too high, or the request is not mergeable with a previously existing reservation (if two services do not have a common "upper bound" that is better than both of them then there is no way to merge them). We do think this is an important issue, especially when admission control failures are a result of merging problems and so are likely to deny service for a long period of time (i.e., if there is no ordering between predictive and guaranteed service, then a predictive request and a guaranteed request will not be able to merge and the later arriving request will continue to be denied until the earlier reservation terminates). However, it does not seem on the critical path to early deployment of services. In contrast, the heterogeneity problem, particularly where there are many network elements that offer no services besides best effort, will seriously hinder deployment if not addressed immediately. The use of replacement services can be viable for two reasons. First, local conditions and service definitions may enable a router to substitute one service for another without a perceptible difference in the quality of service delivered to the application. For example, a lightly loaded ethernet that offers only best-effort service may have low enough delays that it provides service as good as is required by predictive service. Second, applications vary in the degree of assurance they require about the service they receive. An adaptive application that is tolerant of packet loss, may be satisfied with best-effort service at those routers where real-time service is not available. We characterize replacement services as "reliable" or "unreliable". A reliable replacement is one that meets the service specifications of the service it is replacing a large majority of the time. We do not express the degree of compliance precisely, but for purposes of the present discussion we assume reliable replacements achieve this conformance well over 95% of the time. There is a distinction between the notion of the reliability of replacement services and the reliability of service implementations. Breslau/Shenker Expires 5/15/96 [Page 4] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 The reliability of a reliable replacement need only apply to the particular environment in which it is deployed, where assumptions can be made about the nature of the load. Thus, an overprovisioned router with FIFO scheduling, and no admission control, does not support predictive service, but can offer a reliable replacement for predictive service. In contrast, a compliant implementation of an actual service, such as predictive or controlled delay, must be able to meet the service requirements independent of both where it is deployed and the ambient load. While the lack of specification of the degree of reliability may seem vague, we assume that over time operational guidelines and informal standards of acceptable practice will emerge. The key point behind the notion of reliable replacements is an implicit statement that use of the replacement will result in service that is usually not perceptibly different from the requested service. Examples of reliable replacements could be the use of predictive service for guaranteed service, or the use of best effort service on an underutilized ethernet as a replacement for controlled delay service. However, these specific examples of replacement services, and their classification as reliable or unreliable, should not be taken as a definitive statement about the suitability of these services to act as replacements. This ultimately depends on the specific services defined and on decisions taken by routers, which can be impacted by local conditions. Unreliable replacements are a weaker form of replacement services, carrying no assurance about the quality of the resulting service. That is, service offered as an unreliable replacement can be arbitrarily bad. For example, controlled delay service or best- effort service on an often congested network could be considered unreliable replacements for guaranteed service. Some applications may be willing to use unreliable replacements when no alternative exists, since poor service will in some cases be better than no service at all. Unreliable replacements are always offered, as best effort service constitutes an unreliable replacement for all services. The choice of which service to use as a replacement for a service request, and whether the replacement is characterized as reliable or unreliable, is left to the router. This allows overprovisioning of less stringent services to serve as replacements for more demanding ones. A network built around overprovisioned best-effort service cannot claim to support guaranteed or predictive service, but it could claim to provide reliable replacements for them. In some cases users will care about the difference in perceived quality between guaranteed or predictive service and its reliable replacement and will not use reliable replacements, but for the majority of cases the Breslau/Shenker Expires 5/15/96 [Page 5] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 difference in perceived quality may not matter. Router Substitutions In this section, we describe how routers substitute replacements for services that are not offered. We defer until later the issue of when the use of replacements are allowed and how much control applications maintain over this process. For now we assume that whenever a router receives a request for a service that is not offered, it attempts to use a replacement service. Requests for services not offered by a router can be divided into two categories: services known but not offered by the router and services that are neither offered nor known. In the former case the router substitutes its best replacement service for the original request. This means a reliable replacement is substituted if one is offered, and an unreliable replacement is substituted if no reliable replacement is offered. The service request is then processed as if it were a request for the replacement service. If the replacement service requires admission control, the router uses the admission control algorithm to determine the admissibility of the new request. The service request is rejected if the admission control test fails; substitutions of additional replacement services are not permitted. (The reason for this restriction will become evident later. In short, it enables routers using replacement services to export useful characterization parameters describing their replacement services.) If the admission control test passes, or if the replacement service does not require admission control, the service request is accepted. If a setup protocol like RSVP is used to deliver the service request to the router, the original service request is propagated along the data path by the setup protocol. When a router receives a service request for an unknown service, it cannot even judge the suitability of services as replacements. The best it can do is to substitute the ubiquitously available best- effort service. We show in some simple examples how characterization and service replacements can be used to deal with heterogeneity. We expect the two scenarios we describe here to be representative of situations likely to be encountered in the future Internet. Consider first a situation in which a single real-time service (e.g. controlled delay) is offered at some routers along a path, and other routers offer only best-effort service. These routers will substitute best- effort service for the request for controlled delay service. Thus, the use of service replacements allows an application to obtain the Breslau/Shenker Expires 5/15/96 [Page 6] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 real-time service where it is offered. Applications are not confined to using a common service offered end-to-end. Instead, the end-to- end service is built out of heterogeneous services offered at the routers. Next, we consider the case in which all routers offer real-time service, but they do not all offer the same real-time service. For example, some routers may offer guaranteed service, while others offer predictive (but neither service is offered at all routers). Without a mechanism to allow for the composition of end-to-end service out of different services, applications would only be able to use best-effort service (which is offered everywhere). In this example, if routers use the real-time service they offer as a replacement for the service they do not offer, applications can acquire a real-time service at each router. For example, an application may request guaranteed service, and routers that offer only predictive can substitute predictive. Using these replacements, applications receive better service than if they were confined to using a single service. The previous example depends on routers using the real-time services they offer as replacements for ones they do not offer. While the intelligent use of replacements at routers cannot be mandated, we believe that service providers will have strong incentives to use the best replacement strategies they can. Offering replacement services will make their services more usable and will therefore increase the utilization of their networks. Characterizing Service Availability In this section we describe the implications of our proposal for coping with heterogeneity on the characterization parameters that routers must export. These parameters fall into two categories. First, we describe characterization parameters that provide information about the availability of services. Second, we discuss how routers handle the service specific characterization parameters when they offer a replacement for a particular service. While routers may or may not offer particular services, they must characterize the availability (or lack thereof) of every service. For each service, the router characterizes the availability of the service as one of the following four conditions: Offered Reliable replacement available Breslau/Shenker Expires 5/15/96 [Page 7] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 No reliable replacement available Not known The first condition indicates the router offers the service as defined in the service specification. The second indicates the router does not offer the service, but instead offers a reliable replacement for it. The third indicates that the router offers neither the actual service nor a reliable replacement. Every router implicitly offers an unreliable replacement, as best-effort service constitutes an unreliable replacement for all services. Finally, "not known" means that in addition to not offering the specified service, the router does not even know what the service is. For instance, a newly defined service will not be known to most deployed routers. For each service, there is a characterization parameter that keeps a count of how many routers fall into each category (offered, reliable replacement available, etc.). The composition rule is to add one to the characterization parameter associated with the router's status. Thus, a setup protocol like RSVP can use these characterization parameters to transmit to the application the degree of service availability end-to-end. In addition to the characterization parameters describing service availability, a router must attempt to update the service-specific characterization parameter fields, such as the delay bounds in predictive service, with meaningful values. When a replacement service is offered (reliable or otherwise), the router updates the characterization parameters in the normal manner. For a reliable replacement, the characterization parameter values should accurately reflect the service provided by the replacement service. A router can also attempt to fill in a characterization parameter value for an unreliable replacement since it understands something about the service. For example, a router that uses an unreliable replacement and is consequently unable to guarantee packet delivery might still be able to provide an estimated delay bound based on delays experienced at the router. However, the characterization parameters for unreliable services will often be of little value. If there is no meaningful number that can be inserted, the router can set the validity bit of the associated characterization parameter. This signals that the content of the composed characterization parameter is no longer valid. Finally, routers cannot provide any meaningful characterization parameters for services that are not known because they have no idea what the various characterization parameters represent. For example, a router cannot know whether the characterization value for an Breslau/Shenker Expires 5/15/96 [Page 8] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 unknown service reflects the delay experienced or the loss rate or some other value. In this case, routers should set the validity bit on all the characterization values associated with services they do not know about. Applications receiving characterizations will know how much confidence to place in the values based on the availability of the services end-to-end and on the status of the validity bit. If the characterizations of service availability are made available to the endpoints, e.g. through the use of "advertising" in RSVP, then applications know the extent to which replacements would be made for a specific service request. This would enable an application that did not want such replacements to know beforehand to not submit the service request. Use of Replacement Services While the use of replacement services permits the composition of heterogeneous services end-to-end, applications may have different levels of tolerance for the use of replacement services. Some tolerant applications may always be willing to accept replacement services (reliable or unreliable), while others may prefer their service request to be denied when the requested service is not offered. We discuss mechanisms to accommodate diverse application requirements below. Not surprisingly, providing additional functionality and flexibility to applications entails added complexity in the associated mechanisms. The simplest design removes all choice from the applications and mandates a uniform use of replacement services. That is, a router will always attempt to use its best replacement service when the requested service is not offered. While this design is easy to implement in the sense that it requires no added complexity in service requests or in merging behavior, it does not accommodate applications that do not want replacements to be used. As we noted above, however, in environments where end-to-end characterization of service availability is provided to applications, they will know before making a request whether a service replacement will be made. In such an environment, an application that does not want service replacements has the option not to request a service that is not offered end-to-end. If end-to-end characterizations were always available to endpoints (as was implicitly assumed in [1]) then this design choice is an appealing option. However, our design must accommodate the situation where such characterizations are not available. An extension to the simple design enables applications to control the Breslau/Shenker Expires 5/15/96 [Page 9] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 extent to which replacement services are used. In this design, a replacement handling bit is associated with every service request. If the bit is set in a service request, replacement services are allowed. If the bit is not set, a router that does not offer the requested service must reject the service request and return an error. This enables applications to express their preferences about the use of replacement services. In environments where end-to-end characterization of service availability is not known, setting the bit indicates that the application is willing to accept whatever service replacements are made along the path. In environments where end-to-end service characterization is available, applications should always set the bit since applications that do not want replacements used will know about their use beforehand and therefore have the option to not request service. Including this extra bit in service requests, and allowing applications to control how this bit is set introduces the problem of merging requests that have the bit set differently. What should be done when two requests must be merged, one of which has the replacement handling bit set and the other of which does not? We have identified two options to handle this merging problem. The first mandates a particular merging behavior. Namely, when merging two requests that have the bit set differently, the merged request does not have the bit set. This approach takes the conservative approach that it is better to deny the "flexible" application the use of a replacement service than it is to provide the "inflexible" application with service inferior to what it requested. If the applications are well-behaved, the inflexible application should cease or change its service request, which will give the other application the opportunity to use replacement services (although their service may be disrupted). Hence, this middle ground allows applications to express their desires, but it avoids complicated merging behavior. In this case, setting the bit to allow use of replacements can be thought of as advisory only. The network will honor this desire unless it conflicts with the desires of other applications. Applications that do not set the bit and are not well-behaved can deny service to those applications willing to use replacement services. This option results in the desired behavior when end-to-end characterizations are made available to endpoints, since all applications will set their bits and there is no complicated merging behavior. When end-to-end characterizations are not available, some flexible applications may have their service disrupted due to requests from inflexible applications. Treating the replacement handling bit as more than advisory requires maintaining additional information when service requests are merged. Specifically, merging service requests that have the replacement Breslau/Shenker Expires 5/15/96 [Page 10] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 handling bit set differently requires maintaining two RSpecs in the merged request. One RSpec indicates the best service requested by an application that is willing to use replacements and the other represents the best service requested by an application that is not willing to use replacements. Processing these merged requests is also more complicated. The router must determine the appropriate level of service to install, when to return an error, and when and how to modify the service requests (we omit the details here). However, the advantage of this design is that it makes available to applications a wider range of functionality. Examples of Service Replacement In this section, we give examples of how services can be used as replacements. We consider the 3 real-time services (Guaranteed, Predictive and Controlled Delay) currently being considered by the Integrated Services Working Group. However, we reiterate that our proposal for coping with the problem of heterogeneity in the set of offered services could be used with other real-time services. These examples are intended to demonstrate that service replacement is possible. Other ways to accomplish these replacements may be possible; we do not intend to preclude their use. Replacing Guaranteed Service with Predictive A network element that offers predictive service as a replacement for guaranteed should first select a single level of predictive service that it will use to serve guaranteed flows. This level, i, can be any of the 3 levels of predictive service. The network element assigns the guaranteed service characterization parameter C the value 0, and it assigns the characterization parameter D the value DB_i, where DB_i is the delay bound of predictive service level i. When the network element receives a request for guaranteed service, it treats the request as if it were a request for predictive level i, with the TSpec as specified in the original request. If the network element typically meets the service requirements of predictive service with no or very few delay bound violations, then this replacement can be characterized as reliable. Replacing Guaranteed Service with Controlled Delay Breslau/Shenker Expires 5/15/96 [Page 11] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 A network element that offers controlled delay service as a replacement for guaranteed should first select a single level of controlled delay that it will use to serve guaranteed flows. This level, i, can be any of the 3 levels of controlled delay service. The network element assigns the guaranteed service characterization parameter C the value 0. The characterization parameter D can be assigned the value of the maximal packet delay seen in the last 3600 seconds for level i of controlled delay (this is one of the required characterization parameters for controlled delay service). Alternatively, if the network element maintains maximal delays seen over longer intervals, or if it maintains internally a delay target that it attempts to meet for level i of controlled delay service, it can use either of those values for the characterization parameter D. If there is no available value for the characterization parameter that is likely to be an upper bound on the packet delays experienced, the network element should set the validity bit associated with the characterization parameter (indicating that the characterization is not valid) and not compose the associated characterization value. When the network element receives a request for guaranteed service, it treats the request as if it were a request for controlled delay level i, with the TSpec as specified in the original request. The network element can characterize this replacement as either reliable or unreliable, depending on the likelihood that guaranteed packets will experience delays less than the value it exported for the characterization parameter D. Replacing Guaranteed Service with Best Effort. The network element assigns the guaranteed service characterization parameter C the value 0. If the network element maintains values of delay experienced by best effort traffic, it can use a value of maximal delays seen over a fairly long interval for the characterization parameter D. Alternatively, if the network element does not measure packet delays, it can estimate a suitable value for D based on such factors as the amount of buffer space available at the network element. If there is no available value for the characterization parameter that is likely to be an upper bound on the packet delays experienced, the network element should set the validity bit associated with the characterization parameter and not compose the associated characterization value. Since best effort is not an admission controlled service, all requests for guaranteed service are accepted. Breslau/Shenker Expires 5/15/96 [Page 12] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 Such a replacement can be characterized as reliable if the network element is typically underutilized so that packet loss is infrequent, and if the network element has confidence that packet delays will be less than the value it exports for the characterization parameter D. Otherwise, the replacement should be characterized as unreliable. Replacing Predictive Service with Guaranteed A network element replacing predictive service with guaranteed chooses a delay bound, DB_i, for each level i of predictive service. The only constraint on these values is that they be larger than the characterization parameter D exported for the guaranteed service. The network element uses these delay bounds as the characterization parameters that describe the delay bounds for each level of predictive service. Network elements providing guaranteed service are not required to maintain measures of packet delays. Furthermore, because implementations of guaranteed service are likely to isolate flows from each other, delays experienced by existing guaranteed flows are not necessarily indicative of delays that new flows may experience. Unless the network element maintains measures of packet delay that are indicative of delays that will be experienced by new flows, it should not attempt to compose the characterization parameters associated with actual delays experienced by predictive traffic, and it should set the validity bit associated with these parameters. When the network element receives a request for predictive service, it must compute an appropriate RSpec for guaranteed service. It can compute the reserved rate, R, using the following formula: R = (b + C)/(DB_i - D) where b is the token bucket depth specified in the TSpec, C and D are the characterization parameters for the guaranteed service, and DB_i is the delay bound for the requested level of predictive service. The network element treats this as a request for guaranteed service with the TSpec as specified in the original request and the RSpec having the rate R as computed above. This replacement can be characterized as reliable. Breslau/Shenker Expires 5/15/96 [Page 13] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 Replacing Predictive Service with Controlled Delay The network element uses the characterization parameters describing measured delays for controlled delay service as the corresponding characterization parameters for predictive service. For each level of service, the network element can use as a characterization parameter describing the delay bound either the maximal delay seen over the last 3600 seconds, the maximal delay seen over some longer interval, or any internal delay target it maintains in its controlled delay implementation. A request for predictive service is treated as if it were a request for the same level of controlled delay service. This replacement can be characterized as either reliable or unreliable, depending on the confidence the network element has that the delays experienced by predictive flows will be less than the delay bound characterization parameters it exports for predictive service. Replacing Predictive Service with Best Effort The network element exports the same characterization parameters for each level of predictive service. The network element can use as characterization parameters describing the delay bounds some long term measure of maximal packet delay or some estimate of maximum possible delay based on such factors as the amount of buffer space available at the network element. If the network element maintains measured values of maximal packet delays, these can be used as the characterization parameters describing maximal delays experienced. Alternatively, configured values based on average load or buffer space at the network element can be used. If these values are not likely to accurately reflect the service delivered by the network element, the network element should set the validity bit associated with the characterization parameters and not compose the characterization value. Since best effort does not use admission control, all requests for predictive service can be accepted. Such a replacement can be characterized as reliable if packet loss is infrequent at the network element and if the network element has confidence in its ability to meet the delay bounds it exports for predictive service. Replacing Controlled Delay with Guaranteed This replacement is similar to the replacement of predictive Breslau/Shenker Expires 5/15/96 [Page 14] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 service with guaranteed described above, with the only difference being that the network element does not export characterization parameters describing delay bounds. However, even though controlled delay service does not have a per service level delay bound, the network element must maintain such bounds so that the it can compute an appropriate service rate R. This replacement can be characterized as reliable. Replacing Controlled Delay with Predictive This replacement is trivial, as a conformant implementation of predictive service satisfies all requirements for controlled delay service and the two services use the same invocation parameters. In fact, rather than characterizing this as a replacement service, a network element offering predictive service can also claim to offer controlled delay service. Replacing Controlled Delay with Best Effort This replacement is similar to the replacement of predictive service with best effort. The only difference is that characterization parameters describing delay bounds need not be exported. Such a replacement can be characterized as reliable if packet loss is infrequent at the network element. Other Approaches Our solution is built on the notion of routers selecting appropriate replacements for the services they do not offer. Also, we presented ways to provide applications with a limited amount of control over the actual use of these replacements. Specifically, applications can allow the use of replacements, or have their requests rejected when a requested service is not offered. To put this solution in context, it is worth mentioning alternative approaches which we considered. The option described above which provided applications control over whether or not replacement services are used is a constrained example of what we refer to as "reservation scripts". Fully general reservation scripts allow the entity requesting service to specify a set of router actions to be taken when the requested service is not offered. Thus, a reservation script could expand the set of router behavior to include use any replacement, use only reliable replacements, or use only the Breslau/Shenker Expires 5/15/96 [Page 15] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 requested service (with no replacements). While more general scripts would expand functionality by presenting applications with additional options, they also increase complexity. This increased complexity is primarily manifested in the problem of merging scripts of users who desire different router actions. We feel this additional complexity is not worth the functionality it provides. One can extend the idea of reservation scripts to have individual applications indicate which specific services should be used as replacements. For example, an application could indicate that predictive service should be substituted if guaranteed is not offered. This idea exacerbates the merging problems described above. In addition, and perhaps more importantly, we believe it places the responsibility for selecting replacements in the wrong hands. Since the quality of service provided by best-effort and controlled delay services will likely depend a great deal on the ambient load conditions, the local router is much better equipped to make the decision about whether or not a given service can function as a reasonable replacement (if the router knows about the service). There may be a few exceptional cases where a particular application requirement would suggest a different substitution, but we are not convinced that such occurrences outweigh the considerable additional complexity such specific reservation scripts would introduce. A more limited but similar alternative we considered is to include an explicit list of services in the reservation request. Upon receiving a reservation request, a router would scan the list of requested services until finding the first one that it knows about. It would then process the request as a request for this service. If this service is known, but not offered, the router would substitute a replacement; it does not continue to scan the list of services for one it offers. Thus, receiver specified replacement services are used only when the router does not know about the receiver's first choice service; in all other cases, the decision about replacement services is left to the router. Since it is specifically in situations where services are not known that routers lack sufficient information to make intelligent decisions about replacement services, this limited control exerted by the receiver might be useful. The options discussed above vary in the amount of functionality and flexibility they allow and in what entity, either the router or application, exerts control over the use of replacement services. Another approach would be for the working group to mandate router behavior when requested services are not offered. For example, the working group could define specific services as replacements for others and mandate that routers always use these defined substitutes when services are not offered. We view this as inferior to our proposal as it places the control over replacements in the wrong Breslau/Shenker Expires 5/15/96 [Page 16] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 hands. As mentioned previously, the suitability of one service to act as a replacement for another depends in some cases on the environment in which it is deployed. Lacking information about where a service is deployed, the working group cannot make appropriate decisions. For example, best effort service may in many circumstances be an adequate replacement for other services. However, given that it can also be arbitrarily bad, the working group could not define it as an acceptable replacement for any real time service. As an alternative to specifying replacement services, the working group could mandate a uniform router behavior when services are not offered. For example, the working group could require a default action of providing best effort service when a service is not offered. While inviting because of its simplicity, we rejected this approach because it does not give enough control to applications. Specifically, it does not satisfy those applications that desire a strong assurance that an actual service, or a close facsimile of it, will be used. Discussion In this section, we touch on three issues in the integrated services architecture that are relevant to this proposal. We stated earlier that this proposal only attempts to solve the problem of what to do when a requested service is not offered. We did not address the question of what to do when a requested service is offered, but not available. The latter problem is the subject of discussion within the RSVP working group. Various issues and solutions discussed in that context are similar to those we considered. For instance, upon an admission control failure, some applications may want an error message returned to them, while others may prefer to receive best effort service at the node in question while their original request is propagated to other nodes. This is similar to the choice of returning an error message or using the best replacement service when a requested service is not offered. The mechanisms needed to provide this functionality in the two contexts are similar. We confined the current discussion to the problem of heterogeneity. However, since the two problems are related, their eventual solutions ought to fit into a unifying framework. Within the Internet community, there is still a vigorous debate about whether the overprovisioning of best-effort links is a reasonable real-time architecture. Our proposal to accommodate heterogeneity in the set of offered services would allow such overprovisioned best- effort networks to compete with networks supporting real-time Breslau/Shenker Expires 5/15/96 [Page 17] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 services. That is, an over-provisioned network providing only best effort service could characterize this best effort service as a reliable replacement for real-time services. Different service providers can thus experiment with different ways of meeting application needs without changing the service model. We think this is crucial in allowing us to learn while the Internet evolves. Finally, we note that even among those supporting the standardization and deployment of real-time services, debate over the nature and number of these services continues. We believe that heterogeneity will be an issue, regardless of what service model is defined for real-time services. Even if only a single type of real-time service were to be specified, this service will not be universally deployed. Some routers will offer it and others will not. However, we expect that the requirements of real-time applications differ enough to warrant multiple types of real-time service, each geared towards supporting different classes of applications. Multiple classes of service, none of which will be offered everywhere, only serves to compound the problem of heterogeneity. Specific Recommendations We recommend the following approach be adopted. For each service for which the element offers a strictly better replacement, the element must also support the lesser service (by providing characterization values for it, and making ordered substitutions of the service requests). For each service it knows about but does not offer, a router should select a suitable replacement service. The router should characterize the replacement as reliable or unreliable. For each known service, a router should export information about whether it offers the service, whether it offers a reliable replacement, or whether it offers no reliable replacement. A router should attempt to export useful characterization parameters for each service it replaces. These parameters should reflect, as much as possible, the service the router provides. When the router is unable to export a meaningful value for a characterization parameter, it sets the validity bit associated with that characterization parameter. Setup protocols, or other mechanisms, may be used to collect characterization information about end-to-end service availability and about the characteristics of the resulting service. Breslau/Shenker Expires 5/15/96 [Page 18] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 Service requests should be augmented to include a single service replacement handling bit. Service replacements are allowed when the bit is set. They are not allowed when the bit is not set. Applications should set the bit according to their requirements. Applications that receive end-to-end characterizations about service availability should always set the bit on indicating that replacements are allowed. If they are not satisfied with the replacements that would be made, they should not issue a service request. When merging two service requests with different values for the replacement handling bit, the router should turn the bit off, indicating that replacements are not allowed. When a router receives a request for a service it does not offer, it rejects the request if the replacement handling bit is off. If the bit is on, the router should treat the request as a request for its best replacement for the requested service. If the replacement service uses admission control, the router should apply an admission control decision. If the admission control test fails, the request is rejected. The router's replacement does not affect the original request if it is propagated to other routers by a setup protocol. When a router receives a request for a service it does not know about, it should use best effort as a replacement service, if the replacement handling bit is on. Otherwise it should reject the request. This proposal has some deficiencies when end-to-end characterizations are not available. However, providing better behavior in this case requires substantial additional complexity, so we deem it advisable to first observe the extent to which end-to-end characterizations become part of the integrated services architecture. If these characterizations become ubiquitously available, then this handling bit will become a vestigial relic and we will have avoided the additional complexity. If end-to-end characterizations are rarely provided, then we will have to see how serious an impediment the error handling deficiencies are. Security Considerations Security considerations are not discussed in this memo. Breslau/Shenker Expires 5/15/96 [Page 19] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 References [1] S. Shenker and L. Breslau. "Two Aspects of Reservation Establishment", Proceedings of Sigcomm '95. [2] S. Shenker and J. Wroclawski. "Network Element Service Specification Template", Internet Draft, June 1995, [3] S. Shenker, C. Partridge, and J. Wroclawski. "Specification of Controlled Delay Quality of Service", Internet Draft, ?? 1995, [4] S. Shenker and C. Partridge. Specification of Guaranteed Quality of Service", Internet Draft, ?? 1995, [5] S. Shenker, C. Partridge, B. Davie, and L. Breslau. "Specification of Predictive Quality of Service", Internet Draft, ?? 1995, Author's Address: Lee Breslau Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 shenker@parc.xerox.com 415-812-4402 415-812-4471 (FAX) Scott Shenker Xerox PARC 3333 Coyote Hill Road Palo Alto, CA 94304-1314 shenker@parc.xerox.com 415-812-4840 415-812-4471 (FAX) Breslau/Shenker Expires 5/15/96 [Page 20] INTERNET-DRAFT draft-ietf-intserv-hetero-01.txt Nov. 1995 Breslau/Shenker Expires 5/15/96 [Page 21]