5] is used as a means to describe media sessions in terms of their transport addresses, codecs, and other attributes. Signaling that RTCP feedback will be provided via unicast, as specified in this document, requires another session parameter in the session description. Similarly, other SSM RTCP feedback parameters need to be provided, such as the summarization model 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 document (and that have been registered with IANA).
rtcp-unicast:rsi *(SP <processing>:<rtcp-type>]) This attribute MUST be used to indicate the "Distribution Source Feedback Summary" model of operation. In this model, a list or parameters may be used to explicitly specify how RTCP packets originated by receivers are handled. Options for processing a given RTCP packet type are: aggr: The Distribution Source has means for aggregating the contents of the RTCP packets and will do so. forward: The Distribution Source will forward the RTCP packet unchanged. term: The Distribution Source will terminate the RTCP packet. The default rules applying if no parameters are specified are as follows: RR and SDES packets MUST be aggregated and MUST lead to RSI packets being generated. All other RTP packets MUST be terminated at the Distribution Source (or Feedback Target(s)). The SDP description needs only to specify deviations from the default rules. Aggregation of RR packets and forwarding of SR packets MUST NOT be changed. The token for the new SDP attribute is "rtcp-unicast" and the formal SDP ABNF syntax for the new attribute value is as follows: att-value = "reflection" / "rsi" *(SP rsi-rule) rsi-rule = processing ":" rtcp-type processing = "aggr" / "forward" / "term" / token ;keep it extensible rtcp-type = 3*3DIGIT ;the RTCP type (192, 193, 202--209)
This is achieved by following the proposal for SDP source filters documented in . According to the specification, only the inclusion model ("a=source-filter:incl") MUST be used for SSM RTCP. There SHOULD be exactly one "a=source-filter:incl" attribute listing the address of the Distribution Source. The RTCP port MUST be derived from the m= line of the media description. An alternative Feedback Target Address and port MAY be supplied using the SDP RTCP attribute , e.g., a=rtcp:<port> IN IP4 192.0.2.1. This attribute only defines the transport address of the Feedback Target and does not affect the SSM group specification for media stream reception. Two "source-filter" attributes MAY be present to indicate an IPv4 and an IPv6 representation of the same Distribution Source. 5]. If such an indication is desired, the "ssrc" attribute  MUST be used for this purpose. As per , the "cname" Source Attribute MUST be present. Further Source Attributes MAY be specified as needed. If used in an SDP session description of an RTCP-SSM session, the ssrc MUST contain the SSRC intended to be used by the respective Media Sender and the cname MUST equal the CNAME for the Media Sender. If present, the role SHOULD indicate the function of the RTP entity identified by this line; presently, only the "media-sender" role is defined. Example: a=ssrc:314159 cname:email@example.com In the above example, the Media Sender is identified to use the SSRC identifier 314159 and the CNAME firstname.lastname@example.org.
provided to RTP sessions above the current standard are RECOMMENDED but OPTIONAL. The final section outlines some security frameworks that are suitable to conform to this specification. 22], email, or the web is beyond the scope of this document, it is RECOMMENDED that the distribution method employs adequate security measures to ensure the integrity and authenticity of the information. Suitable solutions that meet the security requirements outlined here are included at the end of this section. In practice, the multicast and group distribution mechanism, e.g., the SSM routing tree, is not immune to source IP address spoofing or traffic snooping; however, such concerns are not discussed here. In all the following discussions, security weaknesses are addressed from the transport level or above.
c) Session Replay The potential for session recording and subsequent replay is an additional concern. An attacker may not actually need to understand packet content but simply have the ability to record the data stream and, at a later time, replay it to any receivers that are listening. d) Eavesdropping on a Session The consequences of an attacker eavesdropping on a session already constitutes a security weakness; in addition, eavesdropping might facilitate other types of attacks and is therefore considered a potential threat. For example, an attacker might be able to use the eavesdropped information to perform an intelligent DoS attack.
by mistake, e.g., an IP address configuration error (e.g., typing) -- could directly create a denial of service attack on another host. An additional concern relating to Denial of service attacks would come indirectly through the generation of fake BYE packets, causing the source to adjust the advertised group size. A Distribution Source MUST follow the correct rules for timing out members in a session prior to reporting a change in the group size, which allows the authentic SSRC sufficient time to continue to report and, consequently, cancel the fake BYE report. 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. 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 large group. The consequence of this type of attack may be less effective on its 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. If RTCP traffic is unencrypted, this might also provide valuable information on characteristics such as group size, Media Source SSRC(s), and transmission characteristics of the receivers back to the source. b) Receiver-to-Distribution-Source Communication The second context is the return traffic from the group to the Distribution Source. This traffic should only consist of RTCP packets and should include Receiver Reports, SDES information, BYE reports, extended reports (XR), feedback messages (RTPFB, PSFB) and possibly application-specific packets. The effects of compromise on a single or subset of receivers are not likely to have as great an impact as in context (a); however, much of the responsibility for detecting compromise of the source data stream relies on the receivers. The effects of compromise of critical Distribution Source control information can be seriously amplified in the present context. A large group of receivers may unwittingly generate a distributed
DoS attack on the Distribution Source in the event that the integrity of the source RTCP channel has been compromised and the compromise is not detected by the individual receivers. An attacker capable of instigating a packet forgery attack could introduce false RTCP traffic and create fake SSRC identifiers. Such attacks might slow down the overall control channel data rate since an incorrect perception of the group size may be created. Similarly, the creation of fake BYE reports by an attacker would cause some group size instability, but should not be effective as long as the correct timeout rules are applied by the source in removing SSRC entries from its database. 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. Therefore, ensuring authenticity and freshness of the data source is important. Eavesdropping in this context potentially provides an attacker with a great deal of potentially 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 allowances. c) Receiver-to-Feedback-Target Communication The third context is the return traffic from the group to the Feedback Target. It suffers from the same threats as the receiver-to-source context, with the difference being that now a large group of receivers may unwittingly generate a distributed DoS (DDos) attack on the Feedback Target, where it is impossible to discern if the DDoS is deliberate or due merely to a misconfiguration of the Feedback Target Address. While deliberate attacks can be mitigated by properly authenticating messages that communicate the Feedback Target Address (i.e., the SDP session description and the Feedback Target Address sub-report block carried in RTCP), a misconfigured address will originate from an authenticated source and hence cannot be prevented using security mechanisms. Furthermore, the Feedback Target is unable to communicate its predicament with either the Distribution Source or the session receivers. From the feedback packets received, the Feedback Target cannot tell either which SSM multicast group the feedback belongs to or the Distribution Source, making further analysis and suppression difficult. The Feedback Target may not even support RTCP or listen on the port number in question.
Note that because the DDoS occurs inside of the RTCP session and because the unicast receivers adhere to transmission interval calculations (, ), the bandwidth misdirected toward the Feedback Target in the misconfigured case will be limited to a percentage of the session bandwidth, i.e., the Control Traffic Bandwidth established for the session.
1. An endpoint experiencing DDoS or the side effects of a misconfigured RTCP session may not even be a participant in the session, i.e., may not be listening on the respective port number and may even support RTCP, so it will be unable to react within RTCP. Determining that there is a problem will be up to network administrators and, possibly, anti-malware software that can perform correlation across receiver nodes. 2. With misconfiguration, unfortunately the normally desirable usage of SRTP and SRTCP becomes undesirable. Because the packet content is encrypted, neither the misconfigured Feedback Target nor the network administrator have the ability to determine the root cause of the traffic. In the case where the misconfigured Feedback Target happens to be a node participating in the session or is an RTCP-enabled node, the Feedback Target Address block provides a dynamic mechanism for the Distribution Source to signal an alternative unicast RTCP feedback address to the receivers. As this type of packet MUST be included in every RTCP packet originated by the Distribution Source, all receivers would be able to obtain the corrected Feedback Target information. In this manner, receiver behavior should remain consistent even in the face of packet loss or when there are late-session arrivals. The only caveat is that the misconfigured Feedback Target is largely uninvolved in the repair of this situation and thus relies on others for the detection of the problem. An additional security consideration, which is not a component of this specification but which has a direct influence upon the general security, is the origin of the session-initiation data. This involves the SDP parameters that are communicated to the members prior to the start of the session via channels such as an HTTP server, email, SAP, or other means. It is beyond the scope of this document to place any strict requirements on the external communication of such information; however, suitably secure SDP communication approaches are outlined in Section 11.7.
a) The shared-key model, where all authorized group members share the same key and can equally encrypt/decrypt the data. This method assumes that an out-of-band method is applied to the distribution of the shared group key, ensuring that every key-holder is individually authorized to receive the key and, in the event of member departures from the group, a re-keying exercise can occur. The advantage of this model is that the costly processing associated with one-way key-authentication techniques is avoided, as well as the need to execute additional cipher operations with alternative key sets on the same data set, e.g., in the event that data confidentiality is also applied. The disadvantage is that, for very large groups where the receiver set becomes effectively untrusted, a shared key does not offer much protection. b) The public-key authentication model, using cryptosystems such as RSA-based or PGP authentication, provides a more secure method of source authentication at the expense of generating higher processing overhead. This is typically not recommended for real- time data streams but, in the case of RTCP reports, which are distributed with a minimum interval of 5 seconds, this may be a viable option (the processing overhead might still be too great for small, low-powered devices and should therefore be considered with caution). Wherever possible, however, the use of public key source authentication is preferable to the shared key model identified above. As concerns requirements for protocol acceptability, either model is acceptable although it is RECOMMENDED that the more secure public- key-based options be applied wherever possible. Section 11.5. This is only intended as a guideline and it is acknowledged that there are other solutions that would also be suitable to comply with the specification. 25] and SIP .
b) RTSP -- RTSP provides a client- or server-initiated stream control mechanism for real-time multimedia streams. The session parameters are conveyed using SDP syntax and may adopt standard HTTP authentication mechanisms in combination with suitable network (e.g., IPsec)- or transport (e.g., Transport Layer Security (TLS))-level security. c) SIP -- A typical use of SIP involving a unicast feedback identifier might be a client wishing to dynamically join a multi- party call on a multicast address using unicast RTCP feedback. The client would be required to authenticate the SDP session descriptor information returned by the SIP server. The recommended method for this, as outlined in the SIP specification , is to use an S/MIME message body containing the session parameters signed with an acceptable certificate. For the purposes of this profile, it is acceptable to use any suitably secure authentication mechanism that establishes the identity and integrity of the information provided to the client. 3] is the recommended Audio/Video Transport (AVT) security framework for RTP sessions. It specifies the general packet formats and cipher operations that are used and provides the flexibility to select different stream ciphers based on preference/requirements. It can provide confidentiality of the RTP and RTCP packets as well as protection against integrity compromise and replay attacks. It provides authentication of the data stream using the shared-key trust model. Any suitable key- distribution mechanism can be used in parallel to the SRTP streams. b) IPSEC -- A more general group security profile that might be used is the Group Domain of Interpretation , which defines the process of applying IPSec mechanisms to multicast groups. This requires the use of the Encapsulating Security Payload (ESP) in tunnel mode as the framework and it provides the capability to authenticate -- either using a shared key or individually through public-key mechanisms. It should be noted that using IPSec would break the 'transport-independent' condition of RTP and would therefore not be useable for anything other than IP-based communication. c) TESLA - Timed Efficient Stream Loss-Tolerant Authentication (TESLA)  is a scheme that provides a more flexible approach to data authentication using time-based key disclosure. The
authentication uses one-way, pseudo-random key functions based on key chain hashes that have a short period of authenticity based on the key disclosure intervals from the source. As long as the receiver can ensure that the encrypted packet is received prior to the key disclosure by the source, which requires loose time synchronization between source and receivers, it can prove the authenticity of the packet. The scheme does introduce a delay into the packet distribution/decryption phase due to the key disclosure delay; however, the processing overhead is much lower than other standard public-key mechanisms and therefore may be more suited to small or energy-restricted devices. 29] is the preferred solution for SRTP sessions providing a shared group-key distribution mechanism and intra-session rekeying facilities. If a partly protected communication channel exists, keys may also be conveyed using SDP as per . b) GSAKMP -- The Group Secure Association Key Management Protocol (GSAKMP) is the general solution favored for Multicast Secure group-key distribution. It is the recommended key distribution solution for Group Domain of Interpretation (GDOI) [RFC3547] sessions.
only case that may face such a problem, it is desirable to find a solution that is applicable to RTP at large. Such mechanisms are for further study in the AVT WG. Section 11, but would not actually break the operation of RTP. For RTP-compliant receivers that do not understand the unicast mechanisms, the RTCP traffic may still reach the group in the event that an ASM distribution network is used, in which case there may be some duplication of traffic due to the reflection channel, but this should be ignored. It is anticipated, however, that typically the distribution network will not enable the receiver to multicast RTCP traffic, in which case the data will be lost and the RTCP calculations will not include those receivers. It is RECOMMENDED that any session that may involve non- unicast-capable clients should always use the simple packet- reflection mechanism to ensure that the packets received can be understood by all clients. 2], a new RTCP packet format has been registered with the RTCP Control Packet type (PT) Registry: Name: RSI Long name: Receiver Summary Information Value: 209 Reference: This document. This document defines a substructure for RTCP RSI packets. A new sub-registry has been set up for the sub-report block type (SRBT) values for the RSI packet, with the following registrations created initially:
Name: IPv4 Address Long name: IPv4 Feedback Target Address Value: 0 Reference: This document. Name: IPv6 Address Long name: IPv6 Feedback Target Address Value: 1 Reference: This document. Name: DNS Name Long name: DNS Name indicating Feedback Target Address Value: 2 Reference: This document. Name: Loss Long name: Loss distribution Value: 4 Reference: This document. Name: Jitter Long name: Jitter Distribution Value: 5 Reference: This document. Name: RTT Long name: Round-trip time distribution Value: 6 Reference: This document. Name: Cumulative loss Long name: Cumulative loss distribution Value: 7 Reference: This document. Name: Collisions Long name: SSRC Collision list Value: 8 Reference: This document. Name: Stats Long name: General statistics Value: 10 Reference: This document.
Name: RTCP BW Long name: RTCP Bandwidth indication Value: 11 Reference: This document. Name: Group Info Long name: RTCP Group and Average Packet size Value: 12 Reference: This document. The value 3 shall be reserved as a further way of specifying a Feedback Target Address. The value 3 MUST only be allocated for a use defined in an IETF Standards Track document. Further values may be registered on a first come, first served basis. For each new registration, it is mandatory that a permanent, stable, and publicly accessible document exists that specifies the semantics of the registered parameter as well as the syntax and semantics of the associated sub-report block. The general registration procedures of  apply. In the registry for SDP parameters, the attribute named "rtcp- unicast" has been registered as follows: SDP Attribute ("att-field"): Attribute Name: rtcp-unicast Long form: RTCP Unicast feedback address Type of name: att-field Type of attribute: Media level only Subject to charset: No Purpose: RFC 5760 Reference: RFC 5760 Values: See this document.  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
 Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.  Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", RFC 4570, July 2006.  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.  Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.  Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.  Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.  Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.  Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003.  Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.  Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, June 2009.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.  Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
 Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, October 2003.  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.  Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.  Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.  Fenner, B., Ed., and D. Meyer, Ed., "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.  Session Directory Rendez-vous (SDR), developed at University College London by Mark Handley and the Multimedia Research Group, http://www-mice.cs.ucl.ac.uk/multimedia/software/sdr/.  Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The Group Domain of Interpretation", RFC 3547, July 2003.  Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.  Friedman, T., Ed., Caceres, R., Ed., and A. Clark, Ed., "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.  Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.  Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real- time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, February 2008.
Figure 3. Obviously, no further configuration for the interaction between the Media Sender and the Distribution Source is necessary. Source-specific +--------+ Multicast | | +----------------> R(1) |M D S | | | |E I O | +--+ | |D S U | | | | |I T R | | +-----------> R(2) | |A R C |->+----- : | | | = I E | | +------> R(n-1) | | |S B | | | | | | |E U | +--+--> R(n) | | | |N T | | | | | |D I |<---------+ | | | |E O |<---------------+ | | |R N |<--------------------+ | | |<-------------------------+ +--------+ Unicast Figure 3: Media Source == Distribution Source
This scenario is depicted in Figure 4. The communication setup between the Media Sender and the Distribution Source may be statically configured or SDP may be used in conjunction with some signaling protocol to convey the session parameters. Note that it is a local configuration matter of the Distribution Source how to associate a session between the Media Sender and itself (the Contribution session) with the corresponding session between itself and the receivers (the Distribution session). Source-specific +-----+ Multicast | | +----------------> R(1) | D S | | | | I O | +--+ | | S U | | | | +--------+ | T R | | +-----------> R(2) | | Media |<---->| R C |->+----- : | | | Sender | | I E | | +------> R(n-1) | | +--------+ | B | | | | | | | U | +--+--> R(n) | | | | T | | | | | | I |<---------+ | | | | O |<---------------+ | | | N |<--------------------+ | | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (unicast or ASM) (SSM) Figure 4: One Media Sender Separate from Distribution Source
The configuration of the Media Senders is identical to the previous case. It is just the Distribution Source that must be aware that there are multiple senders and then perform the necessary relaying. The transport address for the RTP session at the Distribution Source may be identical for all Media Senders (which may make correlation easier) or different addresses may be used. This setup is depicted in Figure 5. Source-specific +-----+ Multicast +--------+ | | +----------------> R(1) | Media |<---->| D S | | | |Sender 1| | I O | +--+ | +--------+ | S U | | | | | T R | | +-----------> R(2) | +--------+ | R C |->+----- : | | | Media |<---->| I E | | +------> R(n-1) | | |Sender 2| | B | | | | | | +--------+ | U | +--+--> R(n) | | | | T | | | | | +--------+ | I |<---------+ | | | | Media |<---->| O |<---------------+ | | |Sender 3| | N |<--------------------+ | +--------+ | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (unicast) (SSM) Figure 5: Three Media Senders, Unicast Contribution
The ASM contribution group may be statically configured or the necessary information can be communicated using a standard SDP session description for a multicast session. Again, it is up to the implementation of the Distribution Source to properly associate the ASM contribution session and the SSM distribution sessions. Figure 6 shows this scenario. _ Source-specific / \ +-----+ Multicast +--------+ | | | | +----------------> R(1) | Media |<->| A | | D S | | | |Sender 1| | S | | I O | +--+ | +--------+ | M | | S U | | | | | | | T R | | +-----------> R(2) | +--------+ | G | | R C |->+----- : | | | Media |<->| r |<->| I E | | +------> R(n-1) | | |Sender 2| | o | | B | | | | | | +--------+ | u | | U | +--+--> R(n) | | | | p | | T | | | | | +--------+ | | | I |<---------+ | | | | Media |<->| | | O |<---------------+ | | |Sender 3| \_/ | N |<--------------------+ | +--------+ | |<-------------------------+ +-----+ Unicast Contribution Distribution Session Session (ASM) (SSM) Figure 6: Three Media Senders in ASM Group
First data point = MnDV,first ydata then For each ydata => xdata += (MnDV + (xrange / NDB))
receiver to make a more informed decision about whether it should leave a group that includes a very high percentage of the worst- case reporters. - The organization of a multicast data stream into useful layers for layered coding schemes. The distribution of packet losses and delay would help to identify what percentage of members experience various loss and delay levels, and thus how the data stream bandwidth might be partitioned to suit the group conditions. This would require the same algorithm to be used by both senders and receivers in order to derive the same results. - The establishment of a suitable feedback threshold. An application might be interested to generate feedback values when above (or below) a particular threshold. However, determining an appropriate threshold may be difficult when the range and distribution of feedback values is not known a priori. In a very large group, knowing the distribution of feedback values would allow a reasonable threshold value to be established, and in turn would have the potential to prevent message implosion if many group members share the same feedback value. A typical application might include a sensor network that gauges temperature or some other natural phenomenon. Another example is a network of mobile devices interested in tracking signal power to assist with hand-off to a different distribution device when power becomes too low. - The tuning of Suppression algorithms. Having access to the distribution of round-trip times, bandwidth, and network loss would allow optimization of wake-up timers and proper adjustment of the Suppression interval bounds. In addition, biased wake-up functions could be created not only to favor the early response from more capable group members but also to smooth out responses from subsequent respondents and to avoid bursty response traffic. - Leader election among a group of processes based on the maximum or minimum of some attribute value. Knowledge of the distribution of values would allow a group of processes to select a leader process or processes to act on behalf of the group. Leader election can promote scalability when group sizes become extremely large. Section 7.1.4). The same techniques could also be applied to representing other distribution types.
1) The first method attempts to represent the data in as few bytes as possible. 2) The second method conveys all values without providing any savings in bandwidth. Data Set X values indicate loss percentage reported; Y values indicate the number of receivers reporting that loss percentage. X - 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 Y - 1000| 800 | 6 | 1800 | 2600 | 3120 | 2300 | 1100 | 200 | 103 X - 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 Y - 74 | 21 | 30 | 65 | 60 | 80 | 6 | 7 | 4 | 5 X - 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 Y - 2 | 10 | 870 | 2300 | 1162 | 270 | 234 | 211 | 196 | 205 X - 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 Y - 163 | 174 | 103 | 94 | 76 | 52 | 68 | 79 | 42 | 4 Constant value Due to the size of the multiplicative factor field being 4 bits, the maximum multiplicative value is 15. The distribution type field of this packet would be value 1 since it represents loss data. Example: 1st Method Description The minimal method of conveying data, i.e., small amount of bytes used to convey the values. Algorithm Attempt to fit the data set into a small sub-report size, selected length of 8 octets Can we split the range (0 - 39) into 16 4-bit values? The largest bucket value would, in this case, be the bucket for X values 5 - 7.5, the sum of which is 5970. An MF value of 9 will generate a multiplicative factor of 2^9, or 512 -- which, multiplied by the max bucket value, produces a maximum real value of 7680.
The packet fields will contain the values: Header distribution Block Distribution Type: 1 Number of Data Buckets: 16 Multiplicative Factor: 9 Packet Length field: 5 (5 * 4 => 20 bytes) Minimum Data Value: 0 Maximum Data Value: 39 Data Bucket values: (each value is 16-bits) Results, 4-bit buckets: X - 0 - 2.5 | 2.5 - 5 | 5 - 7.5 | 7.5 - 10 (Y - 1803 | 4403 | 5970 | 853 ) ACTUAL Y - 4 | 9 | 12 | 2 X - 10 - 12.5 | 12.5 - 15 | 15 - 17.5 | 17.5 - 20 (Y - 110 | 140 | 89.5 | 12.5) ACTUAL Y - 0 | 0 | 0 | 0 X - 20 - 22.5 | 22.5 - 25 | 25 - 27.5 | 27.5 - 30 (Y - 447 | 3897 | 609.5 | 506.5) ACTUAL Y - 1 | 8 | 1 | 1 X - 30 - 32.5 | 32.5 - 35 | 35 - 37.5 | 37.5 - 40 (Y - 388.5 | 221.5 | 159.5 | 85.5) ACTUAL Y - 1 | 0 | 0 | 0 Example: 2nd Method Description This demonstrates the most accurate method for representing the data set. This method doesn't attempt to optimise any values. Algorithm Identify the highest value and select buckets large enough to convey the exact values, i.e., no multiplicative factor. The highest value is 3120. This requires 12 bits (closest 2 bit boundary) to represent, therefore it will use 60 bytes to represent the entire distribution. This is within the max packet size; therefore, all data will fit within one sub-report block. The multiplicative value will be 1.
The packet fields will contain the values: Header Distribution Block Distribution Type: 1 Number of Data Buckets: 40 Multiplicative Factor: 0 Packet Length field: 18 (18 * 4 => 72 bytes) Minimum Loss Value: 0 Maximum Loss Value: 39 Bucket values are the same as the initial data set. Result Selecting one of the three methods outlined above might be done by a congestion parameter or by user preference. The overhead associated with processing the packets is likely to differ very little between the techniques. The savings in bandwidth are apparent, however, using 20, 52, and 72 octets respectively. These values would vary more widely for a larger data set with less correlation between results.