Network Working Group Q. Wu
Internet-Draft F. Xia
Intended status: Standards Track R. Even
Expires: April 16, 2011 Huawei
October 13, 2010
RTCP Report Extension for Feedback Suppression
draft-wu-avt-retransmission-supression-rtp-04
Abstract
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 ".
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.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2011.
Wu, et al. Expires April 16, 2011 [Page 1]
Internet-Draft Feedback Suppression October 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Wu, et al. Expires April 16, 2011 [Page 2]
Internet-Draft Feedback Suppression October 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6
4. RTCP Feedback Report Extension . . . . . . . . . . . . . . . . 7
4.1. Transport Layer Feedback: NACK Suppression Report . . . . 7
4.2. Payload Specific Feedback: FIR suppression report . . . . 8
5. SDP Signaling . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Example Use Cases . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Source Specific Multicast (SSM) use case . . . . . . . . . 10
6.1.1. Simple Feedback Model . . . . . . . . . . . . . . . . 12
6.1.2. Distribution Source Feedback Summary Model . . . . . . 13
6.2. RTP transport translator use case . . . . . . . . . . . . 14
6.3. Multipoint Control Unit (MCU) use case . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Example scenarios for NACK Implosion . . . . . . . . 18
A.1. Scenario 1: One or more media source, One distribution
source . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.2. Scenario 2:One media source, Two distribution sources
in cascade . . . . . . . . . . . . . . . . . . . . . . . . 19
A.3. Scenario 3:One media source, Two distribution sources
in parallel . . . . . . . . . . . . . . . . . . . . . . . 19
Appendix B. Applicability of Feedback Suppression . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Wu, et al. Expires April 16, 2011 [Page 3]
Internet-Draft Feedback Suppression October 2010
1. Introduction
RTCP feedback messages [RFC4585]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.[RFC4585]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[RFC4588].
However, in topologies utilizing transport translators (Topo-Trn-
Translator) or large-scale multicast transmission (Topo-Multicast) as
defined in [RFC5117], 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
[RFC5740] 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 [DVB-IPTV]. 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.
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 [RFC5117]. 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.
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),
Wu, et al. Expires April 16, 2011 [Page 4]
Internet-Draft Feedback Suppression October 2010
or Both if the receivers are not correctly implemented
In order to mitigate these behaviors, the current text in [RFC5760]
allows the distribution source to filter out the NACK messages and
[DVB-IPTV] 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.
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.
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 [RFC4588] or resends a new refresh
point for FIR Initiator [RFC5104], depending on the type of feedback
it received.
2. Terminology
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 [RFC2119].
Loss Detector:
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.
Wu, et al. Expires April 16, 2011 [Page 5]
Internet-Draft Feedback Suppression October 2010
3. Protocol Overview
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).
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.
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[DVB-IPTV]. 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.
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.
Since feedback suppression interacts strongly with repair timing, it
Wu, et al. Expires April 16, 2011 [Page 6]
Internet-Draft Feedback Suppression October 2010
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.
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.
4. RTCP Feedback Report Extension
4.1. Transport Layer Feedback: NACK Suppression Report
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.
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.
The Feedback Control Information (FCI) for NSEI uses the similar
format of message Types defined in the section 4.3.1.1 of [RFC5104].
The format is shown in Figure 1.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Message Format for the NSEI report
Wu, et al. Expires April 16, 2011 [Page 7]
Internet-Draft Feedback Suppression October 2010
SSRC (32 bits):
The SSRC value of the media source that is requested to send the
lost packet.
Packet ID (PID): 16 bits
The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet.
bitmask of following lost packets (BLP): 16 bits
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 [RFC4585].
4.2. Payload Specific Feedback: FIR suppression report
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.
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.
The Feedback Control Information (FCI) for FSEI uses the similar
format of message Types defined in the section 4.3.1.1 of [RFC5104].
The format is shown in Figure 2.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Message Format for the FSEI report
SSRC (32 bits):
The SSRC value of the media source that is requested to send a
decoder refresh point.
Wu, et al. Expires April 16, 2011 [Page 8]
Internet-Draft Feedback Suppression October 2010
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.
Reserved: 24 bits
All bits SHALL be set to 0 by the media source and SHALL be
ignored on reception.
5. SDP Signaling
A new feedback value "fss" needs to be defined for the Feedback Storm
Suppression message to be used with Session Description Protocol
(SDP)[RFC4566] using the Augmented Backus-Naur Form (ABNF)[RFC4585].
The "fss" feedback value SHOULD be used with parameters that indicate
the feedback suppression supported. In this document, we define two
such parameters, namely:
o "fsei" denotes support of fir suppression early indication (fsei).
o "nsei" denotes support of NACK suppression early indication.
In the ABNF for rtcp-fb-val defined in [RFC4585], 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
[RFC4585] for complete ABNF syntax).
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] >
Refer to Section 4.2 of [RFC4585] for a detailed description and the
full syntax of the "rtcp-fb" attribute.
6. Example Use Cases
The operation of feedback suppression is similar for all types of RTP
sessions and topologies [RFC5117], however the exact messages used
and the scenarios in which suppression is employed differ for various
Wu, et al. Expires April 16, 2011 [Page 9]
Internet-Draft Feedback Suppression October 2010
use cases. The following sections outline the intended use cases for
feedback suppression and give an overview of the particular
mechanisms.
6.1. Source Specific Multicast (SSM) use case
In SSM RTP sessions as described in [RFC5760], 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.
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.
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 .
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.
The distribution Source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
Wu, et al. Expires April 16, 2011 [Page 10]
Internet-Draft Feedback Suppression October 2010
feedback. The general architecture is displayed below in Figure 3
+--------+ +------------+ 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.
Figure 3: System Architecture
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 [RFC5760]. Configuration information
also follows [RFC5760], with the following additional considerations:
o The Loss Detectors know the addresses of their respectively
responsible Feedback Targets.
As outlined in the [RFC5760], 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.
Wu, et al. Expires April 16, 2011 [Page 11]
Internet-Draft Feedback Suppression October 2010
6.1.1. Simple Feedback Model
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.
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 [RFC3550] 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.
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.
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.
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).
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
Wu, et al. Expires April 16, 2011 [Page 12]
Internet-Draft Feedback Suppression October 2010
message from Loss Detector, the distribution source MUST filter them
out until proactive recovery is complete.
6.1.2. Distribution Source Feedback Summary Model
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.
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[RFC4585] 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.
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.
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.
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
Wu, et al. Expires April 16, 2011 [Page 13]
Internet-Draft Feedback Suppression October 2010
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).
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.
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.
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.
6.2. RTP transport translator use case
A Transport Translator (Topo-Trn-Translator), as defined in [RFC5117]
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.
6.3. Multipoint Control Unit (MCU) use case
In point to multipoint topologies using video switching MCU (Topo-
Video-switch-MCU) [RFC5117], 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.
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
Wu, et al. Expires April 16, 2011 [Page 14]
Internet-Draft Feedback Suppression October 2010
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.
7. Security Considerations
The defined messages have certain properties that have security
implications. These must be addressed and taken into account by
users of this protocol.
Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications:
Sending NACK Suppression Report with wrong sequence number of lost
packet that makes missing RTP packets can not be compensated.
Sending FIR Suppression Report with wrong sequence number of lost
packet that makes missing RTP packets can not be compensated by
update request mechanism.
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 [RFC3711] and AVPF
into SAVPF [RFC5124].
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.
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.
8. IANA Consideration
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 [RFC4585].
Wu, et al. Expires April 16, 2011 [Page 15]
Internet-Draft Feedback Suppression October 2010
This document assigns one new feedback type value x in the RTCP
feedback report registry to "Feedback Storm Suppression" with the
following registrations format:
Name: FSS
Long Name: Feedback Storm Suppression
Value: TBD
Reference: This document.
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:
Name: NSEI
Long name: NACK Suppression Early Indication
Value: TBD
Reference: this document.
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:
Name: FSEI
Long name: FIR Suppression Early Indication
Value: TBD
Reference: this document.
The contact information for the registrations is:
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012, China
9. Acknowledgement
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.
10. References
10.1. Normative References
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Wu, et al. Expires April 16, 2011 [Page 16]
Internet-Draft Feedback Suppression October 2010
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
10.2. Informative References
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", November 2009.
[DVB-IPTV]
ETSI Standard, "Digital Video Broadcasting(DVB); Transport
of MPEG-2 TS Based DVB Services over IP Based Networks",
Wu, et al. Expires April 16, 2011 [Page 17]
Internet-Draft Feedback Suppression October 2010
ETSI TS 102 034, V1.4.1 , August 2009.
[I-D.hunt-avt-monarch-01]
Hunt, G. and P. Arden, "Monitoring Architectures for RTP",
August 2008.
[I-D.ietf-pmol-metrics-framework-02]
Clark, A., "Framework for Performance Metric Development".
Appendix A. Example scenarios for NACK Implosion
In SSM RTP sessions as described in [RFC5760], 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.
A.1. Scenario 1: One or more media source, One distribution source
The scenario 1 is displayed below in Figure 4. 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.
+-------+
|---->|RTP_Rx1|
+--------+ | +-------+
| | +--------------+ |
| | | | | +-------+
| Media |-------| Distribution |-------|---->|RTP_Rx2|
| | | Source | | +-------+
| Source | | | | .
| | +--------------+ | .
| | | .
+--------+ | +-------+
|---->|RTP_Rxn|
+-------+
Figure 4: One media Source, one Distribution Source
Wu, et al. Expires April 16, 2011 [Page 18]
Internet-Draft Feedback Suppression October 2010
A.2. Scenario 2:One media source, Two distribution sources in cascade
+-------+
|---->|RTP_Rx1|
| +-------+
+------+ |
| | +------------+ +------------+ | +-------+
|Media |-+Distribution+--|Distribution+--|---->|RTP_Rx2|
|Source| | Source1 | | Source2 | | +-------+
| | +------------+ +------------+ | .
+------+ | .
| .
| +-------+
|---->|RTP_Rxn|
+-------+
Figure 5: One media source, Two distribution sources in cascade
The scenario 2 is displayed below in Figure 5. 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.
A.3. Scenario 3:One media source, Two distribution sources in parallel
The scenario 3 is displayed below in Figure 6. 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.
Wu, et al. Expires April 16, 2011 [Page 19]
Internet-Draft Feedback Suppression October 2010
+--------+
|---->|RTP_Rx11|
| +--------+
+--------------+ |
| | | +--------+
|--->| Distribution |----|---->|RTP_Rx12|
| | Source1 | | +--------+
| | | | .
+--------+ | +--------------+ | .
| | | | .
| | | | +--------+
| Media | | |---->|RTP_Rx1k|
| |---| +--------+
| Source | | +--------+
| | | |---->|RTP_Rx21|
| | | | +--------+
+--------+ | +--------------+ |
| | | | +--------+
| | Distribution |----|---->|RTP_Rx22|
|--->| Source2 | | +--------+
| | | .
+--------------+ | .
| .
| +--------+
|---->|RTP_Rx2j|
+--------+
Figure 6: One Media Source, more distribution sources
Appendix B. Applicability of Feedback Suppression
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 Appendix A.
Applicability of Feedback Suppression in Scenario 1 described in
Figure 4 is shown in the Figure 7. 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.
Wu, et al. Expires April 16, 2011 [Page 20]
Internet-Draft Feedback Suppression October 2010
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.
+------+ +--------------+ +--------+
|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 |
| | |
| | |
| | |
Figure 7: Applicability of NACK Suppression Early Indication
Applicability of Feedback Suppression in Scenario 2 or 3 described in
Figure 5 and Figure 6 is shown in the Figure 8. The procedure in the
Figure 8 is similar to the one in the figure Figure 7. 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.
Wu, et al. Expires April 16, 2011 [Page 21]
Internet-Draft Feedback Suppression October 2010
+------+ +--------+ +--------+
|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
Figure 8: Applicability of NACK Suppression Early Indication
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Wu, et al. Expires April 16, 2011 [Page 22]
Internet-Draft Feedback Suppression October 2010
Frank Xia
Huawei
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Roni Even
Huawei
14 David Hamelech
Tel Aviv 64953
Israel
Email: even.roni@huawei.com
Wu, et al. Expires April 16, 2011 [Page 23]