Sampling of the Group Membership in RTP
RFC 2762

Document Type RFC - Experimental (February 2000; No errata)
Authors Henning Schulzrinne  , Jonathan Rosenberg 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2762 (Experimental)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      J. Rosenberg
Request for Comments: 2762                                  dynamicsoft
Category: Experimental                                   H. Schulzrinne
                                                            Columbia U.
                                                          February 2000

                Sampling of the Group Membership in RTP

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

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


   In large multicast groups, the size of the group membership table
   maintained by RTP (Real Time Transport Protocol) participants may
   become unwieldy, particularly for embedded devices with limited
   memory and processing power. This document discusses mechanisms for
   sampling of this group membership table in order to reduce the memory
   requirements. Several mechanisms are proposed, and the performance of
   each is considered.

1 Introduction

   RTP, the Real Time Transport Protocol [1], mandates that RTCP packets
   be transmitted from each participant with a period roughly
   proportional to the group size. The group size is obtained by storing
   a table, containing an entry for each unique SSRC seen in RTP and
   RTCP packets. As members leave or time out, entries are deleted, and
   as new members join, entries are added. The table is thus highly

   For large multicast sessions, such as an mbone broadcast or IP-based
   TV distribution, group sizes can be extremely large, on the order of
   hundreds of thousands to millions of participants. In these
   environments, RTCP may not always be used, and thus the group
   membership table isn't needed. However, it is highly desirable for
   RTP to scale well for groups with one member to groups with one
   million members, without human intervention to "turn off" RTCP when
   it's no longer appropriate. This means that the same tools and

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

   systems can be used for both small conferences and TV broadcasts in a
   smooth, scalable fashion.

   Previous work [2] has identified three major scalability problems
   with RTP. These are:

   1. Congestion due to floods of RTCP packets in highly dynamic groups;

   2. Large delays between receipt of RTCP packets from a single user;

   3. Large size of the group membership table.

   The reconsideration algorithm [2] helps to alleviate the first of
   these. This document addresses the third, that of large group size

   Storage of an SSRC table with one million members, for example,
   requires at least four megabytes. As a result, embedded devices with
   small memory capacity may have difficulty under these conditions.  To
   solve this problem, SSRC sampling has been proposed. SSRC sampling
   uses statistical sampling to obtain a stochastic estimate of the
   group membership. There are many issues that arise when this is done.
   This document reviews these issues and discusses the mechanisms which
   can be applied by implementors. In particular, it focuses on three
   methods for adapting the sampling probability as the group membership
   varies. It is important to note that the IETF has been notified of
   intellectual property rights claimed in regard to some or all of the
   specification contained in this document, and in particular to one of
   the three mechanisms: the binning algorithm described below. For more
   information consult the online list of claimed rights. The two other
   approaches presented are inferior to the binning algorithm, but are
   included as they are believed to be unencumbered by IPR.

2 Basic Operation

   The basic idea behind SSRC sampling is simple. Each participant
   maintains a key K of 32 bits, and a mask M of 32 bits. Assume that m
   of the bits in the mask are 1, and the remainder are zero. When an
   RTCP packet arrives with some SSRC S, rather than placing it in the
   table, it is first sampled. The sampling is performed by ANDing the
   key and the mask, and also ANDing the SSRC and the mask. The
   resulting values are compared. If equal, the SSRC is stored in the
   table. If not equal, the SSRC is rejected, and the packet is treated
   as if it has never been received.

   The key can be anything, but is usually derived from the SSRC of the
   user who is performing the sampling.

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

   This sampling process can be described mathematically as:

   D = (K*M == S*M)
Show full document text