rfc1193.txt

RFC 的详细文档！

                 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