rfc1193.txt

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

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]