rfc1193.txt

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


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]