diff options
Diffstat (limited to 'doc/rfc/rfc1193.txt')
| -rw-r--r-- | doc/rfc/rfc1193.txt | 1347 |
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc1193.txt b/doc/rfc/rfc1193.txt new file mode 100644 index 0000000..a5d61f4 --- /dev/null +++ b/doc/rfc/rfc1193.txt @@ -0,0 +1,1347 @@ + + + + + + +Network Working Group D. Ferrari +Request for Comments: 1193 UC Berkeley + November 1990 + + + + CLIENT REQUIREMENTS FOR REAL-TIME COMMUNICATION SERVICES + +Status of this Memo + + This memo describes client requirements for real-time communication + services. This memo provides information for the Internet community, + and requests discussion and suggestions for improvements. It does + not specify any standard. Distribution of this memo is unlimited. + +Abstract + + A real-time communication service provides its clients with the + ability to specify their performance requirements and to obtain + guarantees about the satisfaction of those requirements. In this + paper, we propose a set of performance specifications that seem + appropriate for such services; they include various types of delay + bounds, throughput bounds, and reliability bounds. We also describe + other requirements and desirable properties from a client's + viewpoint, and the ways in which each requirement is to be translated + to make it suitable for lower levels in the protocol hierarchy. + Finally, we present some examples of requirements specification, and + discuss some of the possible objections to our approach. + + This research has been supported in part by AT&T Bell Laboratories, + the University of California under a MICRO grant, and the + International Computer Science Institute. The views and conclusions + in this document are those of the author and should not be + interpreted as representing official policies, either expressed or + implied, of any of the sponsoring organizations. + +1. Introduction + + We call real-time a computer communication service whose clients are + allowed to specify their performance requirements and to obtain + guarantees about the fulfillment of those requirements. + + Three terms in this definition need further discussion and + clarification: clients, performance, and guarantees. + + Network architecture usually consists, at least from a logical + viewpoint, of a stack of protocol layers. In the context of such an + architecture, the notions of client and server apply to a number of + + + +Ferrari [Page 1] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + different pairs of entities: every layer (with the support of the + underlying layers) provides a service to the layer immediately above + it and is a client of its underlying layers. In this paper, our + considerations generally apply to any client-server pair. However, + most of them particularly refer to human clients (users, programmers) + and to the ways in which such clients express their communication and + processing needs to the system (e.g., interactive commands, + application programs). This type of client is especially important, + since client needs at lower layers can be regarded as translations of + the needs expressed by human clients at the top of the hierarchy. + When the client is human, the server consists of the entire + (distributed) system, including the hosts, their operating systems, + and the networks interconnecting them. + + As for the generic term, performance, we will give it a fairly broad + meaning. It will include not only delay and throughput, the two main + network performance indices, but also reliability of message + delivery. Real-time communication is concerned with those aspects of + quality of service that have to do with performance in this broad + sense. + + The term guarantee in this paper has a rather strong legal flavor. + When a server guarantees a given level of performance for the + communications of a client, it commits itself to providing that + performance and to paying appropriate penalties if the actual + performance turns out to be insufficient. On the other hand, the + client will have to obey certain rules, and will not be entitled to + the requested performance guarantees unless those rules are + scrupulously obeyed. In other words, client and server have to enter + into a contract specifying their respective rights and duties, the + benefits that will accrue, the conditions under which those benefits + will materialize, and the penalties they will incur for not keeping + their mutual promises. We believe that a legal viewpoint is to be + adopted if serious progress in the delivery of communication services + (not only the real-time ones) is desired. Utility services, as well + as other kinds of service, are provided under legally binding + contracts, and a mature computer communication utility cannot fail to + do the same. In the field of real-time communication, such a + contract will by definition include performance guarantees. + + Real-time services may be offered in any kind of network or + internetwork. Some of their predictable applications are: + + (a) digital continuous-media (motion video, audio) + communication: lower bounds on throughput and upper bounds + on delay or delay variability or both are needed to ensure + any desired level of output quality; in the interactive case, + both the values of delay and delay variabilities have to be + + + +Ferrari [Page 2] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + bounded; some limited message losses are often tolerable in + the cases of video and voice (whenever very high quality is + not required), but usually not in the case of sound; + + (b) transmission of urgent messages in real-time distributed + systems: delay bounds are the important guarantees to be + provided in these applications; losses should ideally be + impossible; + + (c) urgent electronic-mail messages and, more in general, + urgent datagrams: again, delay is the obvious index to be + bounded in this case, but small probabilities of losses can + often be tolerated; + + (d) transfers of large files: minimum throughput bounds are + usually more important than delay bounds in this + application; also, all pieces of a file must be delivered + with probability 1; + + (e) fast request-reply communication: e.g., data base queries, + information retrieval requests, remote procedure calls; this + is another case in which delay (more precisely, round-trip + delay) is the index of primary interest; reliability + requirements are generally not very stringent. + + We conjecture that, when networks start offering well-designed and + reasonably-priced real-time services, the use of such services will + grow beyond the expectations of most observers. This will occur + primarily because new performance needs will be induced by the + availability of guaranteed-performance options. As the history of + transportation and communication has repeatedly shown, faster + services bring about major increases of the shipments that are + perceived as urgent. The phenomenon will be more conspicuous + whenever the quality of service provided to non-real-time clients + will deteriorate. It is clear from this comment that we assume that + real-time services will coexist within the same networks and + internetworks with non-real-time communications. Indeed, postulating + a world in which the two types of service are segregated rather than + integrated would be unrealistic, as it would go against the clear + trend towards the eventual integration of all information services. + For the same reason, the traffic in the network is assumed to be + heterogeneous, i.e., to consist of a variety of types of messages, + representing a variety of information media and their combinations, + with a wide spectrum of burstiness values (from uncompressed + continuous fixed-rate streams to very short and erratic bursts of + information). + + This paper discusses the client requirements and characteristics of a + + + +Ferrari [Page 3] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + real-time communication service. Server requirements and design + principles will be the subject of a subsequent paper. Section 2 + contains some considerations about the ways in which the clients + specify their requirements, and those in which a server should reply + to requests for real-time services. Performance requirements are + presented in Section 3; other properties that clients may need or + desire are described in Section 4. Section 5 deals with the problem + of translating the requirements of a human client or an application + for the equivalent lower-level ones. In Section 6, we briefly + present four examples of client requirement specifications, and in + Section 7 we discuss some of the objections that can be raised + against our approach. + +2. Client Requests and Server Replies + + No real-time service can be provided if the client does not specify, + together with the requirements, the characteristics of the expected + input traffic. Describing input traffic and all the various + requirements entails much work on the part of a client. Gathering + the necessary information and inputting it may be very time- + consuming. A well-designed real-time communication service will + minimize the effort to be spent by a client. + + Sensible default values, the possibility of partial or incremental + specifications (e.g., by editing preexisting specifications), and a + number of standard descriptions should be provided. These + descriptions will include characterizations of inputs (e.g., those of + a video stream for multimedia conferencing, an HDTV stream, a hi-fi + audio stream, a file transfer stream, and so on) and standard sets of + requirements. With these aids, it might be possible for a human + client to specify his or her request by a short phrase, perhaps + followed by a few characters representing options or changes to the + standard or default values. + + Since requests for real-time services may be denied because of a + mismatch between the client's demands and the resources available to + the server, the client will appreciate being informed about the + reasons for any rejection, so that the request can be modified and + resubmitted, or postponed, or cancelled altogether [Herr89]. The + information provided by the server to a human client should be + meaningful, useful, and non-redundant. The reason for rejection + should be understandable by the client (who should be assumed not to + know any of the details of the operating system, of the protocols or + of the network) and should be accompanied by data that will be useful + to the client in deciding what to do as well as how the request ought + to be modified to make it successful. If, for example, a bound + specified by the client cannot be guaranteed by the server under its + current load, the information returned to the client should include + + + +Ferrari [Page 4] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + the minimum or maximum value of the bound that the server could + guarantee; the client will thus be able to decide whether that bound + would be acceptable (possibly with some other modifications as well) + or not, and act accordingly. + + When the client is not a human being but an application or a process, + the type of a server's replies should be very different from that + just described [Herr89]; another standard interface, the one between + an application and a real-time service, must therefore be defined, + possibly in multiple, application-specific versions. + + Clients will also be interested in the pricing policies implemented + by the server: these should be fair (or at least perceived to be + fair) and easy to understand. The client should be able easily to + estimate charges for given performance guarantees as a function of + distance, time of day, and other variables, or to obtain these + estimates from the server as a free off-line service. + +3. Performance Requirements + + A client can specify a service requirement using the general form + + pred = TRUE, + + where some of the variables in predicate pred can be controlled or + influenced by the server. + + A simple and popular form of performance requirement is that + involving a bound. A deterministic bound can be specified as + + (var <= bound) = TRUE, or var <= bound, + + where variable var is server-controlled, while bound is client- + specified. The bounds in these expressions are upper bounds; if < + is replaced by > , they become lower bounds. + + When the variable in the latter expression above is a probability, we + have a statistical bound, and bound in that case is a probability + bound; if the predicate is a deterministic bound, we have: + + Prob (var <= bound) >= probability-bound. + + In this requirement, the variable has an upper bound, and the + probability a lower bound. Note that deterministic bounds can be + viewed as statistical bounds that are satisfied with probability 1. + + A form of bound very similar to the statistical one is the fractional + bound: + + + +Ferrari [Page 5] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + Ca (var <= bound) >= b, + + where variable var has a value for each message in a stream, and Ca + is a function that counts the number of times var satisfies the bound + for any a consecutive messages in the stream; this number Ca must + satisfy bound b. Obviously, a fractional bound is realizable only if + b <= a . Fractional bounds will not be explicitly mentioned in the + sequel, but they can be used in lieu of statistical bounds, and have + over these bounds the avantages of easy verifiability and higher + practical interest. + + In this section, we restrict our attention to those requirements that + are likely to be the most useful to real-time clients. + +3.1 Delay requirements + + Depending on the application, clients may wish to specify their delay + requirements in different ways [Gait90]. The delays involved will + usually be those of the application-oriented messages known to the + client; for instance, the delay between the beginning of the client- + level transmission of a video frame, file, or urgent datagram and the + end of the client-level reception of the same frame, file, or urgent + datagram. (In those cases, e.g., in some distributed real-time + systems, where message deadlines are assigned instead of message + delays, we can always compute the latter from knowledge of the former + and of the sending times, thereby reducing ourselves again to a delay + bound requirement.) Also, they will be the delays of those messages + that are successfully delivered to the destination; the fraction of + messages that are not, to which the delay bounds will not apply, will + be bounded by reliability specifications. Note that clients will + express delay bounds by making implicit reference to their own + clocks; the design of a real-time service for a large network will + have to consider the impact on bounds enforcement of non-synchronized + clocks [Verm90]. Some of the forms in which a delay requirement may + be specified are + + (i) deterministic delay bound: + + Di <= Dmax for all i, + + the client is delivered to the destination client-level entity, and + Dmax is the delay upper bound specified by the client. In our + descriptions we assume, without loss of generality, that the client + requesting a real-time service is the sending client, and that the + destination (which could be a remote agent of the client or another + user) is a third party with respect to the establishment of the + particular communication being considered (In our descriptions we + assume, without loss of generality, that the client requesting a + + + +Ferrari [Page 6] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + real-time service is the sending client, and that the destination + (which could be a remote agent of the client or another user) is a + third party with respect to the establishment of the particular + communication being considered.); + + (ii) statistical delay bound: + + Prob ( Di <= Dmax ) >= Zmin, + + where Di and Dmax are defined as above, and Zmin is the lower + bound of the probability of successful and timely delivery; + + (iii) deterministic delay-jitter bound: + + Ji = | Di - D | <= Jmax for all i, + + where D is the ideal, or target delay, Ji is the delay jitter of + the i-th message delivered to the destination, and Jmax is the + upper jitter bound to be specified by the client together with D; + note that an equivalent form of this requirement consists of + assigning a deterministic upper bound D + Jmax and a deterministic + lower bound D - Jmax to the delays Di [Herr90]; + + (iv) statistical delay-jitter bound: + + Prob (Ji <= Jmax) >= Umin, for all i, + + where Umin is the lower bound of the probability that Ji be + within its limits. + + Other forms of delay bound include bounds on average delay, delay + variance, and functions of the sequence number of each message, for + example, Dmax(i) for the deterministic case. There may be + applications in which one of these will be the preferred form, but, + since we have not found any so far, we believe that the four types of + bounds listed as (i)-(iv) above will cover the great majority of the + practical cases. + +3.2 Throughput requirements + + The actual throughput of an information transfer from a source to a + destination is bounded above by the rate at which the source sends + messages into the system. Throughput may be lower than this rate + because of the possibility of unsuccessful delivery or message loss. + It is also bounded above by the maximum throughput, which is a + function of, among other things, network load. As the source + increases its input rate, the actual throughput will grow up to a + limit and then stop. Clients concerned with the throughput of their + + + +Ferrari [Page 7] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + transfers will want to make sure that saturation is never reached, or + is reached only with a suitably small probability and for acceptably + short intervals. Also, if the bandwidth allocated to a transfer is + not constant, but varies dynamically on demand to accommodate, at + least to some extent, peak requests, clients will be interested in + adding an average throughput requirement, which should include + information about the length of the interval over which the average + must be computed [Ferr89a]. + + Thus, reasonable forms for throughput requirements appear to be the + following: + + (i) deterministic throughput bound: + + Ti >= Tmin, for all i, + + where Ti is the throughput actually provided by the server, and + Tmin is the lower bound of throughput specified by the client, + that is, the minimum throughput the server must offer to the + client; + + (ii) statistical throughput bound: + + Prob (Ti >= Tmin) >= Vmin, + + where Ti and Tmin are defined as above, and Vmin is the lower + bound of the probability that the server will provide a throughput + greater than the lower bound; + + (iii) average throughput bound: + + T >= Tave, + + where T is the average throughput provided by the server, Tave is + its lower bound specified by the client, and both variables are + averaged over an interval of duration I specified by the client; + the above inequality must obviously hold for all intervals of + duration I, i.e., even for that over which T is minimum. + + One clear difference between delay bounds and throughput bounds is + that, while the server is responsible for delays, the actual + throughputs of a non-saturated system are dictated by the input + rates, which are determined primarily by the clients (though they may + be influenced by the server through flow-control mechanisms). + + + + + + + +Ferrari [Page 8] + +RFC 1193 Requirements for Real-Time Services November 1990 + + +3.3 Reliability requirements + + The usefulness of error control via acknowledgments and + retransmission in real-time applications is doubtful, especially in + those environments where message losses are usually higher, i.e., in + wide-area networks: the additional delays caused by acknowledgment + and retransmission, and out-of-sequence delivery are likely to be + intolerable in applications with stringent delay bounds, such as + those having to do with continuous media. Fortunately, the loss of + some of the messages (e.g., video frames, voice packets) is often + tolerable in these applications, but that of sound packets is + generally intolerable. In other cases, however, completeness of + information delivery is essential (e.g., in file transfer + applications), and traditional retransmission schemes will probably + have to be employed. + + A message may be incorrect when delivered or may be lost in the + network, i.e., not delivered at all. Network unreliability (due, for + example, to noise) is usually the cause of the former problem; buffer + overflow (due to congestion) or node or link failure are those of the + latter. The client is not interested in this distinction: for the + client, the message is lost in both cases. Thus, the simplest form + in which a reliability bound may be expressed and also, we believe, + the one that will be most popular, is + + Prob (message is correctly delivered) >= Wmin, + + where Wmin is the lower bound of the probability of correct delivery, + to be specified by the client. The probability of message loss will + obviously be bounded above by 1 - Wmin. This is a statistical bound, + but, as noted in Section 3, a deterministic reliability bound results + if we set Wmin = 1. + + In those applications in which any message delivered with a delay + greater than Dmax must be discarded, the fraction of messages usable + by the destination will be bounded below by Wmin Zmin. The client + may actually specify the value of this product, and let the server + decide the individual values of the two bounds, possibly subject to a + client-assigned constraint, e.g., that the price of the service to + the client be minimum. + + If the value of Wmin is greater than the system's reliability (the + probability that a delivered message is correct), then there is no + buffer space allocation in the hosts, interfaces, switches and + routers or gateways that will allow the client-specified Wmin to be + guaranteed. In this case, the server uses error correcting codes, or + (if the application permits) retransmission, or duplicate messages, + or (if the sequencing problem discussed in Section 4.1 can be solved + + + +Ferrari [Page 9] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + satisfactorily or is not a problem) multiple physical channels for + the same logical channel, or has to refuse the request. + +4. Other Required or Desirable Properties + + In this section, we briefly describe client requirements that cannot + be easily expressed as bounds on, but are related to, communication + performance. These include sequencing, absence of duplications, + failure recovery, and service setup time. We are not concerned here + with features that may be very important but have a functionality + (e.g., multicast capabilities) or security (e.g., client + authentication) rather than a performance flavor. Requirements in + these areas will generally have appreciable effects also on + performance; we do not discuss them only because of space + limitations. + + For a given application, some of these properties may be required, + some others only desirable. Also, some may be best represented as + Boolean variables (present or absent), some others as continuous or + multi-valued discrete variables, others yet as partially qualitative + specifications. + +4.1 Sequencing + + For applications involving message streams (rather than single + datagrams), it may be necessary or desirable that messages be + delivered in sequence, even though the sequence may not be complete. + If the lower-level servers are not all capable of delivering messages + sequentially, a resequencing operation may have to be performed at + some higher level in the hierarchy. In those cases in which + reliability requirements make retransmission necessary, resequencing + may delay delivery of a large number of messages by relatively long + times. An adequate amount of buffer space will have to be provided + for this purpose at the level of the resequencer in the protocol + hierarchy. + + If sequencing is not guaranteed by all servers at all levels, the + application may be able to tolerate out-of-sequence messages as long + as their number is small, or if the delay bound is so large that very + few out-of-sequence messages have to be discarded because they are + too late. The client could be allowed to specify a bound on the + probability that a message be delivered out of sequence, or to bundle + out-of-sequence losses with the other types of message loss described + by Wmin. The client would specify the value of Wmin (or Wmin Zmin), + and the server would have to decide how much probability to allow for + buffer overflow, how much for network error, and how much for + imperfect sequencing, taking into account the stringency of the delay + bounds. + + + +Ferrari [Page 10] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + On the other hand, with fixed-route connections and appropriate + queueing and scheduling in the hosts and in the network, it is often + not too hard to ensure sequenced delivery at the various layers, + hence also at the top. + +4.2 Absence of duplications + + Most of the discussion of sequencing applies also to duplication of + messages. It is, however, easier and faster to eliminate + duplications than to resequence, as long as some layer keeps track of + the sequence numbers of the messages already received. The + specification of a bound may be needed only if duplications become + very frequent, but this would be a symptom of serious network + malfunction, and should not be dealt with in the same way as we + handle delays or message losses. These observations do not apply, of + course, to the case of intentional duplication for higher + reliability. + +4.3 Failure recovery + + The contract between client and server of a real-time service will + have to specify what will happen in the event of a server failure. + Ideally, from the client's viewpoint, failures should be perfectly + masked, and service should be completely fault-tolerant. As we have + already mentioned, however, it is usually unrealistic to expect that + performance guarantees can be honored even in presence of failures. + A little less unrealistic is to assume that service can resume a + short time after a failure has disrupted it. In general, clients may + not only wish to know what will happen if a failure occurs, but also + have a guaranteed upper bound on the likelihood of such an + occurrence: + + Prob (failure) <= Fmax. + + Different applications have different failure recovery requirements. + Urgent datagrams or urgent message streams in most real-time + distributed systems will probably not benefit much from recovery, + unless it can be made so fast that hard deadlines may still be + satisfied, at least in some cases. In the case of video or audio + transmission, timely resumption of service will normally be very + useful or even necessary; thus, clients may need to be given + guarantees about the upper bounds of mean or maximum time to repair; + this may also be the case of other applications in which the + deadlines are not so stringent, or where the main emphasis is on + throughput and/or reliability rather than on delay. + + In communications over multi-node routes and/or long distances, the + network itself may contain several messages for each source- + + + +Ferrari [Page 11] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + destination pair at the time a failure occurs. The recovery scheme + will have to solve the problems of failure notification (to all the + system's components involved, and possibly also to the clients) and + disposition of messages in transit. The solutions adopted may make + duplicate elimination necessary even in contexts in which no + duplicates are ever created in the absence of failures. + +4.4 Service setup time + + Real-time services must be requested before they can be used to + communicate [Ferr89b]. Some clients may be interested in long-term + arrangements which are set up soon after the signing of a contract + and are kept in existence for long times (days, months, years). + Others, typically for economical reasons, may wish to be allowed to + request services dynamically and to avoid paying for them even when + not in use. The extreme case of short-term service is that in which + the client wants to send one urgent datagram, but this is probably + best handled by a service broker ("the datagraph office") using a + permanent setup shared by many (or all) urgent datagrams. In most + other cases, a request for a short-term or medium-term service must + be processed by the server before the client is allowed to receive + that service (i.e., to send messages). Certain applications will + need the setup time to be short or, in any case, bounded: the maximum + time the client will have to wait for a (positive or negative) reply + to a request may have to be guaranteed by the server in the contract. + +5. Translating Requirements + + Performance specifications and other requirements are assigned at the + top level, that of the human client or application, either explicitly + or implicitly (see Section 2). To be satisfied, these specifications + need the support of all the underlying layers: we believe that a + real-time service cannot be implemented on top of a server at some + level that is unable to guarantee performance. (Some of the other + requirements can be satisfied even without this condition: for + example, reliable delivery (when retransmission is acceptable) and + sequencing.) Upper-level requirements must be translated into + lower-level ones, so that the implementation of the former will be + adequately supported. How should this be done? + +5.1 Delay requirements + + The method for translating delay bounds macroscopically depends on + the type of bound to be translated. All methods have to deal with + two problems: the effects of delays in the individual layers, and the + effects of message fragmentation on the requirements. + + (i) Deterministic delay bound. A deterministic bound on the delay + + + +Ferrari [Page 12] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + encountered by a message in each layer (or group of layers) in + the hosts will have to be estimated and enforced. + The delay bound for a server at a given level will be obtained + by subtracting the delay bounds of the layers above it in both + the sending and the receiving host from the original global + bound: + + Dmax' = Dmax - SUMi {d(max,i)}. + + Message fragmentation can be handled by recalling that delay is + defined as the difference between the instant of completion of the + reception of a message and the instant when its shipment began. + If x is the interfragment time (assumed constant for simplicity + here) and f is the number of fragments in a message, we have + + Dmax' = Dmax - x(f-1), + + where Dmax' is the fragment delay bound corresponding to the + message delay bound Dmax, i.e., the delay of the first fragment. + + (ii) Statistical delay bound. The statistical case is more + complicated. If the bounds on the delay in each layer + (or group of layers) are statistical, we may approach the + problem of the messages delayed beyond the bound + pessimistically, in which case we shall write + + Zmin' = Zmin / (PRODi {z(min,i)}), + + + where the index i spans the layers (or group of layers) above the + given lower-level server, Zmin' is the probability bound to be + enforced by that lower-level server, and d(max,i) and z(min,i) are + the bounds for layer i. (A layer has a sender side and a receiver + side at the same level in the hierarchy.) The expression for + Zmin' is pessimistic because it assumes that a message delayed + beyond its bound in a layer will not be able to meet the global + bound Dmax. (The expression above and the next one assume that + the delays of a message in the layers are statistically + independent of each other. This assumption is usually not valid, + but, in the light of the observations that follow the next + expression, the error should be tolerable.) + + At the other extreme, we have the optimistic approach, which + assumes that a message will not satisfy the global bound only if + it is delayed beyond its local bound in each layer: + + Zmin' = 1 - (1 - Zmin)/(PRODi {1 - z(min,i)}). + + + + +Ferrari [Page 13] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + The correct assumption will be somewhere in between the + pessimistic and the optimistic ones. However, in order to be able + to guarantee the global bound, the system will have to choose the + pessimistic approach, unless a better approximation to reality can + be found. An alternative that may turn out to be more convenient + is the one of considering the bounds in the layers as + deterministic, in which case Zmin' will equal Zmin, and the global + bound will be statistical only because the network will guarantee + a statistical bound. + + When estimating the effects of message fragmentation, the new + bounds must refer to the fragment stream as though its components + were independent of each other. Assuming sequential delivery of + fragments, a message is delayed beyond its bound if its last + fragment is delayed beyond the fragment bound. Our goal can be + achieved by imposing the same probability bound on fragments as on + messages [Verm90]. Thus, + + Zmin' = Zmin. + + Note that both expressions for D prime sub max given in (i) above + apply to the statistical delay bound case as well. + + (iii) Deterministic delay-jitter bound. For the case of layer to + layer translation, the discussion above yields: + + Jmax' = Jmax - SUMi {j(max,i)} , + + where j(max,i) is the deterministic jitter bound of the i-th layer + above the given lower-level server. When messages are fragmented, + the delay jitter bound can be left unchanged: + + Jmax' = Jmax . + + There would be reasons to reduce it in the case of message + fragmentation only if the underlying server did not guarantee + sequenced delivery, and if no resequencing of fragments were + provided by the corresponding reassembly layer on the receiving + side. + + (iv) Statistical delay-jitter bound. The interested reader will + be able with little effort to derive the translation formulas + for this case from the definition in Section 3.1 (iv) + and from the discussion in (ii) and (iii) above. + + + + + + + +Ferrari [Page 14] + +RFC 1193 Requirements for Real-Time Services November 1990 + + +5.2 Throughput requirements + + Since all layers are in cascade, the throughput bounds would be the + same for all of them if headers and sometimes trailers were not added + at each layer for encapsulation or fragmentation. Thus, throughput + bounds have to be increased as the request travels downward through + the protocol hierarchy, and the server at each layer knows by how + much, since it is responsible for these additions. + +5.3 Reliability requirements + + If we assume, quite realistically, that the probability of message + loss in a host is extremely small, then we do not have to change the + value of Wmin when we change layers. + + The effects of message fragmentation are similar to those on + statistical delay bounds, but in a given application a message may be + lost even if only one of its fragments is lost. Thus, we have + + Wmin' = 1 - (1 - Wmin)/f , + + where Wmin' is the lower bound of the correct delivery probability + for the fragment stream, and f is the number of fragments per + message. The optimistic viewpoint, which is the one we adopted in + Section 5.1 (ii), yields Wmin' = Wmin, and the observations made in + that section about the true bound and about providing guarantees + apply. + +5.4 Other requirements + + Of the requirements and desiderata discussed in Section 4, those that + are specified as a Boolean value or a qualitative attribute do not + have to be modified for lower-level servers unless they are satisfied + in some layer above those servers (e.g., no sequencing is to be + required below the level where a resequencer operates). When they + are represented by a bound (e.g., one on the setup time, as described + in Section 4.4), then bounds for the layers above a lower-level + server will have to be chosen to calculate the corresponding bound + for that server. The above discussions of the translation of + performance requirements will, in most cases, provide the necessary + techniques for doing these calculations. + + The requirement that the server give clear and useful replies to + client requests (see Section 2) raises the interesting problem of + reverse translation, that from lower-level to upper-level + specifications. However, at least in most cases, this does not seem + to be a difficult problem: all the translation formulas we have + written above are very easily invertible (in other words, it is + + + +Ferrari [Page 15] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + straightforward to express Dmax as a function of Dmax', Zmin as a + function of Zmin', and so on). + +6. Examples + + In this section we describe some examples of client requirements for + real-time services. Simplifying assumptions are introduced to + decrease the amount of detail and increase clarity. Our intent is to + determine the usefulness of the set of requirements proposed above, + and to investigate some of the problems that may arise in practical + cases. An assumption underlying all examples is that the network's + transmission rate is 45 Mbits/s, and that the hosts can keep up with + this rate when processing messages. + +6.1 Interactive voice + + Let us assume that human clients are to specify the requirements for + voice that is already digitized (at a 64 kbits/s rate) and packetized + (packet size: 48 bytes, coinciding with the size of an ATM cell; + packet transmission time: 8.53 microseconds ; packet interarrival + time: 6 ms). Since the communication is interactive, deterministic + (and statistical) delay bounds play a very important role. Jitter is + also important, but does not dominate the other requirements as in + non-interactive audio or video communication (see Section 6.2). The + minimum throughput offered by the system must correspond to the + maximum input rate, i.e., 64 kbits/s; in fact, because of header + overhead (5 control bytes for every 48 data bytes), total guaranteed + throughput should be greater than 70.66 kbits/s, i.e., 8,834 bytes/s. + (Since the client may not know the overhead introduced by the system, + the system may have to compute this value from the one given by the + client, which in this case would be 8 kbytes/s.) The minimum average + throughput over an interval as long as 100 s is 44% of Tmin, due to + the silence periods [Brad64]. + + Voice transmission can tolerate limited packet losses without making + the speech unintelligible at the receiving end. We assume that a + maximum loss of two packets out of 100 (each packet corresponding to + 6 ms of speech) can be tolerated even in the worst case, i.e., when + the two packets are consecutive. Since packets arriving after their + absolute deadline are discarded if the delay bound is to be + statistical, then this maximum loss rate must include losses due to + lateness, i.e., 0.98 will have to be the value of Zmin Wmin rather + than just that of Wmin. + + This is illustrated in the first column of Table Ia, which consists + of two subcolumns: one is for the choice of a deterministic delay + bound, the other one for that of a statistical delay bound and a + combined bound on the probability of lateness or loss. If in a row + + + +Ferrari [Page 16] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + there is a single entry, that entry is the same for both subcolumns. + Note that the maximum setup time could be made much longer if + connections had to be reserved in advance. + + Since voice is packetized at the client's level, we will not have to + worry about the effects of fragmentation while translating the + requirements into their lower-level correspondents. + +6.2 Non-interactive video + + At the level of the client, the video message stream consists of 1 + Mbit frames, to be transmitted at the rate of 30 frames per second. + Thus, the throughput bounds (both deterministic and average) are, + taking into account the overhead of ATM cell headers, 4.14 Mbytes/s. + As in the case of interactive voice, we have two alternatives for the + specification of delay bounds: the first subcolumn is for the + deterministic bound case, the second for that of a statistical bound + on delays and a combined probability bound on lateness or loss; the + latter bound is set to at most 10 frames out of 100, i.e., three out + of 30. However, the really important bound in this case is the one + on delay jitter, set at 5 ms, which is roughly equal to half of the + interval between two successive frames, and between 1/4 and 1/5 of + the transmission time. This dominance of the jitter bound is the + reason why the other delay bounds are in parentheses. + + If we assume that video frames will have to be fragmented into cells + at some lower level in the protocol hierarchy, then these + requirements must be translated at that level into those shown in the + first column of Table II. The values of Dmax' have been calculated + with x = 12.8 microseconds and f = 2605 fragments/frame. The range + of Wmin' and of (Zmin Wmin)' is quite wide, and achieving its higher + value (a probability of 1) may turn out to be either very expensive + or impossible. We observe, however, that a frame in which a packet + or more are missing or have been incorrectly received does not have + to be discarded but can be played with gaps or patched with the old + packets in lieu of the missing or corrupted ones. Thus, it may be + possible to consider an optimistic approach (e.g., Zmin' = Zmin, + Wmin' = Wmin, (Zmin Wmin)' = Zmin Wmin ) as sufficiently safe. + +6.3 Real-time datagram + + A real-time datagram is, for instance, an alarm condition to be + transmitted in an emergency from one machine to another (or a group + of others) in a distributed real-time system. The client + requirements in this case are very simple: a deterministic bound is + needed (we are assuming that this is a hard-real-time context), the + reliability of delivery must be very high, and the service setup time + should be very small. The value of 0.98 for Wmin in Table Ib tries + + + +Ferrari [Page 17] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + to account for the inevitable network errors and to suggest that + retransmission should not be used as might be necessary if we wanted + to have Wmin = 1, because it would be too slow. To increase + reliability in this case, error correcting codes or spatial + redundancy will have to be resorted to instead. + + Note that one method for obtaining a very small setup time consists + of shipping such urgent datagrams on long-lasting connections + previously created between the hosts involved and with the + appropriate characteristics. Note also that throughput requirements + cannot be defined, since we are dealing with one small message only, + which may not even have to be fragmented. Guarantees on the other + bounds will fully satisfy the needs of the client in this case. + +6.4 File transfer + + Large files are to be copied from a disk to a remote disk. We assume + that the receiving disk's speed is greater than or equal to the + sending disk's, and that the transfer could therefore proceed, in the + absence of congestion, at the speed of the sending disk. The message + size equals the size of one track (11 Kbytes, including disk surface + overhead such as intersector gaps), and the maximum input rate is + 5.28 Mbits/s. Taking into account the ATM cell headers, this rate + becomes 728 kbytes/s; this is the minimum peak throughput to be + guaranteed by the system. The minimum average throughput to be + provided is smaller, due to head switching times and setup delays + (seek times are even longer, hence need not be considered here): we + set its value at 700 kbytes/s. + + Delay bounds are much less important in this example than in the + previous ones; in Table Ib, we show deterministic and statistical + bounds in parentheses. Reliability must be eventually 1 to ensure + the integrity of the file's copy. This result will have to be + obtained by error correction (which will increase the throughput + requirements) or retransmission (which would break most delay bounds + if they were selected on the basis of the first shipment only instead + of the last one). + + The second column in Table II shows the results of translating these + requirements to account for message fragmentation. The values x = + 78.3 microseconds and f = 230 have been used to compute those of + Dmax'. + +7. Discussion + + In this section, we briefly discuss some of the objections that can + be raised concerning our approach to real-time service requirements. + Some of the objections are fundamental ones: they are at least as + + + +Ferrari [Page 18] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + related to the basic decisions to be made in the design of the server + as they are to client requirements. + + Objection 1: Guarantees are not necessary. + + This is the most radical objection, as it stems from a basic + disagreement with our definition of real-time service. The problem, + however, is not with definitions or terminologies: the really + important question is whether a type of service such as the one we + call "real-time" will be necessary or at least useful in future + networks. This objection is raised by the optimists, those who + believe that network bandwidth will be so abundant that congestion + will become a disease of the past, and that delays will therefore be + small enough that the enforcement of legalistic guarantees will not + be necessary. The history of computers and communications, however, + does not unfortunately support these arguments, while it supports + those of the pessimists. In a situation of limited resources + (limited with respect to the existing demand for them), we believe + that there is no serious solution of the real-time communication + problem other than one based on a policy for the allocation of + resources that rigorously guarantees the satisfaction of performance + needs. Even if the approaches to be adopted in practical networks + will provide only approximate guarantees, it is important to devise + methods that offer without exceptions precisely defined bounds. + These methods can at the very least be used as reference approaches + for comparison and evaluation. + + Objection 2: Real-time services are too expensive because reservation + of resources is very wasteful. + + This may be true if resources are exclusively reserved; for example, + physical circuits used for bursty traffic in a circuit-switched + network. There are, however, other ways of building real-time + services, based on priority mechanisms and preemption rather than + exclusive reservation of resources. With these schemes, the real- + time traffic always finds the resources it needs by preempting non- + real-time traffic, as long as the real-time load is kept below a + threshold. The threshold corresponds to the point where the demand + by real-time traffic for the bottleneck resource equals the amount of + that resource in the system. With this scheme, all resources not + used by real-time traffic can be used at any time by local tasks and + non-real-time traffic. Congestion may affect the latter, but not + real-time traffic. Thus, the only limitation is that a network + cannot carry unbounded amounts of real-time traffic, and must refuse + any further requests when it has reached the saturation point. + + + + + + +Ferrari [Page 19] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + Objection 3: Real-time services can be built on top of non-real-time + servers. + + If one accepts our interpretation of the term "guarantee," one can + easily see that performance guarantees cannot be provided by a + higher-level server unless it can rely on real-time support by its + underlying server. Since this is true at all levels, we conclude + that a real-time network service and similar services at all + intermediate levels are needed to provide guaranteed performance to + human clients and applications. + + Objection 4: Delay bounds are not necessary, throughput requirements + suffice. + + Guaranteeing minimum throughput bounds does not automatically and in + general result in any stringent upper bound on delay. Delays in the + hosts and nodes of a packet-switching network fluctuate because of + bursty real-time message streams, starting and ending of traffic on + individual connections (even those with continuous, constant-rate + traffic), and the behavior of scheduling algorithms. Even if delays + did not fluctuate, but had a constant value, it would be possible for + a given throughput bound to be satisfied with many different constant + values for the delay of each message. If delay bounds are wanted, + they must be explicitly guaranteed and enforced. (In a circuit- + switching network, the circuit assigned to a connection has its own + throughput and its own delay. These values may be considered as + explicitly guaranteed and enforced.) + + But are delay bounds wanted? We believe they are in digital video + and audio communication, especially in the form of delay jitter + bounds, and they will be in other contexts as soon as a service which + can bound delays is offered. + + Objection 5: Satisfaction of statistical bounds is impossible to + verify. + + Strictly speaking, this objection is valid. No matter how many + packets on a connection have been delayed beyond their bound (or lost + or delivered with errors), it is always in principle possible for the + server to redress the situation in the future and meet the given + statistical requirements. A more sensible and verifiable bound would + be a fractional one (see Section 3). For instance, such a bound + could be specified as follows: out of 100 consecutive packets, no + less than 97 shall not be late. In this case, the bound is no longer + Zmin, a probability of 0.97, but is given by the two values B = 97 + and A = 100; it is not only their ratio that counts but also their + individual values. + + + + +Ferrari [Page 20] + +RFC 1193 Requirements for Real-Time Services November 1990 + + +8. Conclusion + + This paper has presented a specification of some of the requirements + that human clients and applications may wish to impose on real-time + communications. Though those listed seem to be among the most useful + and natural ones, no attempt has been made to be exhaustive and + comprehensive. + + We have investigated delay bounds, throughput bounds, reliability + bounds, and other requirements. We have studied how the requirements + should be translated from the client's level into forms suitable (and + correct) for lower levels, described some examples of requirement + specification, and discussed some of the objections that may be + raised. + + The material in this paper covers only part of the first phase in the + design of a real-time service: that during which the various + requirements are assembled and examined to extract useful suggestions + for the design of the server. Server needs and design principles + will be the subject of the subsequent paper mentioned several times + above. + +Acknowledgments + + Ralf Herrtwich and Dinesh Verma contributed ideas to, and corrected + mistakes in, a previous version of the manuscript. The author is + deeply indebted to them for their help and for the many discussions + he had with them on the topics dealt with in this paper. The + comments of Ramesh Govindan and Riccardo Gusella are also gratefully + acknowledged. + +References + + [Brad64] Brady, P., "A Technique for Investigating On-Off Patterns + of Speech", Bell Systems Technical Journal, Vol. 44, + Pgs. 1-22, 1964. + + [Ferr89a] Ferrari, D., "Real-Time Communication in + Packet-Switching Wide-Area Networks", Technical Report + TR-89-022, International Computer Science Institute, + Berkeley, May 1989. + + [Ferr89b] Ferrari D., and D. Verma, "A Scheme for Real-Time Channel + Establishment in Wide-Area Networks", IEEE J. Selected + Areas Communications SAC-8, April 1990. + + [Gait90] Gaitonde, S., D. Jacobson, and A. Pohm, "Bounding Delay on + a Multifarious Token Ring Network", Communications of the + + + +Ferrari [Page 21] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + ACM, Vol. 33, No. 1, Pgs. 20-28, January 1990. + + [Herr89] Herrtwich R., and U. Brandenburg, "Accessing and + Customizing Services in Distributed Systems", Technical + Report TR-89-059, International Computer Science Institute, + Berkeley, October 1989. + + [Herr90] Herrtwich, R, personal communication, February 1990. + + [Verm90] Verma, D., personal communication, February 1990. + + + Table Ia + Examples of Client Requirements + + Interactive Non-Interactive + Voice Video + +Delay Bounds +deterministic:Dmax [ms] 200 - (1000) - +statistical:Dmax [ms] - 200 - (1000) + Zmin - (*) - (*) +jitter:Jmax [ms] 1 5 + +Throughput Bounds +deterministic:Tmin [kby/s] 8.834 4140 +average:Tave [kby/s] 3.933 4140 + I [s] 100 100 + +Reliability Bound:Wmin 0.98 (*) (0.90) (*) +Delay&Reliability:ZminWmin - 0.98 - 0.90 + +Sequencing yes yes +Absence of Duplications yes yes +Failure Recovery: + max.repair time [s] 10 100 +Max.Setup Time [s] 0.8 (o) 15 (o) + +---------------------------------- + +(*) To be chosen by the server +(o) Could be much longer if advance reservations were required +(+) Could be achieved by using a preexisting connection + + + + + + + + +Ferrari [Page 22] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + Table Ib + Examples of Client Requirements + + Real-Time File + Datagram Transfer + +Delay Bounds +deterministic:Dmax [ms] 50 - (1500) +statistical:Dmax [ms] - (1000) - + Zmin - (0.95) - +jitter:Jmax [ms] - - + +Throughput Bounds +deterministic:Tmin [kby/s] - 728 +average:Tave [kby/s] - 700 + I [s] - 100 + +Reliability Bound:Wmin 0.98 1 +Delay&Reliability:ZminWmin - - + +Sequencing - yes +Absence of Duplications yes yes +Failure Recovery: + max.repair time [s] - 100 +Max.Setup Time [s] 0 (+) 5 (o) + +---------------------------------- + +(*) To be chosen by the server +(o) Could be much longer if advance reservations were required +(+) Could be achieved by using a preexisting connection + + + + + + + + + + + + + + + + + + + + +Ferrari [Page 23] + +RFC 1193 Requirements for Real-Time Services November 1990 + + + Table II + Translation of the Requirements in Table I + + Non-Interactive File + Video Transfer + +Delay Bounds +deterministic:Dmax' [ms] (966) - - (1482) +statistical:Dmax' [ms] - (966) (982) - + Zmin' - (*) (0.95) - +jitter:Jmax' [ms] 5 - + +Reliability Bound:Wmin' 0.90-1 (*) 1 + +Delay&Reliability:(ZminWmin)' - 0.90-1 - + +_____________________________________ + +(*) To be chosen by the server + + + +Security Considerations + + Security considerations are not discussed in this memo. + +Author's Address + + Domenico Ferrari + University of California + Computer Science Division + EECS Department + Berkeley, CA 94720 + + Phone: (415) 642-3806 + + EMail: ferrari@UCBVAX.BERKELEY.EDU + + + + + + + + + + + + + + +Ferrari [Page 24] +
\ No newline at end of file |