One document matched: draft-wu-avt-retransmission-supression-rtp-03.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-wu-avt-retransmission-supression-rtp-03"
ipr="pre5378Trust200902">
<front>
<title abbrev="Feedback Suppression">RTCP Report Extension for Feedback
Suppression</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Frank Xia" initials="F." surname="Xia">
<organization>Huawei</organization>
<address>
<postal>
<street>1700 Alma Dr. Suite 500</street>
<city>Plano</city>
<region>TX 75075</region>
<country>USA</country>
</postal>
<phone>+1 972-509-5599</phone>
<email>xiayangsong@huawei.com</email>
</address>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street>14 David Hamelech</street>
<region>Tel Aviv 64953</region>
<country>Israel</country>
</postal>
<email>even.roni@huawei.com</email>
</address>
</author>
<date month="October" year="2010" />
<workgroup>Network Working Group</workgroup>
<abstract>
<t>This document specifies an extension to the RTCP feedback messages
defined in the Audio-Visual Profile with Feedback (AVPF). This extension
allows an intermediate node in the network (such as an RTP translator)
inform downstream receivers that sending a feedback message concerning a
specified set of RTP messages may be unnecessary, or even harmful. For
example, in a source-specific multicast session with large fan-out,
packet loss close to the media or distribution source of the session is
detected as a loss by a large number of receivers. The RTCP NACK
messages used to request retransmission of the missing packets are all
addressed to the media sender, or a designated feedback target. This may
result in a phenomenon known variously as a "NACK implosion" or
"feedback storm". The Feedback Suppression message defined herein is
used to notify receivers that packet loss was detected and that the
sender of the report will either proactively recover, or no recovery is
possible. Receivers respond to receipt of a feedback suppression message
by not sending a feedback message (e.g. a NACK) that they otherwise
would, This in turn reduces load on both the feedback target and on the
network. This document registers two new RTCP messages for Feedback
Suppression.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>RTCP feedback messages <xref target="RFC4585"></xref>allow the
receivers in an RTP session to report events and ask for action from the
sender (or a delegated feedback target). There are cases where multiple
receivers may initiate the same, or an equivalent message towards the
same sender. When the receiver count is large, this behavior may
overload the sender or the network or both. One common case is receivers
utilizing RTP retransmission as a packet loss recovery technique in a
real-time application such as streaming video or audio.<xref
target="RFC4588"></xref>Feedback is accomplished using the RTCP NACK
message which conveys the RTP sequence number(s) of the lost packet(s).
This information can then be used by the sender to retransmit the
missing RTP packets using the RTP retransmission payload format<xref
target="RFC4585"></xref>.</t>
<t>However, in topologies utilizing transport translators
(Topo-Trn-Translator) or large-scale multicast transmission
(Topo-Multicast) as defined in <xref target="RFC5117"></xref>, packet
loss can occur on either an upstream link or a downstream aggregate link
of the intermediate network element (e.g., Retransmission server,
Distribution Source). Where there are many receivers, this may result in
a NACK implosion towards the sender, i.e., large number of NACK requests
to the same multicast sender for retransmission of the same RTP packets.
This phenomenon goes by a number of alternate names, such as the “NACK
storm” terminology of <xref target="DVB-IPTV"></xref>. In an attempt to
increase its robustness against the loss of a NACK message or of
retransmission packets, a receiver may send multiple NACKs for the same
detected packet loss, which may aggravate the NACK implosion.</t>
<t>Another use case involves video Fast Update requests. A storm of
these feedback messages can occur in conversational multimedia scenarios
like Topo-Video-switch-MCU <xref target="RFC5117"></xref>. In this
scenario, packet loss may happen on an upstream link of an intermediate
network element such as a Multipoint Control Unit(MCU). Receivers
missing the packets issue fast update requests (i.e., Full Intra
Request(FIR) described in [RFC5104]), which results in an implosion of
FIR requests from receivers to the same media sender.</t>
<t>As these feedback storms propagate (e.g., NACK implosion or Fast
update implosion), the network may be permeated with more and more
feedback traffic, resulting in a positive feedback loop as the network
is also saturated with media traffic. RTCP feedback storms pose a
substantial risk of increasing network congestion, and in extreme cases
to congestion collapse on the control channel (e.g. RTCP feedback), the
data channel (i.e. RTP restransmission), or both.</t>
<t>In order to mitigate these behaviors, the current text in <xref
target="RFC5760"></xref> allows the distribution source to filter out
the NACK messages and <xref target="DVB-IPTV"></xref> suggests sending a
NACK message from sender to the receiver. However NACK is defined as a
receiver report sent from a receiver to the sender and therefore
exhibits a semantic mismatch when used as a suppression indication from
the sender (or intermediary) to the receiver. This document instead
specifies a newly message for this function. It further is more precise
in the intended uses and less likely to be confusing to receivers. It
tells receivers explicitly that feedback for a particular packet loss is
not needed and can provide an early indication before the receiver
reacts to the loss and invokes its packet loss repair machinery.</t>
<t>The Feedback Suppression message asks a receiver to not send feedback
messages for particular packets (indicated by their RTP sequence
numbers) independent of whether the receiver detected the packet loss or
detected a need for a decoder refresh point).</t>
<t>In order to detect packet loss before the receivers perceive it, one
or more intermediate nodes are placed between the media sender and
receiver (e.g., Distribution server, MCU, RTP translator). These
intermediaries monitor for packet loss upstream of themselves by
checking RTP sequence numbers, just as receivers do. Upon detecting (or
suspecting) an upstream loss, the intermediary may either initiate its
own feedback toward the source to provoke a retransmission, send
Feedback Suppression message towards the receivers as defined in this
specification, or both.</t>
<t>Instead of using specialized intermediaries, another possibility is
to instantiate one or more RTP receivers upstream of the loss region to
act as immediate reporters as described in<xref
target="DVB-IPTV"></xref>. These intermediate nodes need to take into
account such factors as the tolerable application delay, the network
dynamics, and the media type. When the packet loss is detected upstream
of the intermediary and additional latency is tolerable, the
intermediate node may itself send a feedback message asking for
retransmission of the suspected lost packet or ask for the correct
decoder refresh point. Because it has already provided the necessary
feedback toward the source, the intermediate node can be reasonably
certain that it will help the situation by sending a Feedback
Suppression message to all the relevant receivers, thereby indicating
that the receivers should not themselves transmit feedback messages.
When the sender receives the request from the intermediate node, the
sender resends the missing packets to the receivers by using the RTP
retransmission payload format <xref target="RFC4588"></xref>or resends a
new refresh point for FIR Initiator <xref target="RFC5104"></xref>,
depending on the type of feedback it received.</t>
<t>RTCP Feedback Storm Suppression follows the same semantic model as
RTCP NACK - it conveys the packet receipt/loss events at the sequence
number level and considers missing packets as unrepaired. But unlike
RTCP NACK, the Feedback Suppression messages can be generated at
intermediate nodes who are not RTP receivers and sent to the
corresponding receivers. Intermediaries downsteam of an intermediary
detecting loss obviously SHOULD NOT initiate their own additional
feedback suppression messages for the same packet sequence numbers. They
may either simply forward the Feedback Suppression message received from
upstream, or augment (or replace) it with a feedback suppression message
that reflects the loss pattern they have themselves seen.</t>
<t>Since feedback suppression interacts strongly with repair timing, it
has to work together with feedback and retransmission to not adversely
impact the repair of lost source packets. In some cases where the loss
was detected and repair initiated much closer to the source, the delay
for the receiver to recover from packet loss can be reduced through the
combination of intermediary feedback to the source and feedback
suppression downstream. In all (properly operating) cases, the risk of
increasing network congestion is decreased. A receiver may still have
sent a Feedback message before receiving a feedback suppression message,
but further feedback messages for those sequence numbers will be
suppressed by this technique.</t>
<t>This document registers two new RTCP Feedback messages for Feedback
Suppression. Applications that are employing one or more loss-repair
methods MAY use Feedback Suppression together with their existing
loss-repair methods either for every packet they expect to receive, or
for an application-specific subset of the RTP packets in a session. In
other words, receivers MAY ignore Feedback Suppression messages, but
SHOULD react to them unless they have good reason to still send feedback
messages despite having been requested to suppress them.</t>
</section>
<section title="Terminology">
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
<t><list style="hanging">
<t hangText="Intermediate Source:"><vspace blankLines="1" />One
intermediate node with logical function which is used to process or
foward packet at the RTP layer. The intermediate Source is located
between media sender and receivers. The examples of intermediate
source are Distribution server, MCU, RTP translator.<vspace
blankLines="1" /></t>
<t hangText="Upstream RTP Client:"><vspace blankLines="1" />An RTP
Client located in the upstream from the intermediate source as
described in <xref target="DVB-IPTV"></xref>. This Client is able to
detect upstream packet loss impacting all the RTP receivers serviced
by the intermediate source and receiving SSM service.<vspace
blankLines="1" /></t>
<t hangText="Immediate reporting RTP Client:"><vspace
blankLines="1" />An RTP Client located on a downstream aggregate
link from the intermediate source as described in <xref
target="DVB-IPTV"></xref>. This Client is able to detect downstream
packet loss on the aggregate link or other nodes upstream of the
aggregat link, thus impacting all the RTP receivers serviced by the
intermediate source and receiving SSM service.<vspace
blankLines="1" /></t>
<t hangText="Loss Reporter:"><vspace blankLines="1" />The Loss
Reporter is one logical function which is used to detect the packet
loss at the RTP layer and report it to the intermediate source. The
function of the loss reporter may be collocated with or integrated
into the same entity. In this case, for a session defined as having
a intermediate source A, on ports n for the RTP channel and k for
the RTCP channel, the unicast RTCP Feedback Target is identified by
an IP address of intermediate source A on port k. The loss reporter
MAY also be implemented in one or more entities different from the
intermediate source. In this case, the loss reporter may be an
upstream RTP client or immediate reporting RTP client located on a
downstream aggregate link of the intermediate source.</t>
</list></t>
</section>
<section title="Protocol Overview">
<t>In order to avoid the forms of NACK implosion described in section 1,
the loss reporter is introduced. The loss reporter detects and reports
packet loss, on both the upstream link and the downstream aggregate
link. When upstream link or downstream aggregate link packet loss
occurs, the Loss reporter may inform intermediate source of the detected
packet loss using Feedback Suppression messages. In response, the
intermediate source either forwards packet loss suppression report
received from loss reporter or creates a Feedback Suppression report and
sends it to all the RTP receivers, over the multicast channel. This loss
suppression report tells the receivers that the lost packet will either
be forthcoming from intermediate source via retransmission, or it
irretrievably lost such that there is nothing to be gained by the
receiver sending a NACK to the media sender. The intermediate source
then can (optionally) ask for retransmission of the lost packets from
the media sender on behalf of all the RTP receivers. Upon receiving the
lost packet via the RTP retransmission payload format, the intermediate
source forwards the retransmitted packet to all the receivers.</t>
<t>When the loss reporter(s) are part of a feedback target collocated
with the intermediate source, redistribution of the feedback suppression
report is trivial. In such cases, the loss reporter function in the
feedback target detects packet loss coming from an upstream link and
informs the collocated intermediate source. Also the loss reporter may
detect packet loss occurring within intermediate source itself and
report to intermediate source using the same method. When the loss
reporter(s) are physically and(or) topologically distinct from
intermediate source, each loss reporter MUST create a packet loss report
using the similar format as conventional RTCP NACK packets at the RTP
layer and send it to the intermediate source . The loss reporters may be
upstream client or downstream immediate reporter who is dedicated to
detect and report packet loss.</t>
<t>The intermediate source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
feedback. The general architecture is displayed below in Figure 1.</t>
<t>The Intermediate Source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
feedback. The general architecture is displayed below in <xref
target="fig1"></xref><figure align="center" anchor="fig1"
title="System Architecture">
<artwork>
+--------+ +------------+ Source-specific
|Media | | | Multicast
|Sender 1|<------->| | +----------------> R(1)
+--------+ |Intermediate| |
| SOURCE | +--+
+--------+ | | | |
|Media |<------->| | | +-----------> R(2)
|Sender 2| | Feedback |->+ +---- :
+--------+ |+ Target --+| | +------> R(n-1)
: || +---+ || | |
: || | R| || +--+--> R(n)
|| | E| ||
+--------+ || |L P| ||
|Media | || |O O| ||
|Sender M|<---- -->|| |S R| ||
+--------+ || |S T| ||
|| | E| ||
|| | R| ||
|| +---+ ||
|+----------+|
+------------+
Transport of packet loss informationfrom the Loss Reporter to the
Feedback Target is via unicast RTCP feedback if the two are not
co-located.
</artwork>
</figure>In this figure, we assume the intermediate source is
separated from a particular media sender and the loss reporter is part
of feedback target collocated with intermediate source. The
communication between the media sender and the intermediate source is
compliant with the methods described in <xref target="RFC5760"></xref>.
Configuration information also follows <xref target="RFC5760"></xref>,
with the following additional considerations:<vspace
blankLines="1" /><list style="symbols">
<t>The Loss Reporters know the addresses of their respectively
responsible Feedback Targets.</t>
</list></t>
</section>
<section title="RTCP Receiver Feedback Report Extension">
<section title="Transport Layer Feedback Message ">
<section title="NACK implosion Suppression Summary report">
<t>The NACK implosion Suppression message is an extension to the
RTCP feedback report and identified by RTCP packet type value
PT=RTPFB and FMT=TBD.</t>
<t>The FCI field MUST contain one or more NACK Suppression Early
Indication (NSEI) entries. Each entry applies to a different media
sender, identified by its SSRC.</t>
<t>The Feedback Control Information (FCI) for NSEI uses the similar
format of message Types defined in the section 4.3.1.1 of <xref
target="RFC5104"></xref>. The format is shown in <xref
target="fig2"></xref>.</t>
<figure align="center" anchor="fig2"
title="Message Format for the NSEI report">
<artwork>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="SSRC (32 bits):"><vspace blankLines="1" />The SSRC
value of the media sender that is requested to send the lost
packet.<vspace blankLines="1" /></t>
<t hangText="Packet ID (PID): 16 bits"><vspace blankLines="1" />
The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet.<vspace
blankLines="1" /></t>
<t
hangText="bitmask of following lost packets (BLP): 16 bits"><vspace
blankLines="1" /> The BLP allows for reporting losses of any of
the 16 RTP packets immediately following the RTP packet
indicated by the PID. The BLP's definition is identical to that
given in <xref target="RFC4585"></xref>.<vspace
blankLines="1" /></t>
</list></t>
</section>
</section>
<section title="Payload Specific Feedback Message">
<section title="FIR implosion Suppression Summary report">
<t>The FIR implosion Suppression message is an extension to the RTCP
receiver feedback report and identified by RTCP packet type value
PT=PSFB and FMT=TBD.</t>
<t>The FCI field MUST contain one or more FIR suppression Early
Indication (FSEI) entries. Each entry applies to a different media
sender, identified by its SSRC.</t>
<t>The Feedback Control Information (FCI) for FSEI uses the similar
format of message Types defined in the section 4.3.1.1 of <xref
target="RFC5104"></xref>. The format is shown in <xref
target="fig3"></xref>.</t>
<figure align="center" anchor="fig3"
title="Message Format for the FSEI report">
<artwork>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="SSRC (32 bits): "><vspace blankLines="1" />The SSRC
value of the media sender that is requested to send a decoder
refresh point.<vspace blankLines="1" /></t>
<t hangText="Seq nr:8bits">Command sequence number. The sequence
number space is unique for each pairing of the SSRC of command
source and the SSRC of the command target. The sequence number
SHALL be increased by 1 modulo 256 for each new command.<vspace
blankLines="1" /></t>
<t hangText="Reserved: 24 bits"><vspace blankLines="1" />All
bits SHALL be set to 0 by the sender and SHALL be ignored on
reception.<vspace blankLines="1" /></t>
</list></t>
</section>
</section>
</section>
<section title="SDP Signaling">
<t>A new feedback value “fss” needs to be defined for the Feedback Storm
Suppression message to be used with Session Description Protocol
(SDP)<xref target="RFC4566"></xref> using the Augmented Backus-Naur Form
(ABNF)<xref target="RFC4585"></xref>.</t>
<t>The "fss" feedback value SHOULD be used with parameters that indicate
the feedback suppression supported. In this document, we define two such
parameters, namely:<vspace blankLines="1" /><list style="symbols">
<t>"fsei" denotes support of fir suppression early indication
(fsei).<vspace blankLines="1" /></t>
<t>“nsei” denotes support of NACK suppression early indication.</t>
</list><vspace blankLines="1" />In the ABNF for rtcp-fb-val defined in
<xref target="RFC4585"></xref>, there is a placeholder called rtcp-fb-id
to define new feedback types. "fss" is defined as a new feedback type in
this document, and the ABNF for the parameters for fss is defined here
(please refer to section 4.2 of <xref target="RFC4585"></xref> for
complete ABNF syntax).</t>
<figure align="center">
<artwork>
rtcp-fb-val =/ "fss" rtcp-fb-fss-param
rtcp-fb-fss-param = SP "nsei";nack suppression early indication
/ SP “fsei”;fir suppression early indication
/ SP token [SP byte-string]
; for future commands/indications
byte-string = <as defined in section 4.2 of [RFC4585] >
</artwork>
</figure>
<t>Refer to Section 4.2 of <xref target="RFC4585"></xref> for a detailed
description and the full syntax of the "rtcp-fb" attribute.</t>
</section>
<section title="Example Use Cases">
<t>The operation of feedback suppression is similar for all types of RTP
sessions and topologies <xref target="RFC5117"></xref>, however the
exact messages used and the scenarios in which suppression is employed
differ for various use cases. The following sections outline the
intended use cases for feedback suppression and give an overview of the
particular mechanisms.</t>
<section title="Source Specific Multicast (SSM) use case">
<t>In SSM RTP sessions as described in <xref target="RFC5760"></xref>,
one or more Media Senders send RTP packets to a Distribution Source.
The Distribution Source relays the RTP packets to the receivers using
a source-specific multicast group.</t>
<t>As outlined in the <xref target="RFC5760"></xref>, there are two
Unicast Feedback models that may be used for reporting, - the Simple
Feedback model and the Distribution Source Feedback Summary Model. The
RTCP Feedback Suppression report extension specified in the section 4
of this document will work in both Feedback models. Details of
operation in each are specified below.</t>
<section title="Simple Feedback Model">
<t>In the simple Feedback Model, the Loss reporter(s) are disjoint
from the distribution source. In this case, an upstream client or
immediate reporting receiver may be chosen as the loss reporter.
Also in this model, the distribution source includes support for
retransmission as part of the offered SDP and expects such support
from the Media Sender.</t>
<t>As one dedicated receiver for packet loss reporting, the Loss
reporter MUST listen on the corresponding RTP session for data. When
the Loss reporter observes that a sequence of RTP packets from a
Media Sender contains gaps (by checking the sequence number of
packets), the Loss reporter MUST use the same packet types as
traditional RTCP feedback described in<xref
target="RFC3550"></xref>and create one new RTCP Feedback Report with
information on the RTP sequence number of the lost packets and
suppression early indication event. When a receiver is eligible to
transmit, it MUST send this Report packet to the distribution source
via unicast feedback.</t>
<t>The Distribution Source (unicast Feedback Target) MUST listen for
unicast RTCP data sent to the RTCP port. Upon receiving the unicast
RTCP Feedback Report packet from the loss reporter, the Distribution
Source MUST forward it to the group on the multicast RTCP session.
Every RTCP packet from each Loss reporter MUST be reflected
individually. If the loss reporter is part of group, the
Distribution source MUST filter this packet out and not forward it
back to this loss reporter.</t>
<t>If there are multiple loss reporters looking at the same RTP
stream, then the loss may be identified by more than one and those
detecting the loss will all send requests for the same packet loss.
In this case, the distribution source MUST filter the duplicated
packet loss request out and only forward one copy of the RTCP
Feedback report packet from the first loss reporter to the group
impacted by packet loss.</t>
<t>This unicast RTCP Feedback Report lets the receivers know that
feedback for this packet loss is not needed and should not be sent
to the media sender(s). If the Media Sender(s) are part of the SSM
group for RTCP packet reflection, the Distribution Source MUST
filter this packet out. If the Media Sender(s) are not part of the
SSM group for RTCP packets, the Distribution Source MUST not forward
this RTCP packets received from the receivers to the Media
Sender(s).</t>
<t>When the receiver receives the RTCP packet, if the receiver
understands the message it will not send feedback (e.g., NACK) for
the missing packets reported in the message and will accept a
retransmission packet (if forthcoming) transmitted from the
Distribution Source. If it did not understand the Feedback
Suppression report the receiver may of course still send feedback
messages to the specified media sender. When the distribution source
receives a feedback message reporting loss from one or more
receivers after it has already detected packet loss or gotten a NACK
feedback message from loss reporter, the distribution source MUST
filter them out until the Retransmission stream is ready in the
Distribution Source.</t>
</section>
<section title="Distribution Source Feedback Summary Model">
<t>In the distribution source feedback summary model, the
distribution source will include the support for retransmission as
part of the offered SDP and will expect such support from the Media
Sender, also the Loss reporter instance may be integrated in the
distribution source or may be separated from the distribution
source. In some cases, several loss reporter instances for the same
session can exist at the same time, e.g., one loss reporter instance
(loss reporter A) is implemented in the upstream client A, one loss
reporter instance (loss reporter B) is implemented in the upstream
client B, another loss reporter instance for the same session (loss
reporter C) is part of feedback target within the distribution
source. In this section, we focus on this generic case to discuss
the distribution Source Feedback Summary Model.</t>
<t>The Loss reporter A and the Loss reporter B MUST listen on the
RTP channel for data. When the Loss reporter observes RTP packets
from a Media Sender are not consecutive by checking the sequence
number of packets, the loss reporter generates NACK message
described in<xref target="RFC4585"></xref> or generates the new RTCP
Feedback Report packet described in the section 6, and then send
either of them to the distribution source via unicast feedback.</t>
<t>The Distribution Source (unicast Feedback Target) MUST listen for
unicast RTCP data sent to the RTCP port. Upon receiving the unicast
RTCP Feedback Report packet from the loss reporter, the distribution
source needs to filter them out, i.e., identify these unicast RTCP
packets coming from the Dedicated receivers (i.e.,Loss Reporter A
and Loss Reporter B)based on the IP address of loss reporters or
dedicated RTCP port for loss report, then summarize the information
received from all the RTCP Feedback Reports generated by the
Dedicated receivers together with the information generated by the
loss reporter integrated in the feedback target and then create the
summary report to include all these information. In order to reduce
the processing load at the distribution source, the individual
instance of Loss Reporter may provide preliminary summarization
report.</t>
<t>During the summary report creating, the Distribution Source MUST
use its own SSRC value for transmitting summarization information
and MUST perform proper SSRC collision detection and resolution.</t>
<t>In some case, the distribution source may receive RTCP NACK
messages from the receivers behind the Distribution Source before
the distribution source detects the packet loss which may cause
potential Feedback implosion. In such case, the distribution source
may filter them out if it already sent a packet loss request for the
missing packet to the media sender. When the distribution source
confirms packet loss reported by the receiver, the distribution
source generates the summary report to include the packet loss
information from the corresponding receiver (e.g., upstream client
or loss reporter).</t>
<t>The distribution source may send this new RTCP summary report
described in the section 6 to the group on the multicast RTCP
channel and in the meanwhile sending a packet loss request to the
media sender.</t>
<t>If the loss reporter is part of group, the Distribution source
MUST not send the summary report back to this loss reporter.</t>
<t>If there are a couple of loss reporters looking at the same RTP
stream, then the loss may be identified by all and they will all
send requests for the same packet loss. In this case, the
distribution source MUST filter out the duplicated information from
various loss reporters and only append one copy of such information
to the summary report.</t>
<t>When the host receives the RTCP packet, if the host understands
this message it will not send packet loss request (e.g., NACK) for
the missing packets reported in the message and will accept a
retransmission stream transmitted from the Distribution Source. If
it did not understand this new message, the host may send packet
loss request(e.g., NACK messages) to the specified media sender.
When the distribution source receives the packet loss request from
the hosts after it has already detected packet loss or got packet
loss report from loss reporter, the distribution source MUST filter
it out until the Retransmission stream is ready in the Distribution
Source.</t>
</section>
</section>
<section title="RTP transport translator use case">
<t>A Transport Translator (Topo-Trn-Translator), as defined in <xref
target="RFC5117"></xref> is typically forwarding the RTP and RTCP
traffic between RTP clients, for example converting between multicast
and unicast for domains that do not support multicast. The translator
can identify packet loss from the upstream and send the Feedback
Suppression message to the unicast receivers. The translator can also
serve as a loss reporter on the multicast side as described in the SSM
case.</t>
</section>
<section title="Multipoint Control Unit (MCU) use case">
<t>In point to multipoint topologies using video switching MCU
(Topo-Video-switch-MCU) <xref target="RFC5117"></xref>, the MCU
typically forwards a single media stream to each participant, selected
from the available input streams. The selection of the input stream is
often based on voice activity in the audio-visual conference, but
other conference management mechanisms (like presentation mode or
explicit floor control) exist as well.</t>
<t>In this case the MCU may detect packet loss from the sender or may
decide to switch to a new source. In both cases the receiver may lose
synchronization with the video stream and may send a FIR request. If
the MCU itself can detect the mis-synchronization of the video, the
MCU can send the FIR suppression message to the receivers and send a
FIR request to the video source.</t>
</section>
</section>
<section title="Security Considerations">
<t>The defined messages have certain properties that have security
implications. These must be addressed and taken into account by users of
this protocol.</t>
<t>Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications:</t>
<t>Sending NACK Implosion Summary Suppression Indication with wrong
sequence number of lost packet that makes missing RTP packets can not be
compensated by retransmission mechanism.</t>
<t>Sending FIR Implosion Summary Suppression Indication with wrong
sequence number of lost packet that makes missing RTP packets can not be
compensated by update request mechanism.</t>
<t>To prevent these attacks, there is a need to apply authentication and
integrity protection of the feedback messages. This can be accomplished
against threats external to the current RTP session using the RTP
profile that combines Secure RTP <xref target="RFC3711"></xref> and AVPF
into SAVPF <xref target="RFC5124"></xref>.</t>
</section>
<section title="IANA Consideration">
<t>New feedback type and New parameters for RTCP FSS receiver feedback
report are subject to IANA registration. For general guidelines on IANA
considerations for RTCP feedback, refer to <xref
target="RFC4585"></xref>.</t>
<t>This document assigns one new feedback type value x in the RTCP
receiver feedback report registry to “Feedback Storm Suppression” with
the following registrations format:</t>
<figure align="center">
<artwork>
Name: FSS
Long Name: Feedback Storm Suppression
Value: TBD
Reference: This document.
</artwork>
</figure>
<t>This document also assigns the parameter value y in the RTCP FSS
receiver feedback report Registry to "NACK Suppression Early Indication
", with the following registrations format:</t>
<figure>
<artwork align="center">
Name: NSEI
Long name: NACK Suppression Early Indication
Value: TBD
Reference: this document.
</artwork>
</figure>
<t>This document also assigns the parameter value z in the RTCP FSS
receiver feedback report Registry to "FIR Suppression Early Indication
", with the following registrations format:</t>
<figure align="center">
<artwork>
Name: FSEI
Long name: FIR Suppression Early Indication
Value: TBD
Reference: this document.
</artwork>
</figure>
<t>The contact information for the registrations is: <figure>
<artwork>
Qin Wu
sunseawq@huawei.com
Site B, Floor 12F,Huihong Mansion, No.91,Baixia Rd.
Nanjing, JiangSu 210001 China
</artwork>
</figure></t>
</section>
<section title="Acknowledgement">
<t>The authors would like to thank David R Oran, Bill Ver Steeg, Ingemar
Johansson S, Colin Perkins, Tom VAN CAENEGEM, WeeSan Lee for their
valuable comments and suggestions on this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5760"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4585"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.5117"?>
<?rfc include="reference.RFC.4588"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5234"?>
<?rfc include="reference.RFC.5104"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.5124"?>
</references>
<references title="Informative References">
<reference anchor="DVB-IPTV">
<front>
<title>Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based
DVB Services over IP Based Networks</title>
<author>
<organization>ETSI Standard</organization>
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="ETSI TS 102 034, V1.4.1" value="" />
</reference>
<reference anchor="I-D.hunt-avt-monarch-01">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization>BT</organization>
</author>
<author fullname="Philip Arden" initials="P." surname="Arden">
<organization>BT</organization>
</author>
<date month="August" year="2008" />
</front>
</reference>
<reference anchor="I-D.ietf-pmol-metrics-framework-02">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark " initials="A." surname="Clark">
<organization>Telchemy Incorporated</organization>
</author>
<date />
</front>
</reference>
</references>
<section anchor="P-1"
title="Example scenarios for Retransmission Storm Suppression">
<t>Feedback Storm Suppression can be further extended when a distributed
content distribution network (CDN) are considered. In these cases,
several intermediate node and media senders may constitute hierarchical
model. In the distributed content distribution environment, the Feedback
Storm Suppression is used to suppress the neighboring node from sending
packet loss request for the missing packets via unicast. How the
neighboring node is discovered is beyond scope of this document.</t>
<section anchor="S-1"
title="Scenario 1: One or more media sender,One distribution source">
<t>The general architecture for scenario 1 is displayed below in <xref
target="F-A-1"></xref>. In this architecture, one or more Media
Senders send RTP packets to the RTP Receivers through the same
Distribution Source. The Distribution Source relays the RTP packets to
the receivers using a source-specific multicast channel. In the
reverse direction, the receivers transmit RTCP packets via unicast to
the distribution source. The Distribution Source in turn relays RTCP
packets to the media sender and then transmits the RTCP packets back
to the receivers, using source-specific multicast. When packet loss
happens in the upstream link or downstream aggregate link of
distribution source, it may result in massive retransmission request
for the same RTP packets from all the receivers using RTCP NACK to the
same multicast sender. We refer to it as Retransmission Storm.<figure
anchor="F-A-1" title="One media Sender, one Distribution Source">
<artwork>
+-------+
|---->|RTP_Rx1|
+--------+ | +-------+
| | +--------------+ |
| | | | | +-------+
| Media |-------| Distribution |-------|---->|RTP_Rx2|
| | | Source | | +-------+
| Sender | | | | .
| | +--------------+ | .
| | | .
+--------+ | +-------+
|---->|RTP_Rxn|
+-------+
</artwork>
</figure></t>
</section>
<section anchor="S-2"
title="Scenario 2:One media sender, Two distribution sources in cascade">
<figure anchor="F-A-2"
title="One media sender, Two distribution sources in cascade">
<artwork>
+-------+
|---->|RTP_Rx1|
| +-------+
+------+ |
| | +------------+ +------------+ | +-------+
|Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2|
|Sender| | Source1 | | Source2 | | +-------+
| | +------------+ +------------+ | .
+------+ | .
| .
| +-------+
|---->|RTP_Rxn|
+-------+
</artwork>
</figure>
<t>The general architecture for scenario 2 is displayed below in <xref
target="F-A-2"></xref>. In this architecture, One media sender passes
through two distribution source in cascading and sends RTP packets to
all the RTP receivers. When packet loss happens in the upstream link
or downstream aggregate link of distribution source1, it may result in
massive retransmission request for the same RTP packets from all the
receivers using RTCP NACK to the same multicast sender. We refer to it
as Retransmission Storm. In this case, the distribution source 2 can
be taken as one special RTP receiver located in the downstream
direction of distribution source 1.</t>
</section>
<section anchor="S-3"
title="Scenario 3:One media sender, Two distribution sources in parallel">
<t>The general architecture for scenario 3 is displayed below in <xref
target="F-A-3"></xref>. In this architecture, one media sender and two
Distribution source constitute one hierarchical tree model. In this
model, one Media Senders send RTP packets to all the RTP receivers
through two different path respectively. When packet loss happens in
the upstream link or downstream aggregate link of distribution source,
it may result in massive retransmission request for the same RTP
packets from all the receivers using RTCP NACK to the same multicast
sender. We refer to it as Retransmission Storm.<figure anchor="F-A-3"
title="One Media Sender, more distribution sources">
<artwork>
+--------+
|---->|RTP_Rx11|
| +--------+
+--------------+ |
| | | +--------+
|--->| Distribution |----|---->|RTP_Rx12|
| | Source1 | | +--------+
| | | | .
+--------+ | +--------------+ | .
| | | | .
| | | | +--------+
| Media | | |---->|RTP_Rx1k|
| |---| +--------+
| Sender | | +--------+
| | | |---->|RTP_Rx21|
| | | | +--------+
+--------+ | +--------------+ |
| | | | +--------+
| | Distribution |----|---->|RTP_Rx22|
|--->| Source2 | | +--------+
| | | .
+--------------+ | .
| .
| +--------+
|---->|RTP_Rx2j|
+--------+
</artwork>
</figure></t>
</section>
</section>
<section anchor="P-2" title="Applicability of Feedback Storm Suppression">
<t>This document defines new RTCP Receiver feedback Report, which we
refer to as Feedback Storm Suppression to deal with Retransmission Storm
mentioned above. Here we give two examples to show how this new RTCP
receiver feedback report is applied into three scenarios described in
<xref target="P-1"></xref> for Retransmission Storm Suppression.</t>
<t>Applicability of Retransmission Storm Suppression in Scenario 1
described in <xref target="F-A-1"></xref> is shown in the <xref
target="F-A-4"></xref>. In this figure, the distribution source detect
the packet loss before the receiver perceive it and ask for
retransmission of the missing packets from the media sender, in the
meanwhile, the distribution source transmits the RTCP Retransmission
Storm Suppression Indication back to the receivers using source-specific
multicast channel. In this way, the delay for the receiver to recover
from the packet loss can be reduced and the risk of increasing network
congestion can be mitigated.<figure anchor="F-A-4"
title="Applicability of Feedback Suppression Early Indication">
<artwork>
+------+ +--------------+ +--------+
|Media | | Distribution | | |
|Sender| | Source | | RTP_Rx |
+--+---+ +------+-------+ +---+----+
| | |
| | |
|------------------->|------RTP Multicast---->|
| | |
| | |
| +--------+----------+ |
| |Detect Packet Loss | |
| |and Identify the SN| |
| |of missing Packets | |
| +--------+----------+ |
|<-----RTCP NACK-----| |
| | |
| +--Multicast RTCP FSS--->|
| RTP Retransmission | |
|------------------->| |
| |------RTP Multicast---->|
| | Retransmission |
| | |
| | |
| | |
</artwork>
</figure>Applicability of Feedback Storm Suppression in Scenario 2 or
3 described in <xref target="F-A-2"></xref> and <xref
target="F-A-3"></xref> is shown in the <xref target="F-A-5"></xref>. The
procedure in the <xref target="F-A-5"></xref> is similar to the one in
the figure <xref target="F-A-4"></xref>. The only difference is
distribution source should not only notify all the receiver behind
itself not to send NACK but also propagate the retransmission
suppression indication to the neighboring distribution sources. In this
way, all the receivers behind all the neighboring distribution source
can avoid sending massive retransmission request to the media
sender.<figure anchor="F-A-5"
title="Applicability of Retransmission Suppression Early Indication">
<artwork>
+------+ +-------+ +--------+ +-------+ +--------+
|Media | | | | RTP_Rx | | | | RTP_Rx |
|Sender| | DS1 | | (DS1) | | DS2 | | (DS2) |
+--+---+ +---+---+ +---+----+ +---+---+ +---+----+
| | | | |
| |RTP Multicast | | |
|----------->|------------->| | |
| | | | |
| | | |RTP Multicast|
|------------------------------------------->|------------>|
| | | | |
| +--------+------------+ | | |
| |Detect Packet Loss | | | |
| |and Identify the SN | | | |
| |of the missing Packets | | |
| +--------+------------+ | | |
| | | | |
|<-RTCP NACK-| Multicast RTCP RSSI | |
| |------------->| | |
| | | | |
| |-----Unicast RTCP RSSI-------->|Multicast RTCP FSS
| | | |------------>|
|RTP Retransmission | | |
|----------->| | | |
| | | | |
| | RTP Retransmission | |
|------------+--------------+--------------->| |
| | | | |
| | RTP Multicast| | RTP Multicast
| |Retransmission| |Retransmission
| |------------->| |------------>|
| | | | |
DS1: Distribution Source 1
DS2: Distribution Source 2</artwork>
</figure></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:18:53 |