J. Chesterfield E. Schooler Internet Draft AT&T Labs - Research Document:draft-ietf-avt-rtcpssm-01 J. Ott Tellique Kommunikationstechnik GmbH Expires: December 2002 June 2002 RTCP Extensions for Single-Source Multicast Sessions with Unicast Feedback Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document specifies a modification to the Real-time Transport Control Protocol (RTCP) to use unicast feedback. The proposed extension is useful for single-source multicast sessions such as Source Specific Multicast (SSM) communication where the traditional model of many-to-many group communication is either not possible or not preferred. In addition, it can be applied to any group that might benefit from a sender-controlled summarised reporting mechanism. Table of Contents 1. Conventions and Acronyms........................................2 2. Introduction....................................................2 3. Basic Operation.................................................4 4. Definitions.....................................................5 Chesterfield Internet Draft - Expires December 2002 [Page 1] RTCP with Unicast Feedback 5. Packet types....................................................6 6. Simple feedback model...........................................7 7. Sender feedback summary model...................................8 8. Mixer/Translator issues........................................16 9. Transmission interval calculation..............................17 10. SDP Extensions................................................17 11. Security Considerations.......................................18 12. IANA Considerations...........................................24 13. Outstanding Issues............................................24 14. Acknowledgements..............................................24 15. References....................................................24 16. Appendix......................................................26 A GSR packet processing at the receiver..........................26 B GSR packet creation at the source...............................27 C AUTHORS ADDRESSES...............................................28 D FULL COPYRIGHT STATEMENT........................................28 1. Conventions and Acronyms The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119. 2. Introduction The Real-time Transport Protocol (RTP) [1] provides a real-time transport mechanism suitable for unicast or multicast communication between multimedia applications. Typical uses are for real-time or near real-time group communication via audio and video data streams. An important component of the RTP protocol is the control channel, defined as the Real-Time Control Protocol (RTCP). RTCP involves the periodic transmission of control packets between group members in a session, enabling group size estimation and the distribution or calculation of session-specific information such as packet loss and round trip time to other hosts. An additional advantage of providing a control channel for a session is that a third-party session monitor can listen to the traffic to establish network conditions and to diagnose faults based on receiver locations. RTP was designed to operate in a unicast mode or in the traditional multicast mode of Any Source Multicast (ASM) group communication, where both one-to-many and many-to-many communication are supported via a common group address in the range 224.0.0.0 through 239.255.255.255. Typical intra-domain routing protocols, that is protocols that operate only within a single administrative domain, that enable such communication are the Distance Vector Multicast Routing Protocol (DVMRP) [2] or Protocol Independent Multicast (PIM) [3][4]. Typically these are used in combination with an Inter-domain Chesterfield Internet Draft - Expires December 2002 [Page 2] RTCP with Unicast Feedback routing protocol, that is to say a protocol that operates across administrative domain borders, such as the Multi-protocol extension to the Border Gateway Protocol (MBGP) [5] in combination with the Multicast Source Discovery Protocol (MSDP) [6]. Such routing protocols enable a host to join a single multicast group address and to send to or to receive data from all members in the group with no prior knowledge of the membership across any multicast enabled portion of the internet. In order to enable such a service in the network, however there is a great deal of complexity involved at the routing level. An alternative approach has been developed for multicast groups with just a single data sender. The Source Specific Multicast (SSM) [7] model provides a simpler alternative in that it removes a great deal of the routing complexity involved in multicast group creation and source information distribution. In creating such a simplification, however the SSM model defines a clear separation between the data source and the multicast receiver group. As a consequence the multicast distribution is uni-directional providing only one source with the capability to communicate to the whole group. SSM sessions are typically assigned a value in the group address range 232.0.0.0 through 232.255.255.255, although this is not a requirement. A session may be assigned any valid multicast address, as long as the local network is configured to allow source-specific joins outside the suggested SSM range. In order for a host to receive traffic from an SSM capable source, it must support the IGMPv3 multicast group membership reporting protocol [19], which enables the host to explicitly request traffic from a (source,group) pair. An SDP syntax is defined in Section 10 to specify the mode of operation for the session and the session characteristics such as the (source, group) identifier and feedback address. The effect of using an SSM channel for RTP is that the ability for receivers in the group to communicate RTCP control information with all other members in the group is not provided by default. In order to explicitly enable this at the routing level, receivers would be required to join to an SSM channel from every other member of the group. The creation of such a routing mesh, however would clearly contradict the initial intention of introducing SSM in the first place, and would likely be less efficient than using ASM. In this draft, therefore we define a solution to this problem. We introduce a new method for distributing control information amongst all members in a multicast session that is designed to operate under any multicast group communication scenario. It is, however, of particular benefit to SSM sessions in the absence of receivers being able to communicate with other members directly. The RTP data stream protocol itself is unaffected. The basic architectural models to which the unicast feedback method could provide benefit include: Chesterfield Internet Draft - Expires December 2002 [Page 3] RTCP with Unicast Feedback a) SSM groups with a single sender. This is the main motivation behind the unicast RTCP feedback mechanism. The proposed extensions allow SSM groups that do not have many-to-many communication capability to still receive RTP data streams and to continue to participate in the RTP control protocol, RTCP by unicasting the data to the source on the standard RTCP port. b) One-to-many broadcast networks. An example of such a network is a satellite network with a terrestrial low-bandwidth return channel or a broadband cable link. Unlike the SSM network, this communication architecture may have the ability for a receiver to multicast return data to the group, however a unicast feedback mechanism is likely to be more preferable simply for routing simplicity. c) ASM with a single sender. An SDP [16] session announcement type may identify a session as having a single sender receiving unicast RTCP feedback. Receivers join the multicast group address and receive RTP and RTCP data from the source on the specified address/port combinations. The RTCP feedback is unicast back to the source on the RTCP port. The unicast feedback approach may help to prevent overtaxing multicast routing infrastructure that does not scale as efficiently. However, it is not more efficient than a standard multicast group RTP communication scenario, and therefore is not recommended to replace the traditional mechanism. The modifications proposed in this document are intended to supplement the existing RTCP feedback mechanisms described in [1], Section 6. For certain distribution networks, such as SSM networks, this may be a requirement, whereas in others it is an optional feature that may be used. 3. Basic Operation This draft proposes two new methods to enable receiver feedback to all members in a session. Each involves the unicasting of RTCP packets to a source whose job it is to re-distribute the information to the members of the group. The source must always be able to communicate with all group members in order for either mechanism to work. The content of receiver RTCP traffic will include Receiver Reports (RRs) and Session Description (SDES) information since they are never active sources in the session. Additionally, Application defined (APP) packets may also be transmitted. The various reports are combined into a single RTCP packet which should not exceed the path MTU. Packets are sent at a rate that is inversely proportional to the group size in order to scale the amount of traffic generated. Chesterfield Internet Draft - Expires December 2002 [Page 4] RTCP with Unicast Feedback The first method, the 'Simple Feedback Model', is a basic mechanism whereby all Receiver RTCP packets are unicast to the source and subsequently forwarded by the source to all receivers on the multicast RTCP channel. The advantage of using this method is that an existing receiver implementation requires little modification in order to use it. Instead of sending reports to a multicast address, a receiver uses a unicast address and still receives RTCP traffic on the control data channel. This method also has the advantage of being backwards compatible with RTP/RTCP implementations that do not support unicast feedback to the source and that operate using the standard multicast group communication model, ASM. In a session that uses ASM, such a receiver would multicast reports to the group address and designated RTCP port as stated in [1]. The reports would be directly received by all members. In a session using SSM, the network should prevent any multicast data from the receiver being distributed further than the first hop router. Additionally, any data heard from a non-unicast capable receiver by other hosts on the same subnet should be filtered out by the host IP stack and therefore will not cause problems with respect to the calculation of Receiver RTCP bandwidth share. The second method, the 'Sender Feedback Summary Model' is a summarised reporting scheme that provides savings in bandwidth by consolidating all the Receiver Reports into one summary packet that is then distributed to all the receivers. The advantage of this scheme is apparent for large group sessions where the basic forwarding mechanism outlined above would create a large amount of packet replication in order to forward all the information to all the receivers. The basic operation of the scheme is the same as the first method, however it requires that all the members in the session understand the new summarised packet format outlined in Section 7.1. Additionally, the summarised scheme provides an optional mechanism to send distribution information about the data reported by the whole group. Potential uses for the compilation of distribution information are addressed in Section 7.4. To differentiate between the two reporting methods, a new SDP identifier is created and discussed in Section 10. The reporting method MUST be decided prior to the start of the session. A distribution source MUST NOT change the method during a session. 4. Definitions Distribution Source: In an SSM context, only one source distributes RTP data and redistributes RTCP information to all receivers. That source is called the distribution source. In order for unicast feedback to work, there MUST be only one session distribution source for any subset of receivers to which RTCP feedback is directed. Note that heterogeneous networks comprised of ASM multiple sender groups, unicast-only clients and/or SSM single-sender receiver groups MAY be connected via translators or mixers to create a single-source group (see Section 9 for details). Chesterfield Internet Draft - Expires December 2002 [Page 5] RTCP with Unicast Feedback RTP and RTCP Channels: The data distributed from the source to the receivers is referred to as the RTP channel and the control information the RTCP channel. With standard RTP/RTCP, these channels typically share the same multicast address but are differentiated via port numbers as specified in [1]. Unicast RTCP Feedback Target: For a session defined as having a distribution source A, using ports n for RTP and k for RTCP , the unicast RTCP feedback target is the IP address of Source A on port k unless otherwise stated in the session description. Note that typically n is an even port number and k=n+1; however, certain circumstances such as the presence of NATs may require deviating from these rules. See Section 10 for details on how the address is specified. SSRC: Synchronization source. A 32-bit value that uniquely identifies each member in a session. See [1] for further information. Report blocks: RTCP [1] encourages the stacking of multiple report blocks in Sender and Receiver Report packets. As a result, a variable size feedback packet is created and sent from one source that pertains to multiple other sources in the group. In this draft, the method of stacking report blocks is extended in Generic Summary Report packets, where a source optionally may stack multiple reports into one packet in order to provide additional feedback on the RTCP traffic received from the group. 5. Packet types The RTCP packet types defined in [1] are: type description Payload number SR sender report 200 RR receiver report 201 SDES source description 202 BYE goodbye 203 APP application-defined 204 These remain unmodified. Two new packet types are introduced in this draft. Later profile extensions may be added to these which are not covered in [1] or this document. The new packet types are: type description Payload number RSI Receiver Summary Information [see Section 12] GSR General Summary Report [see Section 12] Within the General Summary Report packet, various types of distribution data may be reported, each of which requires a Chesterfield Internet Draft - Expires December 2002 [Page 6] RTCP with Unicast Feedback distribution type identifier. Distribution types defined in this document are: Distribution Type Number Packet Loss 1 Receiver Jitter 2 Round Trip Time estimation 3 SSRC distribution 4 6. Simple feedback model 6.1 Packet Formats The simple feedback model uses the same packet types as standard RTCP feedback described in [1]. Receivers still generate Receiver Reports with information on the quality of the stream received from the source. The distribution source still must create Sender Reports that include timestamp information for stream synchronisation and round trip time calculation. Both senders and receivers are required to send SDES packets as outlined in [1]. The rules for generating BYE and APP packets as outlined in [1] also apply. 6.2 Distribution Source behaviour For the simple feedback model, the source provides a simple packet reflection mechanism. It is the default behaviour for any distribution source and is the minimum requirement for acting as a source to a group of receivers using unicast RTCP feedback. The source MUST NOT stack report blocks received from different SSRCs into one packet for retransmission to the group. Every RTCP packet from each receiver MUST be reflected individually. The source MUST listen for unicast RTCP data sent to the RTCP port. All unicast data received on this port MUST be forwarded by the source to the group on the multicast RTCP channel. Any multicast data received on this port MUST NOT be forwarded but processed as defined in [1]. The reflected traffic MUST NOT be included in the transmission interval calculation by the source. In other words, the source MUST NOT consider reflected packets as part of its own control data bandwidth allowance. The algorithm for computing the allowance is explained in Section 9. The control traffic included in the bandwidth calculation includes any Sender Reports to the group, along with any additional SDES and APP packets. If an application wishes to use APP packets, it is recommended that the simple feedback model be used since it is likely that all receivers in the session will need to hear the APP specific packets. The same applies for all other RTCP packets that are not defined in the base RTP specification [1]. The decision to use the simple Chesterfield Internet Draft - Expires December 2002 [Page 7] RTCP with Unicast Feedback feedback model MUST be made in advance of the session and MUST be indicated in the SDP announcement [16]. When reflecting traffic, it is recommended that the source SHOULD attempt to avoid generating bursts of packets whenever buffer playout smoothing is possible. 6.3 Receiver behaviour Receivers listen on the RTP channel for data and the RTCP channel for control. Each receiver calculates its share of the control bandwidth based on the standard rule that 75% of the RTCP bandwidth is divided equally between all unique SSRCs in the session. See Section 9 for further information on the calculation of the bandwidth allowance. When a receiver is eligible to transmit, it sends a unicast Receiver Report packet to the RTCP port of the distribution source. 7. Sender feedback summary model In the sender feedback summary model, the sender is required to summarise the information received from all the Receiver Reports generated by the receivers and place the information into summary reports. The sender feedback summary model introduces two new packets. The Receiver Summary Information packet (RSI), which MUST be sent by a source if the summarised feedback mechanism is selected, and the OPTIONAL General Summary Report packet (GSR), which MAY be appended to the RSI packet to provide more detailed information on the overall session characteristics reported by all receivers. The sender MUST send at least one Receiver Summary Information packet for each reporting interval. The sender can additionally stack General Summary Reports (GSRs) after the RSI packet. Each GSR packet corresponds to the initial RSI packet and acts as an enhancement to the basic summary information required by the receivers to calculate their reporting time interval. For this reason, GSR packets are not required but recommended. RSI and GSR packets are sent in addition to the standard receiver-issued packets, such as Sender Reports and SDES packets outlined in [1]. Chesterfield Internet Draft - Expires December 2002 [Page 8] RTCP with Unicast Feedback 7.1 Packet Formats 7.1.1 RSI: Receiver Summary Information RTCP Packet 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| SC | PT | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | group size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AFL | HCNL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Highest interarrival jitter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver RTCP Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | collision SSRC #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . | The RSI packet consists of a main report block modeled along the same lines as a Receiver Report with optional GSR blocks appended. The first eight bytes of header extension follow the standard RTP header outline. This ensures backwards compatibility with older versions that may not understand the RSI packet format but can read the length field indicating the end of the report block. The following fields are included: The fields "V", "P", and "length" have the same meaning as per [1]. SC: 5 bits The number of collision SSRC entries towards the end of the report block. A value of 0 is allowed, indicating that no collisions are reported. PT: 8 bits The payload type of this report, see Section 5 for further details. SSRC: 32 bits The synchronisation source identifier for the originator of the summary report packet. timestamp: 32 bits The time the packet was sent. This is an unsigned integer value displayed in NTP timestamp units to enable detection of duplicate packets, reordering and to provide a chronological profile of the feedback reports. Chesterfield Internet Draft - Expires December 2002 [Page 9] RTCP with Unicast Feedback group size: 32 bits This field provides the sender's view of the number of receivers in a session. This MUST include the sender itself and any other senders potentially connected to the session, e.g., via a mixer/translator gateway. The group size is calculated according to the rules outlined in [1]. average fraction lost (AFL): 8 bits The average fraction lost indicated by Receiver Reports forwarded to this source, expressed as a fixed point number with the binary point at the left edge of the field. highest cumulative number of packets lost (HCNL): 24 bits Highest 'cumulative number of packets lost' value out of all RTCP RR packets since the last RSI from any of the receivers. highest interarrival jitter: 32 bits Highest 'interarrival jitter' value out of all RTCP RR packets since the last RSI from any of the receivers. receiver bandwidth: 32 bits Indicates the maximum bandwidth allocated to any single receiver for sending RTCP data relating to the session. This is a fraction value indicating a percentage of the session bandwidth, expressed as a fixed-point number with the binary point at the left edge of the field. collision SSRC: n x 32 bits The final fields in the packet are used to identify any SSRCs that are duplicated within the group. Usually this is handled by the hosts upon detection of the same SSRC, however since receivers in an SSM context no longer have a global view of the session, the collision algorithm is handled by the source. SSRCs that collide are listed in the packet. On receipt of the packet, receiver(s) MUST detect the collision and select another SSRC. 7.1.2 GSR: General Summary Report RTCP Packet Header 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P| BC | PT | Length |header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of Sender | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... |report | ... |blocks The GSR packet is a three-level structure composed of an 8 Octet header and zero or more report blocks, each of which contains a 12 Octet sub-header and variable length payload.Each GSR report Chesterfield Internet Draft - Expires December 2002 [Page 10] RTCP with Unicast Feedback describes a range of values and indicates the distribution of the group members across the data values. The report block formats are described in subsequent sections. The fields "V", "P", and "length" have the same meaning as per [1]. block count (BC): 5 bits The number of report blocks contained in this packet PT: 8 bits The payload type of this report, see Section 5 for further details. SSRC of Sender: 32 bits The SSRC of the distribution source 7.1.3 GSR Report block 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | DT | NDB | MF | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Distribution Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Distribution Value | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Distribution Buckets | | ... | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ distribution type (DT): 8 bits A numeric identifier to indicate the significance of the distribution values. The distribution types currently defined are described in the following four sections. Additional items may be defined in a separate profile by registering the type numbers with IANA (see Section 12). number of distribution buckets (NDB): 12 bits The number of distribution buckets of the data. The size of the bucket can be calculated using the formula, number of bits equals ((length*4)-12)*8/NDB. The calculation is based upon the length of the whole packet in octets (length field*4) minus the header of 12 octets. Providing 12 bits for the NDB field enables bucket sizes as small as 2 bits for a full length packet. The bucket size in bits must always be divisible by 2 to ensure proper byte alignment. A bucket size of 2 bits is fairly restrictive, however, and it is expected that larger bucket sizes will be more practical for most distributions. Chesterfield Internet Draft - Expires December 2002 [Page 11] RTCP with Unicast Feedback multiplicative factor (MF): 4 bits Indicates the multiplicative factor to be applied to each distribution Bucket value. Possible values are 1 - 15. length: 8 bits The length of the whole GSR data packet in 4 byte units. The full length of the packet in bytes is calculated by multiplying the length value by 4. This tells the receiver the full length of the packet and enables the receiver to identify the bucket size based on the calculation ((length*4)-12)*8/NDB. Therefore the maximum data portion of a GSR packet may be 1008 bytes, which would provide up to 4032 data buckets of length 2 bits, or 2016 data buckets of length 4 bits etc... minimum distribution value: 32 bits The minimum distribution value, in combination with the maximum distribution value, indicates the range covered by the data bucket values. maximum distribution value: 32 bits The maximum distribution value, in combination with the minimum distribution value, indicates the range covered by the data bucket values. The significance and range of the distribution values is defined in the individual profiles for each distribution type (DT). distribution buckets: each bucket is ((length*4)-12)*8/NDB bits The size and number of buckets depends upon the value of NDB and the length of the packet. In order to calculate the size of the bucket, the formula ((length*4)-12)*8/NDB should be used. This indicates the division of the data space and the size of each data point in bits. Each value must be multiplied by the multiplicative factor. Interpretation of the minimum, maximum and distribution values in the report block are profile-specific and are addressed individually in the sections below. The size of the report block is variable, as indicated by the packet length field. 7.1.4 GSR Loss report block GSR loss report blocks indicate the distribution of losses as reported by the receivers to the distribution source. Values are expressed as a fixed-point number with the binary point at the left edge of the field. The distribution type (DT) is 1. The maximum number of fields is 256, therefore the minimum and maximum distribution values may not exceed 0 - 255. Valid results for the minimum distribution value field therefore are 0 - 254. Similarly, valid results for the maximum distribution value field are 1 - 255. The minimum distribution value MUST always be less than the maximum. Chesterfield Internet Draft - Expires December 2002 [Page 12] RTCP with Unicast Feedback The distribution bucket values are always unsigned positive integers of length ((length*4)-12)*8/NDB. For examples on processing GSR loss report blocks, see section 7.4 and the Appendix B. 7.1.5 GSR Jitter report block GSR jitter report blocks indicate the distribution of the estimated statistical variance of the RTP data packet interarrival time reported by the receivers to the distribution source. See [1] for details on how the values are calculated and the relevance of the jitter results. Jitter values are measured in timestamp units and expressed as unsigned integers. The maximum number of fields is (2^32), therefore the minimum and maximum distribution values may not exceed 0 - (2^32)-1. The values are timestamp units expressed as an unsigned integer. The minimum distribution value must always be less than the maximum. The distribution type (DT) is 2. The distribution bucket values are always unsigned positive integers of length ((length*4)-12)*8/NDB. 7.1.6 GSR Round Trip Time report block GSR round trip time reports indicate the distribution of round trip times from the distribution source to the receivers. The distribution source is the only member of the group capable of calculating the round trip time to any other members since it is the only sender in the group. The sender has the option of distributing these round trip time estimations to the whole group, uses of which are described in Section 7.4. Round trip times are measured in timestamp units and expressed as 32-bit unsigned integers. The multiplicative factor can be used to reduce the number of bits required to represent the values. The minimum distribution value MUST always be less than the maximum. The distribution type (DT) is 3. The distribution bucket values are always unsigned positive integers of length ((length*4)-12)*8/NDB. 7.1.7 SSRC Distribution report block GSR SSRC distribution report blocks are an additional data type that can be provided by the distribution source to indicate the allocation of SSRCs across the group. SSRCs are expressed as 32-bit unsigned integers. The multiplicative factor (MF) can be used to reduce the number of bits required to represent the values. The minimum distribution value MUST always be less than the maximum. The distribution type (DT) is 4. The distribution bucket values are always unsigned positive integers of length ((length*4)-12)*8/NDB. Chesterfield Internet Draft - Expires December 2002 [Page 13] RTCP with Unicast Feedback 7.2 Distribution Source behaviour The source is responsible for accepting RTCP packets from the receivers, interpreting and storing the per-receiver information as defined in [1]. The importance of this is apparent when creating the RSI and GSR summary packets, since incorrect information can have serious implications. Section 11 addresses the security risks in detail. The group size and Receiver RTCP Bandwidth packet fields MUST be calculated and included in the RSI packet. Typically, the bandwidth value will be calculated as outlined in [1] using the group size and session bandwidth as input. However, the Receiver RTCP Bandwidth field, does provide the source with the capability to control the amount of feedback from the receivers and MAY be increased or decreased based on the requirements of the source. Regardless of the value selected by the source for the Receiver RTCP Bandwidth field, the source MUST continue to forward Sender Reports and RSI packets at the rate allowed by its bandwidth allocation. See Section 9 for further details about the frequency of reports. In order to identify SSRC collisions, the source is responsible for maintaining a record of each SSRC and the corresponding CNAME within at least one reporting interval in order to differentiate between clients. It is RECOMMENDED that an updated list of more than one interval be maintained to increase accuracy. This mechanism should prevent the possibility of collisions since the combination of SSRC and CNAME should be unique if the CNAME is generated correctly. If collisions are not detected, the source will have an inaccurate impression of the group size. Since the statistical probability is very low that collisions will both occur and be undetectable, this should not be a significant concern. In particular, the clients would have to randomly select the same SSRC and have the same username + IP address (e.g., using private address space behind a NAT router). For the GSR packet, the source must decide which are the most significant feedback values to convey. The packet format provides flexibility in the amount of detail conveyed by the data points. There is a trade-off between the granularity of the data and the accuracy based on the factorisation values, the number of buckets and the min and max values. In order to focus on a particular region of a distribution, the source can adjust the minimum and maximum values and either increase the number of buckets and possibly the factorisation, or decrease the number of buckets and provide more accurate values. See Appendix B for detailed examples on how to convey a summary of RTCP Receiver Reports as GSR information. The results should correspond as near as possible to the values received during the interval since the last report. The source may stack as many report blocks as required in order to convey different distributions. If the distribution size exceeds the largest packet length (1008 bytes data portion), more packets may be stacked with additional information up to the MTU of the connection. Chesterfield Internet Draft - Expires December 2002 [Page 14] RTCP with Unicast Feedback 7.3 Receiver behaviour The receiver must process RSI packets and adapt session parameters such as the RTCP bandwidth based on the information received. The receiver no longer has a global view of the session, and will therefore be unable to receive information from individual receivers aside from itself. However, the information portrayed by the source can be extremely detailed, providing the receiver with an accurate view of the overall session quality, without the processing overhead associated with listening to and analysing all Receiver Reports. The SSRC collision list must be checked against the SSRC selected by the receiver to ensure there are no collisions. The group size value provides the receiver with the data necessary to calculate its share of the RTCP bandwidth. The Receiver RTCP Bandwidth field may override this value. The Receiver RTCP Bandwidth field provides the source with the capability to control the amount of feedback from the receivers. The receiver can use the GSR data as desired. This data is most useful in providing the receiver with a more global view of the conditions experienced by other receivers, and enables the client to place itself within the distribution and establish the extent to which its reported conditions correspond to the group reports as a whole. Appendix A provides further information and examples of data processing at the receiver. The receiver MUST assume that any report blocks in the same packet correspond to the same data set received by the source during the last reporting time interval. This applies to packets with multiple blocks, where each block conveys a different range of values. 7.4 Generating and analyzing summarised reports In the most basic form, the sender uses an algorithm such as Appendix A.1 to generate the data bucket values for a distribution providing buckets for every possible value. As a first step in creating the GSR packet for loss, the source would calculate the highest loss value out of each data bucket in order to identify what bucket width is required. In the case of loss values, there is a fixed maximum number of different values which could possibly be reported, i.e. 256 since the RTCP fraction lost field is exactly 1 octet. This means that in this, the most basic example, the source creates a distribution with 256 buckets and calculates for each bucket how many receivers reported each value. When generating the packet, the source sets the Minimum Distribution Value to 0 and the Maximum Distribution Value to 255. The maximum data value determines the width of the bucket, i.e. (2^n-2) -1 < Max Value <= (2^n) -1 where n is an even number. As an example, the maximum data bucket values for the widths 6,8 and 10 Chesterfield Internet Draft - Expires December 2002 [Page 15] RTCP with Unicast Feedback bits would be 63,255 and 1023. Therefore if the maximum distribution value was 557, a data bucket of size 10 would be required. Clearly, there is further potential for applying compression techniques to the basic algorithm. In many cases the most extreme values, e.g. 200 - 255, may not even be reported by the group or may be considered irrelevant. In such circumstances the source might choose to decrease either the range or the number of buckets within the range. Additionally, the multiplicative factor can be applied to further reduce the necessary bucket size. Examples of this and more detailed processing are explained in Appendix B. Further information on the applicability of distributions to various application scenarios is addressed in Appendix A.3. 8. Mixer/Translator issues The original RTP specification allows a session to use mixers and translators, which help to connect heterogeneous networks into one session. There are a number of issues, however, which are raised by the unicast feedback model proposed in this document. The term 'mixer' refers to devices that provide data stream multiplexing where multiple sources are combined into one stream. Conversely, a translator does not multiplex streams, but simply acts as a bridge between two distribution mechanisms, e.g., a unicast-to-multicast network translator. Since the issues raised by this draft apply equally to either a mixer or translator, they are referred to from this point onwards as mixer-translator devices. A mixer-translator between distribution networks in a session must ensure that all members in the session receive all the relevant traffic to enable the usual operation by the clients. A typical use may be to connect an older implementation of an RTP client with an SSM distribution network, where the client is not capable of unicasting feedback to the source. In this instance the mixer- translator must join the session on behalf of the client and send and receive traffic from the session to the client. Certain hybrid scenarios may have different requirements. 8.1 Use of a mixer-translator The mixer-translator MUST adhere to the SDP description [16] for the single source session (Section 10) and use the feedback mechanism indicated. Receivers SHOULD be aware that by introducing a mixer- translator into the session, more than one source may be active in a session since the mixer-translator may be forwarding traffic from either multiple unicast sources or from an ASM session to the SSM receivers. Receivers SHOULD still forward unicast RTCP reports in the usual manner to the distribution source, which in this case would be the mixer-translator itself. It is RECOMMENDED that the simple packet reflection mechanism be used under these circumstances since attempting to coordinate RSI + LJS reporting between more than Chesterfield Internet Draft - Expires December 2002 [Page 16] RTCP with Unicast Feedback one source may be complicated unless the mixer-translator is capable of undertaking the summarisation itself. 8.2 Encryption and Authentication issues Encryption and security issues are discussed in detail in Section 11. A mixer-translator MUST be able to follow the same security policy as the client in order to unicast forward RTCP feedback to the source, and it therefore MUST be able to apply the same authentication and/or encryption policy required for the session. Transparent bridging, where the mixer-translator is not acting as the distribution source, and subsequent unicast feedback to the source is only allowed if the mixer-translator can conduct the same source authentication as required by the receivers. 9. Transmission interval calculation The Control Traffic Bandwidth referred to in [1] is an arbitrary amount which is intended to be supplied by a session management application (e.g., [9]) or decided based upon the bandwidth of a single sender in a session. A receiver MUST calculate the number of other members in a session based upon either its own SSRC count determined by the number of forwarded Receiver Reports, or from the group size field in the RSI report from a sender. The RTCP transmission Interval calculation remains the same as in the original RTP specification [1]. In the original specification, the senders are allocated 1/4 of the control traffic bandwidth if they number 25% or less than the group size. Otherwise the allocation for senders is the percentage of senders to group size. The remaining bandwidth is allocated to the receivers to be divided evenly amongst the group. The source should calculate the transmission interval for RSI + LJS packets out of its 1/4 of the control traffic bandwidth with a minimum transmission interval of 5 seconds. 10. SDP Extensions The Session Description Protocol (SDP) [16] is used as a means to describe media sessions in terms of their transport addresses, codecs, and other attributes. Providing RTCP feedback via unicast as specified in this document constitutes another session parameter needed in the session description. Similarly, other SSM RTCP feedback parameters need to be provided, such as the summarisation mode at the sender and the target unicast address to which to send feedback information. This section defines the SDP parameters that are needed by the proposed mechanisms in this draft (and that also need to be registered with IANA). Chesterfield Internet Draft - Expires December 2002 [Page 17] RTCP with Unicast Feedback 10.1 SSM RTCP Session Identification A new session level attributes MUST be used to indicate the use of unicast instead of multicast feedback: "rtcp:unicast". This attribute uses one additional parameter to specify the mode of operation. rtcp:unicast reflection -- MUST be used to indicate packet reflection by the RTCP target (without further processing). rtcp:unicast gsr -- MUST be used to indicate the "General Summary Report" mode of operation. rtcp:unicast rsi -- MUST be used to indicate the "Receiver Summary Information" mode of operation. 10.2 SSM Source Specification In addition, in an SSM RTCP session, the sender(s) need to be indicated for both source-specific joins to the multicast group as well as for addressing RTCP packets to. This is done following the proposal for SDP source filters documented in draft-ietf-mmusic-sdp-srcfilter-00.txt [15]. From this specification, only the inclusion mode ("a=incl:") MUST be used for SSM RTCP. There MUST be exactly one "a=incl:" attribute listing the address of the sender. The RTCP port MUST be derived from the m= line of the media description. An optional alternative feedback address may be supplied using an attribute such as a=rtcp: IN IP4 192.168.1.1 [17]. 11. Security Considerations 11.1 Assumptions RTP/RTCP is a protocol for carrying real-time multimedia traffic, and therefore one of the main considerations for any security solution must be to maintain as low an overhead as possible in order to limit processing constraints. This includes the consideration of overhead for different applications and types of cryptographic operations, as well as considerations for deploying or creating security infrastructure for large groups. The distribution of session parameters, typically using type information through SAP, email or the web is beyond the scope of this document. It is recommended, however, that the method used Chesterfield Internet Draft - Expires December 2002 [Page 18] RTCP with Unicast Feedback should employ adequate security measures to ensure the integrity and authenticity of the information. For the purposes of this analysis, it is assumed that the information has already been securely distributed out-of-band. SAP, SIP, RTSP, and HTTP, as prime candidates for conveying SDP-based session descriptions support the necessary protocol mechanisms, drawing on work from the MSEC WG. Further work is in progress within the Gsec working group, which is addressing the security implications of distributing session announcements. It is also assumed that the multicast or group distribution mechanism, e.g., the SSM routing tree, is not immune to source IP address spoofing or traffic snooping. All security weaknesses are therefore addressed from a transport level perspective or above. 11.2 Security threats Attacks on this architecture may take a variety of forms, and in order to identify the security weaknesses, it is important to address these individually. a) Denial of Service A major area of concern would be a denial of service attack. Due to the nature of the communication architecture this is a situation that could be generated in a number of ways by using the unicast feedback characteristic as a weakness. Since standard multicast communication does not typically involve many to one unicast forwarding of data, this poses new challenges for a security solution. b) Packet Forgery One potential area of attack to guard against is packet forgery. In particular, it is important to protect against the integrity of certain influential packets since compromise of certain control packets could directly affect the transmission characteristics of the whole group, however for the purposes of defining a security profile at this stage, every packet is considered equally as important. This decision may be revisited in future revisions as the requirements emerge more clearly. It is clear, however that in the case of a large group, the compromise of RTCP traffic could have serious consequences. c) Session Replay An additional concern is the potential for session recording and subsequent replay. The issue to deal with in particular in this instance is that an attacker may not actually need to understand the packet contents, but just simply have the ability to record the data stream and at a later time replay it with a spoofed source address. d) Eavesdropping on a session The consequences of eavesdropping by an attacker on a session may not directly constitute a security weakness, however it might Chesterfield Internet Draft - Expires December 2002 [Page 19] RTCP with Unicast Feedback benefit other types of attack, and should therefore be considered as a potential threat. 11.3 Security properties The following security types are relevant to this draft and will be addressed in greater detail in subsequent sections. a) Data integrity Ensures that any third party has not tampered with the data received from the network, either maliciously or through a network error. This property ensures that the packet received is guaranteed to be in exactly the same condition as that source intended it to be. The authenticity of the data must be tested in a separate manner. b) Data authenticity Ensures the origin of the message can either be uniquely identified, or in the case of group authentication can be identified as coming from a specific trusted group of sources. c) Data confidentiality Ensures that the only receiver(s) that can recover the original plaintext is the intended receiver(s), therefore in order to restrict access only to authorized entities, confidentiality is required. It does not prevent eavesdroppers from receiving the traffic but does guarantee that they cannot recover the original data. d) Replay protection Ensures that given some pre-determined range of either time or session values, a host can determine whether the data was transmitted within the given window. 11.4 Architectural Contexts In order to understand the potential weaknesses to guard against, it is necessary to divide the communication model into a number of distinct contexts. a) Source to Receiver communication The first, and perhaps most influential context to protect, is the 'downstream' communication channel from the source to the receivers. This is effectively the main controlling influence over the behaviour of the group since it determines the bandwidth allocation for each receiver and hence the rate at which the RTCP traffic is directly unicast back to the source. All traffic that is distributed over the downstream channel should be generated by a single source. Both the RTP data stream and the RTCP control data are sent over this channel. The RTCP data is indirectly Chesterfield Internet Draft - Expires December 2002 [Page 20] RTCP with Unicast Feedback influenced by the information the source has received from the whole group. This context is vulnerable to all four attacks outlined in the previous section. A denial of service attack from the source to the receivers is possible, but less of a concern since the worst case effect of sending large volumes of traffic over the distribution channel has the potential to reach every receiver, but only on a one-to-one basis, this is no different from the current multicast model where an individual source may send large volumes of traffic to a multicast group. The real danger of denial of service attacks in this context comes indirectly via compromise of the source RTCP traffic. If receivers are provided with an incorrect group size estimate or bandwidth allowance, the return traffic to the source may create a Distributed DoS effect on the source. Similarly, an incorrect feedback address whether as a result of a malicious attack or by mistake, e.g., an IP address typing error, could directly create a denial of service attack on another host which must also be guarded against. The danger of Packet forgery in the worst case may be to maliciously instigate a denial of service attack, e.g. if an attacker were capable of spoofing the source address and injecting incorrect packets into the data stream or intercepting the source RTCP traffic and modifying the fields. Other consequences of packet forgery in this context may be the compromise of data affecting the integrity of the data received both in the RTP stream itself and the RTCP data in general. The replay of a session would have the effect of recreating the receiver feedback to the source address at a time when the source is not expecting additional traffic from a potentially very large group. The consequences of this type of attack may be less effective on their own, but in combination with other attacks might be serious. Eavesdropping on the session would provide an attacker with information on the characteristics of the source to receiver traffic such as the frequency of RTCP traffic and, if unencrypted, might also provide valuable information on characteristics such as group size and transmission characteristics of the receivers back to the source in addition to enabling an attacker to listen to the media streams. In this context, the attacker might also have access to personal information carried in the SDES packets such as email, phone and full username information. b) Receiver to source or gateway communication The second context to address is the return traffic from the group to the source or gateway, which for the purposes of this analysis may be considered in the same light as a distribution source. This traffic should only be RTCP type data, and should include receiver reports, SDES information and possibly Application specific packets. The effects of compromise on a Chesterfield Internet Draft - Expires December 2002 [Page 21] RTCP with Unicast Feedback single or subset of receivers is less likely to have as great an impact as the first context, however much of the responsibility for detecting compromise of the source data stream relies on the receivers. The effects of compromise of the first context with respect to critical source RTCP control information would be witnessed most seriously in the second context. A large group of receivers may unwittingly generate a distributed DoS attack on the source in the event that the integrity of the source RTCP channel has been compromised and the security breach is not detectable by the individual receivers. In the event that packet forgery may occur in this context, the effect may be the introduction of false RTCP traffic and/or the creation of fake SSRC identifiers. Such an attack might slow down the overall control channel data rate, since an incorrect perception of the group size may be created. This might affect external issues such as group accounting and other as yet unknown potential uses of the distribution functionality for controlling group behaviour such as leader election based on feedback criteria. A replay attack on receiver return data to the source would have the same implications as the generation of false SSRC identifiers and RTCP traffic to the source. It is therefore equally as important to protect against compromise of any receiver contribution to the RTCP channel, as it is to ensure authenticity and freshness of the data source. Eavesdropping in this context may potentially provide an attacker with a great deal of personal information about a large group of receivers available from SDES packets. It would also provide an attacker with information on group traffic generation characteristics and parameters for calculating individual receiver bandwidth allowance. 11.5 Requirements in each context Some initial requirements to consider for each context in general are that the overhead of ensuring the security of the session should be kept as low as possible. This entails keeping the setup and communication of keys to a minimum. The nature of RTP/RTCP traffic is that sessions require real-time processing and minimal overhead for communication. This means that processing constraints imposed by the required cryptographic techniques are an important consideration in defining this security profile. Having identified the security weaknesses for each communication context, security type requirements can be addressed for each. a) The first context is concerned with denial of service attacks through possible packet forgery. The forgery may take the form of Chesterfield Internet Draft - Expires December 2002 [Page 22] RTCP with Unicast Feedback interception and modification of packets from the source, or simply injecting false packets into the distribution channel. To combat these attacks, data integrity and source authenticity are required. The degree of confidentiality which may be deployed is not a requirement in this context since the actual consequences of eavesdropping do not affect the operation of the protocol, however without confidentiality, access to personal and group characteristics information would be unrestricted to an external listener and it is therefore recommended. b) The second context must defend against the same kinds of attacks. Data integrity is required to ensure that interception and modification of an individual receiver's RTCP traffic is not accomplished. This is to protect against the false influence of group control information and the possible serious compromise of future services provided by the distribution functionality such as leader election based on various parameters. In order to ensure data integrity, receiver authenticity is therefore an additional requirement in order to ensure the origin of the data is secure. The same situation applies as in the first context with respect to data confidentiality, and it is recommended that precautions should be taken to protect the privacy of the data. 11.6 Overview of existing security solutions This section addresses some existing group security mechanisms and identifies which aspects of the security requirements they might provide. This security analysis is a work in progress, and these options will be explored in more detail in subsequent versions of the draft. SRTP provides confidentiality of the RTP and RTCP packets as well as protection against integrity compromise and replay attacks. It provides authentication of the data stream, however it does not provide authentication on a per-user basis. This means that a packet can be authenticated as having originated from one of the session members, but it does not indicate which member. All keys for an SRTP session are derived from a single master key, which it is assumed has been distributed via some out-of-band secure method. The most detailed group security profile which may be considered is the Group Domain of Interpretation, which provides a solution for multicast IPSec ESP security with group authentication. Used in combination with a Key negotiation protocol, it provides integrity and group authentication and re-keying for groups with dynamic membership. It is not particularly well suited to Real-time application data stream processing, however and may therefore not be appropriate. A third option with respect to group security frameworks is TESLA [18], a lightweight source authentication scheme based on loose time synchronisation calculations by receivers to the source, and a delayed key disclosure interval. The usefulness of this scheme in Chesterfield Internet Draft - Expires December 2002 [Page 23] RTCP with Unicast Feedback addition to the others is currently being considered for the unicast RTCP feedback scenario, the results of which will be addressed in a subsequent draft. 12. IANA Considerations Based on the guidelines suggested in [10], this document proposes 2 new RTCP data payload types for consideration by IANA, and 4 new sub-payload types for summary distribution types, defined in section 5. Furthermore, four new SDP media-level attributes are defined in Section 10. 13. Outstanding Issues 6.2 Complication with detecting unicast versus multicast transmitted data on the same port. Backwards Compatibility section? Incorporate additional distribution type to include packet loss rate based on Cumulative values. Analyse and select suitable scheme(s) for appropriate security 14. Acknowledgements Many people have made comments and suggestions regarding this document. In particular, we would like to thank Patrick McDaniel for advice and suggestions regarding the security aspects, Marshall Eubanks, Marty Schoch, Bill Fenner, the Networking Research group at AT&T in California and also the AVT working group. 15. References [1] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP - A Transport Protocol for Real-time Applications," Internet Draft, draft-ietf-avt-rtp-new-11.txt, Work in Progress, July 2001. [2] Pusateri, T, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-10, August 2000 [3] Fenner, B, Handley, M, Holbrook, H, Kouvelas, I, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", draft-ietf-pim-sm-v2-new-05.txt, March 2001 [4] Farinacci, D, Kouvelas, I, Windisch, K, "State Refresh in PIM- DM" draft-ietf-pim-refresh-02.txt, November, 2000 Chesterfield Internet Draft - Expires December 2002 [Page 24] RTCP with Unicast Feedback [5] Thaler, D, Cain, B, "BGP Attributes for Multicast Tree Construction", draft-ietf-idmr-bgp-mcast-attr-00.txt, February 1999 [6] Farinacci, D, Rekhter, Y, Meyer, D, Lothberg, P, Kilmer, H, Hall, J, "Multicast Source Discovery Protocol (MSDP)", draft- ietf-msdp-spec-06.txt, July 2000 [7] Shepherd, G, Luczycki, E, Rockell, R, "Source-Specific Protocol Independent Multicast in 232/8", draft-shepherd-ssm232-00.txt, March 2000. [8] Holbrook, H, Cain, B, "Using IGMPv3 For Source-Specific Multicast", draft-holbrook-idmr-igmpv3-ssm-00.txt, July 2000. [9] Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group. [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [11] Handley, M, Perkins, C, Whelan, E, "Session Announcement Protocol", (SAP), RFC 2974, October 2000. [12] A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996. [13] Perrig, Canetti, Briscoe, Tygar, Song, "TESLA: Multicast Source Authentication Transform", draft-irtf-smug-tesla-01.txt. [14] E. Carrara, D. McGrew, M. Naslund, K. Norrman, D. Oran, "The Secure Real Time Transport Protocol", draft-ietf-avt-srtp- 05.txt. [15] B. Quinn, "SDP Source-Filters", Internet Draft draft-ietf- mmusic-sdp-srcfilter-00.txt, Work in Progress, May 2000. [16] M. Handley, V. Jacobson, Perkins, C. "SDP: Session Description Protocol", draft-ietf-mmusic-sdp-new-10.txt, May 2002. [17] C. Huitema, "RTCP Attribute in SDP," Internet Draft draft-ietf- mmusic-sdp4nat-02.txt, February 2002. [18] A. Perrig et al,." TESLA:Multicast source authentication transform introduction", draft-perrig-msec-tesla-intro-00.txt, February 2002. [19] B. Cain, S. Deering, B. Fenner, I. Kouvelas, and A. Thyagarajan, "Internet Group Management Protocol, Version 3," Internet Draft draft-ietf-idmr-igmp-v3-11.txt, May 2002. Chesterfield Internet Draft - Expires December 2002 [Page 25] RTCP with Unicast Feedback 16. Appendix A GSR packet processing at the receiver A.1 Algorithm Example processing of Loss Distribution Values X values represent the loss percentage. Y values represent the number of receivers. Number of x values is the NDB value xrange = Max Distribution Value(MaDV) - Min Distribution Value(MnDV) First data point = MnDV,first ydata then Foreach ydata => xdata += (MnDV + (xrange / NDB)) A.2 Pseudo-code Packet Variables -> factor,NDB,MnDVL,MaDV Code variables -> xrange, ydata[NDB],x,y xrange = MaDV - MnDV x = MnDV; for(i=0;i