rfc2762.txt

RFC 的详细文档！


RFC 2762                      RTP Sampling                 February 2000


   As an example, consider computation of the additive factor. The group
   size is 1000, c is 1 second, and m is two. With a mask of this size,
   a participant will, on average, observe 250 (N = 250) users. At t=0,
   the user decides to reduce the number of bits in the mask to 1. As a
   result, L(0-) is 1000, and L(0+) is 500. The additive factor
   therefore starts at 500, and decays to zero at time ts + cL(ts-) =
   1000. At time 500, lets assume N has increased to 375 (this will, on
   average, be the case if the actual group size has not changed). At
   time 500, the additive factor is 250. This is added to 2**m times N,
   which is 750, resulting in a group size estimate of 1000. Now, the
   user decides to reduce the number of bits in the mask again, so that
   m=0. Another additive factor is computed. This factor starts at
   L(ts-) (which is 1000), minus L(ts+). L(ts+) is computed without the
   new factor; it is the first additive factor at this time (250) plus
   2**m (1) times N (375). This is 625. As a result, the new additive
   factor starts at 1000 - 625 (375), and decays to 0 in 1000 seconds.

4.2 Binning Algorithm

   In order to more correctly estimate the group size even when it is
   rapidly decreasing, a binning algorithm can be used. The algorithm
   works as follows. There are 32 bins, same as the number of bits in
   the sample mask. When an RTCP packet from a new user arrives whose
   SSRC matches the key under the masking operation, it is placed in the
   mth bin (where m is the number of ones in the mask) otherwise it is
   discarded.

   When the number of bits in the mask is to be increased, those members
   in the bin who still match after the new mask are moved into the next
   higher bin. Those who don't match are discarded. When the number of
   bits in the mask is to be decreased, nothing is done. Users in the
   various bins stay where they are. However, when an RTCP packet for a
   user shows up, and the user is in a bin with a higher value than the
   current number of bits in the mask, it is moved into the bin
   corresponding to the current number of bits in the mask. Finally, the
   group size estimate L(t) is obtained by:

           31
          ----
          \
   L(t) = /    B(i) * 2**i
          ----
           i=0



   Where B(i) are the number of users in the ith bin.




Rosenberg & Schulzrinne       Experimental                      [Page 7]

RFC 2762                      RTP Sampling                 February 2000


   The algorithm works by basically keeping the old estimate when the
   number of bits in the mask drops. As users arrive, they are gradually
   moved into the lower bin, reducing the amount that the higher bin
   contributes to the total estimate. However, the old estimate is still
   updated in the sense that users which timeout are removed from the
   higher bin, and users who send BYE packets are also removed from the
   higher bin. This allows the older estimate to still adapt, while
   gradually phasing it out. It is this adaptation which makes it
   perform much better than the corrective algorithms. The algorithm is
   also extremely simple.

4.3 Comparison

   The algorithms are all compared via simulation in Table 1. In the
   simulation, 10,001 users join a group at t=0. At t=10,000, 5000 of
   them leave. At t=20,000, another 5000 leave. All implement an SSRC
   sampling algorithm, unconditional forward reconsideration and BYE
   reconsideration. The table depicts the group size estimate from time
   20,000 to time 25,000 as seen by the single user present throughout
   the entire session. In the simulation, a memory size of 1000 SSRC was
   assumed. The performance without sampling, and with sampling with the
   additive, multiplicative, and bin-based correction are depicted.

   As the table shows, the bin based algorithm performs particularly
   well at capturing the group size estimate towards the tail end of the
   simulation.

























Rosenberg & Schulzrinne       Experimental                      [Page 8]

RFC 2762                      RTP Sampling                 February 2000


   Time    No Sampling     Binned  Additive  Multiplicative
   ----    -----------     ------  --------  --------------
   20000   5001            5024    5024      5024
   20250   4379            4352    4352      4352
   20500   3881            3888    3900      3853
   20750   3420            3456    3508      3272
   21000   3018            2992    3100      2701
   21250   2677            2592    2724      2225
   21500   2322            2272    2389      1783
   21750   2034            2096    2125      1414
   22000   1756            1760    1795      1007
   22250   1476            1472    1459      582
   22500   1243            1232    1135      230
   22750   1047            1040    807       80
   23000   856             864     468       59
   23250   683             704     106       44
   23500   535             512     32        32
   23750   401             369     24        24
   24000   290             257     17        17
   24250   198             177     13        13
   24500   119             129     11        11
   24750   59              65      8         8
   25000   18              1       2         2

4.4 Sender Sampling

   Care must be taken in handling senders when using SSRC sampling.
   Since the number of senders is generally small, and they contribute
   significantly to the computation of the RTCP interval, sampling
   should not be applied to them. However, they must be kept in a
   separate table, and not be "counted" as part of the general group
   membership. If they are counted as part of the general group
   membership, and are not sampled, the group size estimate will be
   inflated to overemphasize the senders.

   This is easily demonstrated analytically. Let Ns be the number of
   senders, and Nr be the number of receivers. The membership table will
   contain all Ns senders and (1/2)**m of the receivers. The total group
   size estimate in the current memo is obtained by 2**m times the
   number of entries in the table. Therefore, the group size estimate
   becomes:

   L(t) = (2**m) Ns + Nr

   which exponentially weights the senders.






Rosenberg & Schulzrinne       Experimental                      [Page 9]

RFC 2762                      RTP Sampling                 February 2000


   This is easily compensated for in the binning algorithm. A sender is
   always placed in the 0th bin. When a sender becomes a receiver, it is
   moved into the bin corresponding to the current value of m, if its
   SSRC matches the key under the masked comparison operation.

5 Security Considerations

   The use of SSRC sampling does not appear to introduce any additional
   security considerations beyond those described in [1]. In fact, SSRC
   sampling, as described above, can help somewhat in reducing the
   effect of certain attacks.

   RTP, when used without authentication of RTCP packets, is susceptible
   to a spoofing attack. Attackers can inject many RTCP packets into the
   group, each with a different SSRC. This will cause RTP participants
   to believe the group membership is much higher than it actually is.
   The result is that each participant will end up transmitting RTCP
   packets very infrequently, if ever. When SSRC sampling is used, the
   problem can be amplified if a participant is not applying a hash to
   the SSRC before matching them against their key. This is because an
   attacker can send many packets, each with different SSRC, that match
   the key. This would cause the group size to inflate exponentially.
   However, with a random hash applied, an attacker cannot guess those
   SSRC which will match against the key. In fact, an attacker will have
   to send 2**m different SSRC before finding one that matches, on
   average. Of course, the effect of a match causes an increase of group
   membership by 2**m. But, the use of sampling means that an attacker
   will have to send many packets before an effect can be observed.

6 Acknowledgements

   The authors wish to thank Bill Fenner and Vern Paxson for their
   comments.

7 Bibliography

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

   [2] J. Rosenberg and H. Schulzrinne, "Timer reconsideration for
       enhanced RTP scalability", IEEE Infocom, (San Francisco,
       California), March/April 1998.








Rosenberg & Schulzrinne       Experimental                     [Page 10]

RFC 2762                      RTP Sampling                 February 2000


   [3] International Telecommunication Union, "Visual telephone systems
       and equipment for local area networks which provide a non-
       guaranteed quality of service," Recommendation H.323,
       Telecommunication Standardization Sector of ITU, Geneva,
       Switzerland, May 1996.

   [4] Rivest, R., "The MD5 message-digest algorithm", RFC 1321, April
       1992.

   [5] Rosenberg, J., "Protocols and Algorithms for Supporting
       Distributed Internet Telephony," PhD Thesis, Columbia University,
       Dec. 1999.  Work in Progress.

8 Authors' Addresses

   Jonathan Rosenberg
   dynamicsoft
   200 Executive Drive
   West Orange, NJ 07052
   USA

   EMail: [e-mail]


   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003
   USA

   EMail: [e-mail]



















Rosenberg & Schulzrinne       Experimental                     [Page 11]

RFC 2762                      RTP Sampling                 February 2000


9 Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Rosenberg & Schulzrinne       Experimental                     [Page 12]