rfc1193.txt

RFC 的详细文档！

   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.