One document matched: draft-wu-avt-retransmission-supression-rtp-04.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-04"
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>When packet loss close to the media source or intermediary of the
session is detected as a loss by a large number of receivers, large
number of feedback requests used to ask for the lost RTP packets are all
addressed to the same media source, or a designated feedback target.
This may result in a phenomenon known variously as a "feedback storm "
or "feedback implosion ". </t>
<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 packet loss was detected and sending a
feedback message concerning a specified set of RTP packets may be
unnecessary, or even harmful. 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. The proposed extension is useful for
single-source multicast sessions. In addition, it can be applied to any
other types of RTP sessions and topologies that might benefit from
feedback suppression mechanism.</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
media source (or a delegated feedback target). There are cases where
multiple receivers may initiate the same, or an equivalent message
towards the same media source. When the receiver count is large, this
behavior may overload the media source 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="RFC4585"></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 media or
distribution source to retransmit the missing RTP packets using the RTP
retransmission payload format<xref target="RFC4588"></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 Feedback implosion <xref target="RFC5740"></xref> towards the media or
distribution source, i.e., large number of feedback 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 "feedback
storm" or the “NACK storm” terminology of <xref
target="DVB-IPTV"></xref>. In an attempt to increase its robustness
against the loss of a feedback message or of retransmission packets, a
receiver may send multiple feedbacks for the same detected packet loss,
which may aggravate the feedback 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 source.</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 may cause
short term overload and, and in extreme cases to pose a possible risk of
increasing network congestion on the control channel (e.g. RTCP
feedback), the data channel (i.e. RTP retransmission), or Both if the
receivers are not correctly implemented </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 server to the client (or receiver). However NACK is
defined as a receiver report sent from a client to the server and
therefore exhibits a semantic mismatch when used as a suppression
indication from the server (or intermediary) to the client. 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>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.
</t>
<t>Also the intermediate node may initiate its own feedback toward the
media source to provoke a retransmission. When the media source receives
the request from the intermediate node, the media source resends the
lost 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>
</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="Loss Detector:"><vspace blankLines="1" /> The Loss
Detector is one logical function which is used to detect the packet
loss at the RTP layer and report it to the distribution 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 distribution source A, on ports n for the RTP channel and k for
the RTCP channel, the Loss Detector are identified by an IP address
of distribution source A on port k. The Loss Detector MAY also be
implemented in one or more entities different from the distribution
source. </t>
</list></t>
</section>
<section title="Protocol Overview">
<t> This document extend the RTCP feedback messages defined in the
Audio-Visual Profile with Feedback (AVPF) and define the Feedback
Suppression message. 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 source 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 send Feedback
Suppression message towards the receivers as defined in this
specification.</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 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. </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 downstream 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 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="RTCP Feedback Report Extension">
<section title="Transport Layer Feedback: NACK Suppression 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
source, 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 source 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 title="Payload Specific Feedback: FIR suppression 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
source, 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 source 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 media source and SHALL be ignored on
reception.<vspace blankLines="1" /></t>
</list></t>
</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 Sources 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>In order to avoid the forms of NACK implosion described in section
1, the Loss Detector is introduced. The Loss Detector detects and
reports packet loss, on both the upstream link and the downstream
aggregate link. How the loss detector SHOULD detect the packet loss is
beyond of scope of this document. When upstream link or downstream
aggregate link packet loss occurs, the Loss Detector MAY inform
distribution source of the detected packet loss using Feedback
Suppression messages. In response, the distribution source either
forwards packet loss suppression report received from Loss Detector 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 distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media
source. The distribution source then can (optionally) ask for the lost
packets from the media source on behalf of all the RTP receivers. </t>
<t>When the Loss Detector(s) are part of a feedback target collocated
with the distribution source, redistribution of the feedback
suppression report is trivial. In such cases, the Loss Detector
function in the feedback target detects packet loss coming from an
upstream link and informs the collocated distribution source. Also the
Loss Detector may detect packet loss occurring within distribution
source itself and report to distribution source using the same method.
When the Loss Detector(s) are physically and(or) topologically
distinct from distribution source, each Loss Detector MUST create a
packet loss report using the similar format as conventional RTCP NACK
packets at the RTP layer and send it to the distribution source . </t>
<t>The distribution 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 distribution 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
|Source 1|<------->| | +----------------> R(1)
+--------+ |Distribution| |
| SOURCE | +--+
+--------+ | | | |
|Media |<------->| | | +-----------> R(2)
|Source 2| | Feedback |->+ +---- :
+--------+ |+ Target --+| | +------> R(n-1)
: || +---+ || | |
: || | D| || +--+--> R(n)
|| | E| ||
+--------+ || |L T| ||
|Media | || |O E| ||
|Source M|<---- -->|| |S C| ||
+--------+ || |S T| ||
|| | O| ||
|| | R| ||
|| +---+ ||
|+----------+|
+------------+
Transport of packet loss informationfrom the Loss Detector to the
Feedback Target is via unicast RTCP feedback if the two are not
co-located.
</artwork>
</figure>In this figure, we assume the distribution source is
separated from a particular media source and the Loss Detector is part
of feedback target collocated with Distribution source. The
communication between the media source and the distribution 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 Detectors know the addresses of their respectively
responsible Feedback Targets.</t>
</list></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 instance(s)are
distributed into two different distribution sources. e.g., upstream
distribution source may act as the loss detector of downstream of
distribution source. </t>
<t> The Loss Detector MUST listen on the corresponding RTP session
for data. When the Loss Detector observes that a sequence of RTP
packets from a media source contains gaps (by checking the sequence
number of packets), the Loss Detector 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 the Loss Detector is
eligible to transmit, it MUST send this Report packet to the
distribution source via feedback. </t>
<t> The Distribution Source (unicast Feedback Target) MUST listen
for RTCP data sent to the RTCP port. Upon receiving the RTCP
Feedback Report packet from the Loss Detector, the Distribution
Source MUST forward it to the group on the multicast RTCP session.
Every RTCP packet from each Loss Detector MUST be reflected
individually. </t>
<t>If there are multiple Loss Detectors 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 Detector to the group
impacted by packet loss.</t>
<t>This RTCP Feedback Report lets the receivers know that feedback
for this packet loss is not needed and SHOULD NOT be sent to the
media source(s). If the media source(s) are part of the SSM group
for RTCP packet reflection, the Distribution Source MUST filter this
packet out. If the media source(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 source(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 source. 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 Detector, the distribution source MUST
filter them out until proactive recovery is complete.</t>
</section>
<section title="Distribution Source Feedback Summary Model">
<t> In the distribution source feedback summary model, the Loss
Detector instances may be distributed into different distribution
sources. In some cases, several Loss Detector instances for the same
session can exist at the same time, e.g., one Loss Detector instance
(Loss Detector A) is implemented in the upstream distribution source
A, one Loss Detector instance (Loss Detector B) is implemented in
the upstream distribution source B, another Loss Detector instance
for the same session (Loss Detector C) is part of feedback target
within the distribution source C. In this section, we focus on this
generic case to discuss the distribution Source Feedback Summary
Model. </t>
<t>The Loss Detector A and the Loss Detector B MUST listen on the
RTP channel for data. When the Loss Detector observes RTP packets
from a media source are not consecutive by checking the sequence
number of packets, the Loss Detector 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 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 Detector, the distribution
source needs to filter them out, i.e., identify these unicast RTCP
packets coming from the Dedicated receivers (i.e.,Loss Detector A
and Loss Detector B)based on the IP address of Loss Detectors 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 Detector 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 Detector 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 source. 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 Loss
Detector).</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 source.</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 Detectors 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. If it did not
understand this new message, the host MAY send packet loss
request(e.g., NACK messages) to the specified media source. When the
distribution source receives the packet loss request from the hosts
after it has already detected packet loss, the distribution source
MUST filter it out until proactive recovery is complete.</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 Suppression Report with wrong sequence number of lost
packet that makes missing RTP packets can not be compensated.</t>
<t>Sending FIR Suppression Report 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>
<t>Note that middleboxes that are not visible at the RTP layer that wish
to send NACK/FIR suppression reports on behalf of the media source can
only do so if they spoof the SSRC of the media source. This is difficult
in case SRTP is in use. If the middlebox is visible at the RTP layer,
this is not an issue, provided the middlebox is part of the security
context for the session.</t>
<t>Also note that endpoints that receive a NACK/FIR suppression request
would be well-advised to ignore it, unless it is authenticated via SRTCP
or similar. Accepting un-authenticated NACK/ FIR suppression requests
can lead to a denial of service attack, where the endpoint accepts poor
quality media that could be repaired. </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
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
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
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
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012, China
</artwork>
</figure></t>
</section>
<section title="Acknowledgement">
<t>The authors would like to thank David R Oran, Ali C. Begen, Colin
Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, 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="RFC5740">
<front>
<title>NACK-Oriented Reliable Multicast (NORM) Transport
Protocol</title>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
</author>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen TZI</organization>
</author>
<author fullname="Mark Handley " initials="M." surname="Handley">
<organization>University College London</organization>
</author>
<author fullname="Joe Macker" initials="J." surname="Macker">
<organization>Naval Research Laboratory</organization>
</author>
<date month="November" year="2009" />
</front>
</reference>
<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 NACK Implosion">
<t>In SSM RTP sessions as described in <xref target="RFC5760"></xref>,
there may have more than one distribution source between the media
source and the receivers. In order for loss repair, the distribution
source may choose to include the support for retransmission as part of
the offered SDP and will expect such support from the media source.The
following section outline several example scenarios for NACK Implosion.
</t>
<section anchor="S-1"
title="Scenario 1: One or more media source, One distribution source">
<t>The scenario 1 is displayed below in <xref target="F-A-1"></xref>.
In this scenario, one or more Media Sources 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 souce and then
transmits the RTCP packets back to the receivers, using
source-specific multicast. <figure anchor="F-A-1"
title="One media Source, one Distribution Source">
<artwork>
+-------+
|---->|RTP_Rx1|
+--------+ | +-------+
| | +--------------+ |
| | | | | +-------+
| Media |-------| Distribution |-------|---->|RTP_Rx2|
| | | Source | | +-------+
| Source | | | | .
| | +--------------+ | .
| | | .
+--------+ | +-------+
|---->|RTP_Rxn|
+-------+
</artwork>
</figure></t>
</section>
<section anchor="S-2"
title="Scenario 2:One media source, Two distribution sources in cascade">
<figure anchor="F-A-2"
title="One media source, Two distribution sources in cascade">
<artwork>
+-------+
|---->|RTP_Rx1|
| +-------+
+------+ |
| | +------------+ +------------+ | +-------+
|Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2|
|Source| | Source1 | | Source2 | | +-------+
| | +------------+ +------------+ | .
+------+ | .
| .
| +-------+
|---->|RTP_Rxn|
+-------+
</artwork>
</figure>
<t>The scenario 2 is displayed below in <xref target="F-A-2"></xref>.
In this scenario, One media source passes through two distribution
source in cascading and sends RTP packets to all the RTP receivers. In
this case, the distribution source 2 is located in the downstream
direction of distribution source 1. </t>
</section>
<section anchor="S-3"
title="Scenario 3:One media source, Two distribution sources in parallel">
<t>The scenario 3 is displayed below in <xref target="F-A-3"></xref>.
In this scenario, the Media Sources send RTP packets to all the RTP
receivers through two different path respectively. In each path, there
is a distribution source. The distribution source1 is a neighboring
node of distribution source 2.<figure anchor="F-A-3"
title="One Media Source, more distribution sources">
<artwork>
+--------+
|---->|RTP_Rx11|
| +--------+
+--------------+ |
| | | +--------+
|--->| Distribution |----|---->|RTP_Rx12|
| | Source1 | | +--------+
| | | | .
+--------+ | +--------------+ | .
| | | | .
| | | | +--------+
| Media | | |---->|RTP_Rx1k|
| |---| +--------+
| Source | | +--------+
| | | |---->|RTP_Rx21|
| | | | +--------+
+--------+ | +--------------+ |
| | | | +--------+
| | Distribution |----|---->|RTP_Rx22|
|--->| Source2 | | +--------+
| | | .
+--------------+ | .
| .
| +--------+
|---->|RTP_Rx2j|
+--------+
</artwork>
</figure></t>
</section>
</section>
<section anchor="P-2" title="Applicability of Feedback Suppression">
<t> This document defines new RTCP feedback Report, which we refer to as
Feedback Suppression to deal with NACK Implosion mentioned above. Here
we give two examples to show how this new RTCP feedback report is
applied into three scenarios described in <xref
target="P-1"></xref>.</t>
<t>Applicability of Feedback 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 lost packets from the media source on behalf of
all the RTP receivers. , in the meanwhile, the distribution source
transmits the RTCP Feedback Suppression Indication back to the receivers
using source-specific multicast channel. Upon receiving the lost packet
via the RTP retransmission payload format, the distribution source
forwards the retransmitted packet to all the receivers. The receiver
will accept a retransmission stream transmitted from the Distrbituion
Source. </t>
<t>When the distribution source receives a feedback message reporting
loss from one or more receivers after it has already detected packet
loss, the distribution source MUST filter them out until the
Retransmission stream is ready in the Distrbitution Source. 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.
</t>
<figure anchor="F-A-4"
title="Applicability of NACK Suppression Early Indication">
<artwork>
+------+ +--------------+ +--------+
|Media | | Distribution | | |
|Source| | 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>
<t>Applicability of Feedback 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 source.<figure anchor="F-A-5"
title="Applicability of NACK Suppression Early Indication">
<artwork>
+------+ +--------+ +--------+
|Media | +-----+ | RTP_Rx | +-----+ | RTP_Rx |
|Source| | DS1 | | served | | DS2 | | served |
+--+---+ +-----+ | by DS1 | +-----+ | by DS2 |
| | ----+----+ | ----+----+
| |RTP Multicast | | |
|----------->|------------->| | |
| | | | |
| | | |RTP Multicast|
|------------------------------------------->|------------>|
| | | | |
| +--------+------------+ | | |
| |Detect Packet Loss | | | |
| |and Identify the SN | | | |
| |of the missing Packets | | |
| +--------+------------+ | | |
| | | | |
|<-RTCP NACK-| Multicast RTCP FSS | |
| |------------->| | |
| | | | |
| |-----Unicast RTCP FSS -------->|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:17:31 |