SUBGROUP FEEDBACK FOR SOURCE-SPECIFIC MULTICAST

Dan Komosny

Dept. of Telecommunications, Brno University of Technology, Purkynova 118, 612 00 Brno, Czech Republic

Keywords: Multicast, Source-specific, Feedback, Subgroup.

Abstract: The recent deployment of IP-based TV and radio distributions requires one-to-many multicast instead of the

traditional many-to-many data distribution. These large multimedia sessions usually rely on the real time

protocol (RTP) and the real time control protocol (RTCP). Although one-to-many multicast offers the

required communication, it does not support the multicast feedback channel for carrying the RTCP control

messages. Therefore, unicast feedback channels from session members to the source are used to carry these

messages. In this paper, we introduce subgroup feedback scenarios for source-specific multicast, which is

built on the one-to-many philosophy. Our extensions are based on the subgroup feedback framework

standardized in the IETF. We outline a possible implementation of the subgroup feedback using the receiver

summary information (RSI) packet. A theoretical RSI packet rate analysis is also presented in the paper.

1 INTRODUCTION

New IP-based broadcasting services currently being

deployed do not require many-to-many

communication offered by the well-known any

source multicast (ASM) (Quinn and Almeroth,

2001). As a result, instead of many-to-many, a new

one-to-many philosophy is preferred. To support

this, source-specific multicast (SSM) (Holbrook and

Cain, 2004), (Bhattacharyya, 2003) has been

developed. SSM is expected to cover all types of IP-

based multimedia sessions with many receivers and

only one source, such as IPTV broadcasting.

Multicast sessions (either ASM or SSM) typically

rely on the RTP/RTCP (Real Time Protocol/ Real

Time Control Protocol) protocol (Schulzrinne et al.,

2003). The RTP flow carries multimedia data,

whereas the RTCP flow carries signalization and

synchronization. RTCP, which is more sophisticated

than RTP, provides a set of messages exchanged

among session members. These messages are used

as a feedback for monitoring the session behavior.

The session feedback could be used, for example,

for the parameterization of multicast forward error

correction (FEC) or the tuning of suppression

algorithms. The feedback flow usually involves

information such as a summary of data sent,

synchronization of different transmitted media

(audio, video), packet loss, packet delays, and

interarrival jitter. This information can be also used,

for example, to localize distribution problems for

particular receivers. Furthermore, a third-party

application could receive the feedback flow for long-

term session monitoring.

However, SSM lacks the support for

communication among session members (i.e. many-

to-many). Therefore, RTCP packets cannot be

transmitted since SSM does not offer the required

feedback channel. Feedback RTCP data are

transmitted using several packet types. The two

basic types are sender report SR (it carries

transmission and reception statistics) transmitted

from the source to receivers, and receiver report RR

(it carries reception statistics) transmitted from

receivers to the source. The existing solutions use

unicast feedback connections from receivers to the

source. The two known methods are: reflection and

summarization (Chesterfield and Schooler, 2003).

Both methods deal with the same transmission of

RR packets from receivers back to the source, but

they differ in processing the packets received at the

source. After processing the received data, the

feedback data are sent back via SSM to all session

receivers, as depicted in Figure 1. With the

reflection method, the source forwards every RR

packet to all session receivers. However, the

forwarding could be harmful to the network load,

especially with the session size growing. In addition,

the source does not need to forward all the received

data – some of them are necessary only for the

295

Komosny D. (2006).

SUBGROUP FEEDBACK FOR SOURCE-SPECIFIC MULTICAST.

In Proceedings of the International Conference on Signal Processing and Multimedia Applications, pages 295-301

DOI: 10.5220/0001569502950301

 SciTePress

source, not for the receivers. On the other hand,

problematic receivers can be easily identified and

certain actions can be taken to improve the session

quality. The reflection method is backward

compatible with currently used RTP/RTCP

implementations. The traffic generated by the

source, when RR packets are forwarded, is not

regarded as traffic belonging to the source.

The summarization method deals with an

aggregation of selected receivers' data from RR

packets in the source. When an aggregation is

finished, a summary packet is assembled and sent to

all receivers via multicast. Several known algorithms

can be used for aggregating the received values

(Chesterfield et al., 2004). In addition, the

aggregated values can be compressed up to a factor

of 16. The compression significance is growing

when large sessions are being used. The resulting

summary information is conveyed using the

Receiver Summary Information packet (RSI)

(Chesterfield et al., 2004) containing several

elementary fields for encapsulating the carried

information, such as timestamps and group size. The

RSI packet also has several optional sub-report

blocks that follow the RSI packet: loss, jitter,

cumulative loss, general statistics and receiver

bandwidth. These sub-report blocks are considered

an enhancement to the key information required by

receivers. The source sends one RSI packet per one

reporting interval. The RSI packets are sent together

with the sender SR packets.

2 FEEDBACK RATE PROBLEM

One of the major problems with RTP/RTCP is the

large delays between sending RTCP packets from a

session member (Rosenberg and Schulzrinne, 1998).

As mentioned above, RTCP provides feedback about

the multimedia session quality. This information is

usually used by high-layer protocols to control and

monitor the session behavior. Thus, the session

control is strongly affected by the feedback reporting

frequency. This means that even minimally outdated

values can burden further data processing with an

error and consequently the behavior of the session

can be faulty. Therefore, the RTCP packets (either

SR or RR) should be sent as often as possible. On

the other hand, many RTCP packets can load the

assigned session channel too much. Besides that,

there is a possibility that not enough bandwidth is

left for the multimedia flow carried by RTP packets.

In case of large sessions, RTCP packets can interfere

with RTP packets and cause packet delay and loss.

Therefore, a mechanism to control the frequency of

RTCP packets is used. The algorithm used keeps the

frequency of RTCP packets at a value corresponding

to 5% of the total allowed session bandwidth.

Furthermore, 3.75% of the session bandwidth is used

by RR packets and 1.25% of the session bandwidth

is used by SR packets.

With an SSM session, the RR packet rate PR

thus calculated as

0.75× BW

rtcp

× n

(1)

and the SR packet rate PR

is identified as

0.25 × BW

rtcp

× n

(2)

where PS

is the average size of the RR packet, PS

is the average size of the SR packet, BW

rtcp

is the

allowed bandwidth used for RTCP packets, n

is the

number of receivers, and n

is the number of senders

of an SSM session. The formulas assume that the

number of senders is less than or equal to 25% of

session members - an SSM session has only one

sender. Also, it is assumed that the session has four

receivers or more. The algorithm used gives 25% of

the RTCP bandwidth to senders and 75% of the

RTCP bandwidth to receivers.

For the purpose of feedback rate problem

description, it is necessary to determine the RR

packet size. Using the values presented in

Figure 1: Unicast feedback with SSM.

1 10 100 1000 10000

0.001

0.01

0.1

100

5 sec. limit

PRrr

Session members

RR packet rate [pkt/sec]

Figure 2: RR packet rate vs. session members for 1Mbps

session bandwidth.

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS

296

(Chesterfield and Schooler, 2002), the average RR

packet size is set to 736bits. As an example, the

identified RR packet rate for 1Mbps session

bandwidth is depicted in Figure 2. The graph reveals

that with a great number of receivers the RR packet

rate is very low. For example, for 10 000 session

members the rate is 0.005 pkt/sec (200 seconds per

member). However, this number of members is

expected when certain services are provided, such as

IPTV broadcasting. Thus, some values reported by

session members could lose their importance if they

become too old. This problem has been identified as

one of three major problems with RTP/RTCP - a

low rate of session member reports when the session

grows extremely large. Furthermore, the dashed line

in the graph shows the minimum transmission

interval between RR packets – 0.2pks/sec (5

seconds per member). The purpose of the limitation

is to avoid packet floods when the session behaves

unexpectedly (Schulzrinne et al., 2003). For

instance, when a session is experiencing a network

part failure, the number of session members could

become extremely small during a short period of

time.

With the RTP/RTCP multicast, not all the

feedback data from session members are of equal

importance. This means that some member feedback

needs to be reported more frequently. For that

purpose, a biasing algorithm was developed for SSM

with the summarization method (Chesterfield and

Schooler, 2003). The algorithm is built on sampling

the feedback for a specific range of values. Then,

members reporting values within this range are

treated as biased. The remaining members are

unbiased. The source conveys to the receivers its

selection range. For the biased group of members,

for example, the source can increase the amount of

allowed bandwidth and decrease the bandwidth for

the unbiased members.

3 SUBGROUP FEEDBACK

SCENARIOS

In this section, we propose two new subgroup

feedback scenarios for SSM sessions with the sender

summary model. For simplicity, we assume one

subgroup within a session. Our proposal is based on

two possible uses of the multicast subgroup

feedback – the hierarchical aggregation used to

reduce SSM feedback latency (Chesterfield and

Schooler, 2003) and multimedia transmission

monitoring application. With these applications, the

feedback from the subgroup members is more

important to receive than any other feedback. In the

case of using the hierarchical aggregation, a

subgroup member acts as summarization server for a

group of other multicast members. Members from

this group report theirs feedback to the

summarization server and the server puts the

feedback into a single summary. Summarization

servers are members of another group placed higher

up. As other multicast members join or leave the

session, the number of remaining members in this

group varies. In the case of using a transmission

monitoring application, the subgroup members could

be, for example, constant sensors reporting rough

values of the whole monitored multimedia system.

As other sensors join or leave the session, the

number of remaining session members again varies.

Figure 3 shows possible scenarios for the subgroup

feedback framework. The three following cases are

considered:

• Case a) A subgroup sends RR reports to

the IP feedback address of the source

This scenario was previously described in the

biasing method. The source receives the feedback

values from both the subgroup and the remaining

session members. The valuable feature is that the

feedback rate of subgroup members could be

adjusted as desired. However, the 5% limit of the

session assigned bandwidth has to be achieved. With

this scenario, for example, the source can specify a

subgroup with problematic session members and

speed up their feedback rate or slow down the

feedback of other session members whose feedback

is not so important. A monitor application shown in

the figure receives the feedback data from all session

members via multicast. Therefore, the reported

values cannot be assigned to a particular session

member.

• Case b) A subgroup sends RR reports to

the IP feedback address of a LAN monitor

Now the sender does not receive the subgroup

feedback. Since the feedback rate from the subgroup

is outside the session bandwidth control, it is

possible to speed up the feedback rate as desired,

outside of the 5% restriction. This scenario is

expected to be applied in a multimedia transmission

monitor application. Also, this scenario brings an

advantage of comparing the feedback data from all

session members with data received only from the

subgroup. In this way, a subgroup sample could be

SUBGROUP FEEDBACK FOR SOURCE-SPECIFIC MULTICAST

297

set up and used for describing the whole session

behavior. The subgroup size should be set carefully

with certain applications. A large subgroup could

make the whole session behavior faulty since not

enough feedback is provided for the source. A

monitor application could receive feedback values

from the whole session and also from the subgroup

members.

• Case c) A subgroup sends RR reports to

both a LAN monitor and the source

The third case deals with the reflection of the

subgroup feedback data from session members. The

session feedback acts as described in case a) and

furthermore a new feedback rate above the 5% limit

could be defined for a LAN monitor.

For the purpose of specifying a subgroup, the

feedback reported values could be used. Feedback

data for RTP/RTCP sessions are introduced in

(Schulzrinne et al., 2003). They are, among other

things, loss distribution, jitter distribution, round trip

time distribution, cumulative loss, and general

statistics. Furthermore, we use an additional

subgroup parameter, the feedback sender IP address,

for a session member localization. These subgroup

parameters could be mixed to create a subgroup

defined by several requirements. As with the biasing

method, subgroup rules based on the selected

feedback parameters are defined. The source

transfers the rules to session members. When a

session member receives the defined rules, it

compares them with own feedback reported values.

If the feedback data meet the subgroup required

criteria, a member joins the subgroup.

3.1 Implementation of Extended

Subgroup Feedback

The source informs session members that its

reporting values are or are not within the desired

range to join a subgroup, as introduced above. Since

a session member cannot be identified in the sender

summary report model, it is not possible to send

such information to a particular member. Therefore,

we have adopted the RSI packet used purely in the

sender summary report model. The RSI packet

consists of various types of information

encapsulated in optional sub-report blocks that

follow after the fixed header. Optional sub-report

blocks use a generic format that includes sub-report

block size (SRBT), length and sub-report specific

data. Furthermore, to carry distributions of values

(i.e. loss, RTT), a data bucket format is used. This

format divides data into variable length buckets.

Among other things, minimum and maximum

distribution values are included to indicate the data

bucket range. We have extended the RSI packet in

order to allow subgroup parameters to be

encapsulated in a new RSI packet sub-report block

called session subgroups. This new packet block

consists of the following fields: SRBT, length,

number of subgroups, and subgroup description. A

subgroup description format is: length, number of

members, IP feedback address, IP feedback port, IP

feedback address flag, and allowed bandwidth. The

feedback flag says whether the feedback traffic is

reflected to both the source and the feedback address

or only the feedback address is used. What follows

is the subgroup rules formatted as number of rules

and rule description. The rule description consists of

the ID number of the parameter. We use IDs as

defined in (Chesterfield et al., 2004) and parameter

minimum and maximum values for the rule

parameter. The number of rules per group is limited

to 255. The packet structure is depicted in Figure 4.

Figure 3: Subgroups feedback scenarios.

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS

298

3.2 Analysis of the Adopted RSI

Packet Rate

The sender should send at least one RSI packet for

each calculated reporting interval, as was given in

(Chesterfield et al., 2004). However, the RSI packet

sub-report blocks are optional as we mentioned

above. It is recommended that no more than 20% of

the bandwidth assigned to a session member is used

to carry the optional information in RTP/RTCP

sessions. Packet rates above this limit could result in

protocol misbehavior. Therefore, the adopted RSI

packet rate should be lower than the original one. To

meet this requirement, we have recalculated the

adopted RSI packet rate. Considering that there is

only one sender in an SSM session, the packet rate

for sender reports is from equation (2)

identified as

0.25 × BW

rtcp

(3)

provided that there are at least four session

members. Supposing that PR

rsi

is equal to PR

and

10% of the bandwidth assigned to the sender is used

to carry optional information, the packet rate for the

adopted RSI packet PR

rsi_adp

can be calculated as

rsi_adp

0.025 × BW

rtcp

rsi_adp

(4)

where PS

rsi_adp

is the size of the adopted RSI packet.

Based on equation (4), the adopted RSI packet size

must be included in the calculation. Thus, we

assume these field lengths of the adopted RSI packet

(Chesterfield et al., 2004): fixed header - 160bits,

SRBT - 8bits, length - 8bits, number of subgroups -

8bits. A subgroup consists of length - 32bits,

subgroup members - 32bits, IPv4 feedback address –

32bits, IPv4 feedback port – 16bits, feedback flag –

1bit, allowed bandwidth – 32bits and the number of

rules - 8bits. A subgroup rule consists of the ID

number - 8bits, minimum value – 32bits and

maximum value - 32bits. Therefore, for the purpose

of theoretical calculations, the estimated average

packet size PS

rsi_adp

= 184n

sgr

×145 n

rul

× 72



(5)

where n

sgr

is the number of subgroups in a session

and n

rul

is the number of subgroup rules. Figure 5

examines the calculated adopted RSI packet rate

with n

rul

= 3 and session bandwidth = 64Kbit/s.

The dashed line in the graph shows a minimum

transmission interval between adopted RSI packets

– 0.2 pkt/sec (5 seconds). The purpose of the

limitation is to avoid packet floods when the session

behaves unexpectedly, see (Schulzrinne et al., 2003).

For instance, when a session is experiencing a

network part failure, the number of session members

could be extremely small during a short period of

time. When the values go over the limit, equation (4)

has to be redefined as

rsi_adp

= min 0.2 ,

0.025 × BW

rtcp

rsi_adp



(6)

4 CREATING A NEW SUBGROUP

For the purpose of creating a new subgroup within

an SSM session, we have chosen the application-

defined (APP) RTCP packet introduced in

(Schulzrinne et al., 2003). The packet is intended for

experimental use. In our case, the packet carries

parameters of a subgroup to be created from a

session member to the source. The field called

application-dependent data is used for this purpose.

The data format is the same as we introduced in

section 3.1. When a session member sends a new

subgroup request, the source accepts or denies the

creation of the subgroup. The source should allow

only certain session members to create a new

subgroup in order to avoid subgroup overflow.

Furthermore, creating duplicate subgroups has to be

considered. Therefore, requests for creating a new

subgroup are acknowledged by the source. For the

acknowledgment, we again use the APP packet. If

the session member does not receive the

Figure 4: Adopted RSI packet.

SUBGROUP FEEDBACK FOR SOURCE-SPECIFIC MULTICAST

299

acknowledgment, the request is sent again within a

selected period.

Also, we assume that an application itself is

responsible for the authorization of allowed

members to create a new subgroup. Besides this,

there are quite different requirements on the

subgroup creation process. For example, with a

monitoring application, only one subgroup is

assumed. On the other hand, with the hierarchical

aggregation, the number of subgroups depends on

the number of aggregations levels.

5 CONCLUSION AND RELATED

WORK

Our work has been inspired by one of three major

problems with RTP/RTCP that deals with the low

rate of the session member reports when session

grows extremely large. In this paper, we extended

the subgroup feedback framework for SSM based on

the biasing algorithm for the sender summary model.

The two new subgroup feedback scenarios allow

subgroup members to change their feedback rate in

several ways as desired. A possible use of these

scenarios is the hierarchical aggregation for SSM (a

subgroup member atcs as summarization server for

a group of multicast ordinary members) and

multimedia transmission monitoring application that

uses the multicast feedback channel to report

monitored values (the subgroup members are

constant sensors reporting rough values of the whole

monitored system).

A new feature is the comparison

of subgroup feedback data with feedback from all

the session members. For the purpose of transferring

the subgroup parameters from the source to session

members, we modified the RSI packet by adding

new specific fields. Since the new fields in the

adopted RSI packet are optional, we defined a

packet rate that meets the requirements for optional

data transmission used in RTP/RTCP sessions. For

the purpose of describing the adopted RSI packet

rate, a theoretical analysis was also presented in the

paper.

Our related work deals with setting the

appropriate thresholds for subgroup parameters.

Some feedback values change quite often within a

wide range, for example, packet loss, delay and

jitter. Subsequently, a session member changes its

subgroup identity as these feedback values are above

or below the defined threshold. Thus, session

members should take care when processing the

subgroup parameters. We also aim to extend the

subgroup identification with the parameters

introduced in (Friedman et al., 2003) and (Ott et al.,

2004), such as jitter buffer parameters, configuration

parameters, bit vector chunks, and slice loss

indication.

ACKNOWLEDGEMENTS

This work was supported by the Academy of

Sciences of the Czech Republic (project

1ET301710508).

REFERENCES

Quinn, B., Almeroth, K. (2001). IP Multicast

Applications: Challenges and Solutions. Request for

Comments 3170, Internet Engineering Task Force.

Holbrook, H., Cain, B. (2004). Source-Specific Multicast

for IP. Internet Draft, Internet Engineering Task

Force.

Bhattacharyya, S. (2003). An Overview of Source-Specific

Multicast (SSM). Request for Comments 3569,

Internet Engineering Task Force.

Schulzrinne, H., Casner, S., Frederick, R., Jacobson, V.

(2003). RTP: A Transport Protocol for Real-Time

Applications. Request for Comments 3550, Internet

Engineering Task Force.

Chesterfield J., Schooler E. (2003). An Extensible RTCP

Control Framework for Large Multimedia

Distributions. Proceedings of IEEE International

Symposium on Network Computing and Applications,

Cambridge.

Chesterfield, J., Schooler, E., OTT, J. (2004). RTCP

Extensions for Single-Source Multicast Sessions with

Unicast Feedback. Internet Draft, Internet Engineering

Task Force.

Rosenberg, J., Schulzrinne, H. (1998). Timer

reconsideration for enhanced RTP scalability.

Proceedings of IEEE Infocom.

0 20 40 60 80 100

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

1.10

1.20

1.30

1.40

1.50

Session subgroups (nsgr)

Adopted RSI packet rate [pkt/sec]

Figure 5: Adopted RSI packet rate.

SIGMAP 2006 - INTERNATIONAL CONFERENCE ON SIGNAL PROCESSING AND MULTIMEDIA

APPLICATIONS

300

Chesterfield J., Schooler E. (2002). A comparison of

RTCP standard and summarized feedback models.

Accompaniment to draft-ietf-avt-rtcpssm-01.txt.

Friedman, T., Caceres, R., Clark, A. (2003). RTP Control

Protocol Extended Reports (RTCP XR). Request for

Comments 3611, Internet Engineering Task Force.

Ott, J., Wenger, S., Sato, N., Burmeister, C., Rey, J.

(2004). Extended RTP Profile for RTCP-based

Feedback (RTP/AVPF). Internet Draft, Internet

Engineering Task Force.

SUBGROUP FEEDBACK FOR SOURCE-SPECIFIC MULTICAST

301