1.1. Applicability
1.1. Applicability
The XR packets are useful across multiple applications, and for that reason are not defined as profile-specific extensions to RTCP sender or Receiver Reports [9, Section 6.4.3]. Nonetheless, they are not of use in all contexts. In particular, the VoIP metrics report block (Section 4.7) is specific to voice applications, though it can be employed over a wide variety of such applications.
The VoIP metrics report block can be applied to any one-to-one or one-to-many voice application for which the use of RTP and RTCP is specified. The use of conversational metrics (Section 4.7.5), including the R factor (as described by the E Model defined in [3]) and the mean opinion score for conversational quality (MOS-CQ), in applications other than simple two party calls is not defined; hence, these metrics should be identified as unavailable in multicast conferencing applications.
The packet-by-packet report block types, Loss RLE (Section 4.1), Duplicate RLE (Section 4.2), and Packet Receipt Times (Section 4.3), have been defined with network tomography applications, such as multicast inference of network characteristics (MINC) [11], in mind. MINC requires detailed packet receipt traces from multicast session receivers in order to infer the gross structure of the multicast distribution tree and the parameters, such as loss rates and delays, that apply to paths between the branching points of that tree.
Any real time multicast multimedia application can use the packet-by-packet report block types. Such an application could employ a MINC inference subsystem that would provide it with multicast tree topology information. One potential use of such a subsystem would be for the identification of high loss regions in the multicast tree and the identification of multicast session participants well situated to provide retransmissions of lost packets.
Detailed packet-by-packet reports do not necessarily have to consume disproportionate bandwidth with respect to other RTCP packets. An application can cap the size of these blocks. A mechanism called "thinning" is provided for these report blocks, and can be used to ensure that they adhere to a size limit by restricting the number of packets reported upon within any sequence number interval. The rationale for, and use of this mechanism is described in [13]. Furthermore, applications might not require report blocks from all receivers in order to answer such important questions as where in the multicast tree there are paths that exceed a defined loss rate threshold. Intelligent decisions regarding which receivers send these report blocks can further restrict the portion of RTCP bandwidth that they consume.
The packet-by-packet report blocks can also be used by dedicated network monitoring applications. For such an application, it might be appropriate to allow more than 5% of RTP data bandwidth to be used for RTCP packets, thus allowing proportionately larger and more detailed report blocks.
Nothing in the packet-by-packet block types restricts their use to multicast applications. In particular, they could be used for network tomography similar to MINC, but using striped unicast packets instead. In addition, if it were found useful, they could be used for applications limited to two participants.
One use to which the packet-by-packet reports are not immediately suited is for data packet acknowledgments as part of a packet retransmission mechanism. The reason is that the packet accounting technique suggested for these blocks differs from the packet accounting normally employed by RTP. In order to favor measurement applications, an effort is made to interpret as little as possible at the data receiver, and leave the interpretation as much as possible to participants that receive the report blocks. Thus, for example, a packet with an anomalous SSRC ID or an anomalous sequence number might be excluded by normal RTP accounting, but would be reported upon for network monitoring purposes.
The Statistics Summary Report Block (Section 4.6) has also been defined with network monitoring in mind. This block type can be used equally well for reporting on unicast and multicast packet reception.
The reference time related block types were conceived for receiver-based TCP-friendly multicast congestion control [18]. By allowing data receivers to calculate their round trip times to senders, they help the receivers estimate the downstream bandwidth they should request. Note that if every receiver is to send Receiver Reference Time Report Blocks (Section 4.4), a sender might potentially send a number of DLRR Report Blocks (Section 4.5) equal to the number of receivers whose RTCP packets have arrived at the sender within its reporting interval. As the number of participants in a multicast session increases, an application should use discretion regarding which participants send these blocks, and how frequently.
XR packets supplement the existing RTCP packets, and may be stacked with other RTCP packets to form compound RTCP packets [9, Section 6]. The introduction of XR packets into a session in no way changes the rules governing the calculation of the RTCP reporting interval [9, Section 6.2]. As XR packets are RTCP packets, they count as such for bandwidth calculations. As a result, the addition of extended reporting information may tend to increase the average RTCP packet size, and thus the average reporting interval. This increase may be limited by limiting the size of XR packets.
The SDP signaling defined for XR packets in this document (Section 5) was done so with three use scenarios in mind: a Real Time Streaming Protocol (RTSP) controlled streaming application, a one-to-many multicast multimedia application such as a course lecture with enhanced feedback, and a Session Initiation Protocol (SIP) controlled conversational session involving two parties. Applications that employ SDP are free to use additional SDP signaling for cases not covered here. In addition, applications are free to use signaling mechanisms other than SDP.