rfc1193.txt

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

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.

   Objection 4: Delay bounds are not necessary, throughput requirements
   suffice.

   Guaranteeing minimum throughput bounds does not automatically and in
   general result in any stringent upper bound on delay.  Delays in the
   hosts and nodes of a packet-switching network fluctuate because of
   bursty real-time message streams, starting and ending of traffic on
   individual connections (even those with continuous, constant-rate
   traffic), and the behavior of scheduling algorithms.  Even if delays
   did not fluctuate, but had a constant value, it would be possible for
   a given throughput bound to be satisfied with many different constant
   values for the delay of each message.  If delay bounds are wanted,
   they must be explicitly guaranteed and enforced.  (In a circuit-
   switching network, the circuit assigned to a connection has its own
   throughput and its own delay.  These values may be considered as
   explicitly guaranteed and enforced.)

   But are delay bounds wanted?  We believe they are in digital video
   and audio communication, especially in the form of delay jitter
   bounds, and they will be in other contexts as soon as a service which
   can bound delays is offered.

   Objection 5: Satisfaction of statistical bounds is impossible to
   verify.

   Strictly speaking, this objection is valid.  No matter how many
   packets on a connection have been delayed beyond their bound (or lost
   or delivered with errors), it is always in principle possible for the
   server to redress the situation in the future and meet the given
   statistical requirements.  A more sensible and verifiable bound would
   be a fractional one (see Section 3).  For instance, such a bound
   could be specified as follows: out of 100 consecutive packets, no
   less than 97 shall not be late.  In this case, the bound is no longer
   Zmin, a probability of 0.97, but is given by the two values B = 97
   and A = 100; it is not only their ratio that counts but also their
   individual values.




Ferrari                                                        [Page 20]

RFC 1193          Requirements for Real-Time Services      November 1990


8.  Conclusion

   This paper has presented a specification of some of the requirements
   that human clients and applications may wish to impose on real-time
   communications.  Though those listed seem to be among the most useful
   and natural ones, no attempt has been made to be exhaustive and
   comprehensive.

   We have investigated delay bounds, throughput bounds, reliability
   bounds, and other requirements.  We have studied how the requirements
   should be translated from the client's level into forms suitable (and
   correct) for lower levels, described some examples of requirement
   specification, and discussed some of the objections that may be
   raised.

   The material in this paper covers only part of the first phase in the
   design of a real-time service: that during which the various
   requirements are assembled and examined to extract useful suggestions
   for the design of the server.  Server needs and design principles
   will be the subject of the subsequent paper mentioned several times
   above.

Acknowledgments

   Ralf Herrtwich and Dinesh Verma contributed ideas to, and corrected
   mistakes in, a previous version of the manuscript.  The author is
   deeply indebted to them for their help and for the many discussions
   he had with them on the topics dealt with in this paper.  The
   comments of Ramesh Govindan and Riccardo Gusella are also gratefully
   acknowledged.

References

   [Brad64]  Brady, P., "A Technique for Investigating On-Off Patterns
             of Speech", Bell Systems Technical Journal, Vol. 44,
             Pgs. 1-22, 1964.

   [Ferr89a] Ferrari, D., "Real-Time Communication in
             Packet-Switching Wide-Area Networks", Technical Report
             TR-89-022, International Computer Science Institute,
             Berkeley, May 1989.

   [Ferr89b] Ferrari D., and D. Verma, "A Scheme for Real-Time Channel
             Establishment in Wide-Area Networks", IEEE J. Selected
             Areas Communications SAC-8, April 1990.

   [Gait90]  Gaitonde, S., D. Jacobson, and A. Pohm, "Bounding Delay on
             a Multifarious Token Ring Network", Communications of the



Ferrari                                                        [Page 21]

RFC 1193          Requirements for Real-Time Services      November 1990


             ACM, Vol. 33, No. 1, Pgs. 20-28, January 1990.

   [Herr89]  Herrtwich R., and U. Brandenburg, "Accessing and
             Customizing Services in Distributed Systems", Technical
             Report TR-89-059, International Computer Science Institute,
             Berkeley, October 1989.

   [Herr90]  Herrtwich, R, personal communication, February 1990.

   [Verm90]  Verma, D., personal communication, February 1990.


                                 Table Ia
                    Examples of Client Requirements

                           Interactive  Non-Interactive
                              Voice           Video

Delay Bounds
deterministic:Dmax [ms]    200     -     (1000)    -
statistical:Dmax [ms]       -     200       -    (1000)
            Zmin            -     (*)       -      (*)
jitter:Jmax [ms]               1                5

Throughput Bounds
deterministic:Tmin [kby/s]   8.834            4140
average:Tave [kby/s]         3.933            4140
        I [s]                 100              100

Reliability Bound:Wmin     0.98   (*)     (0.90)   (*)
Delay&Reliability:ZminWmin  -    0.98       -      0.90

Sequencing                    yes              yes
Absence of Duplications       yes              yes
Failure Recovery:
 max.repair time [s]           10              100
Max.Setup Time [s]            0.8 (o)          15 (o)

----------------------------------

(*) To be chosen by the server
(o) Could be much longer if advance reservations were required
(+) Could be achieved by using a preexisting connection








Ferrari                                                        [Page 22]

RFC 1193          Requirements for Real-Time Services      November 1990


                                 Table Ib
                    Examples of Client Requirements

                           Real-Time     File
                            Datagram   Transfer

Delay Bounds
deterministic:Dmax [ms]        50      -   (1500)
statistical:Dmax [ms]           -    (1000)   -
            Zmin                -    (0.95)   -
jitter:Jmax [ms]                -             -

Throughput Bounds
deterministic:Tmin [kby/s]      -          728
average:Tave [kby/s]            -          700
        I [s]                   -          100

Reliability Bound:Wmin        0.98          1
Delay&Reliability:ZminWmin      -           -

Sequencing                      -          yes
Absence of Duplications        yes         yes
Failure Recovery:
 max.repair time [s]            -          100
Max.Setup Time [s]             0 (+)       5 (o)

----------------------------------

(*) To be chosen by the server
(o) Could be much longer if advance reservations were required
(+) Could be achieved by using a preexisting connection




















Ferrari                                                        [Page 23]

RFC 1193          Requirements for Real-Time Services      November 1990


                                Table II
                  Translation of the Requirements in Table I

                           Non-Interactive            File
                                Video               Transfer

Delay Bounds
deterministic:Dmax' [ms]     (966)    -            -    (1482)
statistical:Dmax' [ms]         -    (966)        (982)     -
            Zmin'              -     (*)         (0.95)    -
jitter:Jmax' [ms]                 5                    -

Reliability Bound:Wmin'      0.90-1  (*)               1

Delay&Reliability:(ZminWmin)'  -    0.90-1             -

_____________________________________

(*) To be chosen by the server



Security Considerations

   Security considerations are not discussed in this memo.

Author's Address

   Domenico Ferrari
   University of California
   Computer Science Division
   EECS Department
   Berkeley, CA 94720

   Phone: [phone]

   EMail: [e-mail]














Ferrari                                                        [Page 24]