rfc1193.txt

RFC 的详细文档！

   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 ,