rfc1193.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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