doc: Add RFC documents

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