rfc1193.txt

RFC 的详细文档！

   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]