rfc2354.txt

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


RFC 2354         Options for Repair of Streaming Media         June 1998


   the bandwidth of a stream.  Media independent FEC is typically the
   next best option, since a single FEC packet has the potential to
   repair multiple lost packets, providing efficient transmission.

   In an interactive session, the delay imposed by the use of
   interleaving and retransmission is not acceptable, and a low-latency
   FEC scheme is the only means of repair suitable.  The choice between
   media independent and media specific forward error correction is less
   clear-cut:  media-specific FEC can be made more efficient, but
   requires modification to the output of the codec.  When defining the
   packet format for a new codec, this is clearly an appropriate
   technique, and should be encouraged.

   If an existing codec is to be used, a media independent forward error
   correction scheme is usually easier to implement, and can perform
   well.  A media stream protected in this way may be augmented with
   retransmission based repair with minimal overhead, providing improved
   quality for those receivers willing to tolerate additional delay, and
   allowing interactivity for those receivers which desire it.  Whilst
   the addition of FEC data to an media stream is an effective means by
   which that stream may be protected against packet loss, application
   designers should be aware that the addition of large amounts of
   repair data when loss is detected will increase network congestion,
   and hence packet loss, leading to a worsening of the problem which
   the use of error correction coding was intended to solve.

   At the time of writing, there is no standard solution to the problem
   of congestion control for streamed media which can be used to solve
   this problem.  There have, however, been a number of contributions
   which show the likely form the solution will take [12, 19].  This
   work typically used some form of layered encoding of data over
   multiple channels, with receivers joining and leaving layers in
   response to packet-loss (which indicates congestion).  The aim of
   such schemes is to emulate the congestion control behavior of a TCP
   stream, and hence compete fairly with non-real time traffic.  This is
   necessary for stable network behavior in the presence of much
   streamed media.

   Since streaming media applications are in use now, without congestion
   control, it is important to give some advice to authors of those
   tools as to the behavior which is acceptable, until congestion
   control mechanisms can be deployed.  The remainder of this section
   uses the throughput of a TCP connection over a link with a given loss
   rate as an example to indicate behavior which may be classified as
   reasonable.

   As a number of authors have noted (eg:  [6]), the loss rate and
   throughput of a TCP connection are approximately related as follows:



Perkins & Hodson             Informational                      [Page 7]

RFC 2354         Options for Repair of Streaming Media         June 1998


    T = (s * c) / (RTT * sqrt(p))

   where T is the observed throughput in octets per second, s is the
   packet size in octets, RTT is the round-trip time for the session in
   seconds, p is the packet loss rate and c is a constant in the range
   0.9...1.5 (a value of 1.22 has been suggested [6]).  Using this
   relation, one may determine the packet loss rate which would result
   in a given throughput for a particular session, if a TCP connection
   was used.

   Whilst this relation between packet loss rate and throughput is
   specific to the TCP congestion control algorithm, it also provides an
   estimate of the acceptable loss rate for a streaming media
   application using the same network path, which wishes to coexist
   fairly with TCP traffic.  Clearly this is not sufficient for fair
   sharing of a link with TCP traffic, since it does not capture the
   dynamic behavior of the connection, merely the average behavior, but
   it does provide one definition of "reasonable" behavior in the
   absence of real congestion control.

   For example, an RTP audio session with DVI encoding and 40ms data
   packets will have 40 bytes RTP/UDP/IP header, 4 bytes codec state and
   160 bytes of media data, giving a packet size, s, of 204 bytes.  It
   will send 25 packets per second, giving T = 4800.  It is possible to
   estimate the round-trip time from RTCP reception report statistics
   (say 200 milliseconds for the purpose of example).  Substituting
   these values into the above equation, we estimate a "reasonable"
   packet loss rate, p, of 6.7%.  This would represent an upper bound on
   the packet loss rate which this application should be designed to
   tolerate.

   It should be noted that a round trip time estimate based on RTCP
   reception report statistics is, at best, approximate; and that a
   round trip time for a multicast group can only be an `average'
   measure.  This implies that the TCP equivalent throughput/loss rate
   determined by this relation will be an approximation of the upper
   bound to the rate a TCP connection would actually achieve.

6  Security Considerations

   Some of the repair techniques discussed in this document result in
   the transmission of additional traffic to correct for the effects of
   packet loss.  Application designers should be aware that the
   transmission of large amounts of repair traffic will increase network
   congestion, and hence packet loss, leading to a worsening of the
   problem which the use of error correction was intended to solve.  At
   its worst, this can lead to excessive network congestion and may
   constitute a denial of service attack.  Section 5 discusses this in



Perkins & Hodson             Informational                      [Page 8]

RFC 2354         Options for Repair of Streaming Media         June 1998


   more detail, and provides guidelines for prevention of this problem.

7  Summary

   Streaming media applications using the Internet will be subject to
   packet loss due to the unreliable nature of UDP packet delivery.
   This document has summarized the typical loss patterns seen on the
   public Mbone at the time of writing, and a range of techniques for
   recovery from such losses.  We have further discussed the need for
   congestion control, and provided some guidelines as to reasonable
   behavior for streaming applications in the interim until congestion
   control can be deployed.

8  Acknowledgments

   The authors wish to thank Phil Karn and Lorenzo Vicisano for their
   helpful comments.

9  Authors' Addresses

   Colin Perkins
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

   EMail: [e-mail]


   Orion Hodson
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT
   United Kingdom

   EMail: [e-mail]

References

   [1] R.E. Blahut. Theory and Practice ofError Control Codes.
       Addison Wesley, 1983.

   [2] J.-C. Bolot and A. Vega-Garcia. The case for FEC based
       error control for packet audio in the Internet. To appear
       in ACM Multimedia Systems.




Perkins & Hodson             Informational                      [Page 9]

RFC 2354         Options for Repair of Streaming Media         June 1998


   [3] C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco,
       D. Newell, J. Ott, S. Wenger, and C.  Zhu. RTP payload
       format for the 1998 version of ITU-T reccomendation  H.263
       video (H.263+).  Work in Progress.

   [4] D. Budge, R. McKenzie, W. Mills, W. Diss,  and P. Long.
       Media-independent error correction using RTP, Work in Progress.

   [5] G. Carle and E. W. Biersack. Survey of error recovery
       techniques for IP-based audio-visual multicast applications.
       IEEE Network, 11(6):24--36, November/December 1997.

   [6] S. Floyd and K. Fall. Promoting the use  of end-to-end
       congestion control in the internet. Submitted to IEEE/ACM
       Transactions on Networking, February 1998.

   [7] S. Floyd, V. Jacobson, S. McCanne, C.-G. Liu, and L. Zhang.
       A reliable multicast framework for light-weight sessions and
       applications level framing. IEEE/ACM Transactions on Networking,
       1995.

   [8] M. Handley.   An examination of Mbone performance.  USC/ISI
       Research Report:  ISI/RR-97-450, April 1997.

   [9] M. Handley and J. Crowcroft.   Network text editor (NTE): A
       scalable shared text editor for the Mbone.   In Proceedings
       ACM SIGCOMM'97, Cannes, France, September 1997.

  [10] V. Hardman, M. A. Sasse, M. Handley, and  A. Watson.
       Reliable audio for use over the Internet.    In Proceedings
       of INET'95, 1995.

  [11] I. Kouvelas, O. Hodson, V. Hardman, and J.  Crowcroft.
       Redundancy control in real-time Internet audio conferencing.
       In Proceedings of AVSPN'97, Aberdeen, Scotland, September 1997.

  [12] S. McCanne, V. Jacobson, and M. Vetterli.   Receiver-driven
       layered multicast.  In Proceedings ACM SIGCOMM'96, Stanford,
       CA., August 1996.

  [13] J. Nonnenmacher, E. Biersack, and D. Towsley.   Parity-based
       loss recovery for reliable multicast transmission. In
       Proceedings ACM SIGCOMM'97, Cannes, France, September 1997.

  [14] P. Parnes.   RTP extension for scalable reliable multicast,
       Work in Progress.





Perkins & Hodson             Informational                     [Page 10]

RFC 2354         Options for Repair of Streaming Media         June 1998


  [15] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
       Bolot, J-C., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
       for Redundant Audio Data", RFC 2198, September 1997.

  [16] J.L. Ramsey. Realization of optimum interleavers. IEEE Transactions
       on Information Theory, IT-16:338--345, May 1970.

  [17] J. Rosenberg and H. Schulzrinne. An A/V profile extension for
       generic forward error correction in RTP.  Work in Progress.

  [18] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A transport protocol for real-time applications",
       RFC 1889, January 1996.

  [19] L. Vicisano, L. Rizzo, and Crowcroft J.  TCP-like congestion
       control for layered multicast data transfer.  In Proceedings
       IEEE INFOCOM'98, 1998.

  [20] R. X. Xu, A. C. Myers, H. Zhang,  and R. Yavatkar.
       Resilient multicast support for continuous media applications.
       In Proceedingsof the 7th International Workshop on Network and
       Operating Systems Support for Digital Audio and Video
       (NOSSDAV'97), Washington University in St. Louis, Missouri,
       May 1997.

  [21] M. Yajnik, J. Kurose, and D. Towsley. Packet loss correlation
       in the Mbone multicast network. In Proceedings IEEE Global
       Internet Conference, November 1996.























Perkins & Hodson             Informational                     [Page 11]

RFC 2354         Options for Repair of Streaming Media         June 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.























Perkins & Hodson             Informational                     [Page 12]